- From: John C. Vernaleo <john@netpurgatory.com>
- Date: Sat, 25 Feb 2012 13:50:27 -0500 (EST)
- To: Glenn Adams <glenn@skynav.com>
- cc: Andreas Kuckartz <A.Kuckartz@ping.de>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, Adrian Bateman <adrianba@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, David Dorwin <ddorwin@google.com>, Mark Watson <watsonm@netflix.com>
- Message-ID: <alpine.DEB.2.02.1202251346540.31490@yoshi>
On Sat, 25 Feb 2012, Glenn Adams wrote: > > On Sat, Feb 25, 2012 at 10:44 AM, John C. Vernaleo <john@netpurgatory.com> > wrote: > 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). > > > Just because one license for one content item employs a restrictive policy > does not mean that all licenses do the same. You over-generalize when you > imply that one such restrictive license effectively prohibits a meaningful > use of a mechanism with a non-restrictive policy. I'm not particularly concerned with particular restrictive policies; I'm concerned about building a system that open source projects cannot participate in, restrictive, or non-restrictive policies. > > The danger here is not restrictive policies. The danger is making premature > conclusions about the utility of a mechanism without a good understanding of > its potential range of uses. > I agree that restrictive policies are not the danger (although for full disclosure, I'm generally not in favor of restrictive policies, but I'm not trying to argue against them). I do however think that there is a danger in supporting a mechanism that has use cases for some parties without talking about the consequences of said mechanism.
Received on Saturday, 25 February 2012 18:50:45 UTC