On Sat, 25 Feb 2012, Glenn Adams wrote: > > On Sat, Feb 25, 2012 at 10:02 AM, John C. Vernaleo <john@netpurgatory.com> > wrote: > On Sat, 25 Feb 2012, Glenn Adams wrote: > > The issue isn't whether it can be implemented in > open source software (it > can), the issue is whether encrypted content can be > decoded and presented to > a user on a device that uses such implementation > while simultaneously > satisfying further constraints imposed by licensing > terms by content > providers who insist on using content protection > with acceptable impediments > to unauthorized access. > If such content providers cannot be assured of such > protection, then they > may not make the content available through such > means. > > > Saying that something can be implemented but not be used seems to be a > very odd definition of implementing to me. > > > It is important to separate technical issues and licensing issues. They are > orthogonal. There is a tendency to conflate the two in discussions of this > area, and that should be avoided. > > I can understand how some may be philosophically disposed to a policy of no > licensing constraints on content usage (including access, copying, etc.), > but that is a very different issue from defining technical mechanisms that > may be used to implement policy. Please, let's separate mechanism and > policy. > In principle, I'm in favor of keeping mechanism and policy seperate, but I'm afraid (and I suspect I'm not alone in this), that if we do that, we end up with a situation where open source implimentations are forever kept out of the game. Saying we can make open source implementations, we just can't use them in any meaningful way is not an answer some of us can be okay with (and shows that it is dangerous for us to accept talking about mechanism without any reference to policy).
Received on Saturday, 25 February 2012 17:44:49 UTC