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

On Feb 29, 2012, at 2:20 PM, Boris Zbarsky wrote:

> On 2/29/12 5:11 PM, Mark Watson wrote:
>>> Or put another way, we want to avoid creating barriers to entry into
>>> the device-making space, if we can. That means avoiding unnecessary
>>> restrictions on both the hardware and the software of potential new
>>> devices.
>> 
>> We can all agree to avoid 'unnecessary' restrictions ;-)
> 
> Well, sure.  We might just disagree on the definition of "unnecessary".  Requiring licensing for a CDM (either a patent or closed-source copyright license) from a consortium of your competitors might strike some as an unnecessary restriction and might seem perfectly fine to the members of said consortium, say.

I think we have to find models in which CDMs can get onto the device without any payment from the device vendor. This list isn't probably isn't the right place to resolve that.

> 
>>> Again, it's not immediately clear to me how to reconcile that with the
>>> current licensing regime of TV and movie content, just like it's not
>>> clear to me how to reconcile that licensing regime with fair use
>>> rights....
>> 
>> I don't see a big problem with the former unless you are talking about a
>> 100% GPLv3 software stack.
> 
> I don't see what GPLv3 has to do with my example of a custom-built device or a new device trying to enter the market.  How does either one end up with a CDM in a way that's not open to abuse?  (Note that RAND licensing is in fact open to abuse, as far as I can tell, though some claim it's not.)
> 
>> Content authors and software authors sometimes make incompatible choices about how they wish to license the
>> product of their respective endeavors.
> 
> Indeed.
> 
>> But I don't see how that should affect our work here
> 
> Well, it might insofar as we privilege one or the other set of choices, yes?

What I mean to say is that in a technical working group we should not privilege either choice.

> 
>> The latter seems to be a matter of public policy which should not
>> prevent us from supporting in HTML what is widely supported outside HTML
>> today.
> 
> I think that enshrining things in de-jure specifications that implementations are then expected (and in some cases coerced, by law) to conform to always involves a certain aspect of public policy on the part of standards bodies...

Sure, but our proposal does not enshrine anything more in relation to this issue than the existing support for plugins does. The requirement to make access to encoded content difficult, making some uses of the content more difficult, comes from the licensing terms of the content either way, not from any specifications.

...Mark

> 
> -Boris
>

Received on Wednesday, 29 February 2012 23:17:49 UTC