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

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.