W3C home > Mailing lists > Public > public-restrictedmedia@w3.org > May 2013

Re: Alternatives to DRM?

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 6 May 2013 14:06:38 +0300
Message-ID: <CAJQvAud2H86jbc_9vHxd1+o4cDQx+72RV5xue+XAqngUCPWOQA@mail.gmail.com>
To: Jeff Jaffe <jeff@w3.org>
Cc: Dominique Hazael-Massieux <dom@w3.org>, public-restrictedmedia@w3.org
On Wed, Apr 24, 2013 at 6:07 PM, Jeff Jaffe <jeff@w3.org> wrote:
> On 4/24/2013 8:27 AM, Henri Sivonen wrote:
>> On Wed, Apr 24, 2013 at 2:33 PM, Jeff Jaffe <jeff@w3.org> wrote:

>>> To your point, W3C could certainly add a new practice to make sure that
>>> our
>>> standards are compatible with the "no 'disclosed source code except
>>> keys'"
>>> category.  In that case DReaM like solutions would indeed be excluded.
>> I thought it was already effectively a requirement that W3C specs be
>> implementable in ways that grant the downstream freedoms associated
>> with Open Source
> I have not seen that in my three years at W3C, but I would appreciate
> pointers to where that practice was established.

The current Patent Policy of the W3C emerged as the result of feedback
the W3C received over a draft policy that allowed RAND. One of the key
arguments against RAND was the incompatibility of RAND with Free
Software / Open Source. See for example feedback from Mozilla to that

That the W3C abandoned RAND and went with RF instead strongly
indicates that the W3C valued implementability as Free Software / Open
Source (though right now I'm unable to locate an explicit
acknowledgement by the W3C at the time to that effect).

Back then, it was already understood that patents and RAND were
poisonous to Free Software / Open Source, but back then the problem of
Tivoization was not yet properly on the radar (neither in the narrow
sense of using cryptographic certification to deny code from running
nor in the broader sense of using cryptographic certification to deny
interoperability to program by means other than preventing it from
running; the latter problem being more immediately relevant to EME).
That the threat of using cryptographic certification to deny
interoperability depending on the provenance of an implementation
wasn't on the radar when the W3C Patent Policy was written doesn't
mean that denying interoperability based on (the lack of)
cryptographic certification of the provenance/characteristics of an
implementation isn't a threat analogous to the one that the current
Patent Policy seeks to address relative to the earlier RAND-embracing
draft that was abandoned.

>>   (and that this was one of the reasons why the
>> boundaries of the EME spec have been drawn to exclude the actual
>> production CDMs).
> W3C has not received any requirements to work on actual production CDMs.

Probably because it's understood that the requirements would be
incompatible with what expected of W3C specs.

Henri Sivonen
Received on Monday, 6 May 2013 11:07:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:24:30 UTC