Re: Open Source implementations Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

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.

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.