W3C home > Mailing lists > Public > public-html@w3.org > February 2012

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 29 Feb 2012 17:20:11 -0500
Message-ID: <4F4EA49B.1060601@mit.edu>
To: Mark Watson <watsonm@netflix.com>
CC: "<public-html@w3.org>" <public-html@w3.org>
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.

>> 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.


> 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?

> 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...

Received on Wednesday, 29 February 2012 22:20:40 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:21 UTC