W3C home > Mailing lists > Public > public-html-admin@w3.org > January 2013

Re: Oppose DRM ! Re: CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD)

From: Mark Watson <watsonm@netflix.com>
Date: Fri, 25 Jan 2013 19:29:59 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: David Singer <singer@apple.com>, "public-html-admin@w3.org" <public-html-admin@w3.org>
Message-ID: <78FE20E1-64FB-41F7-8509-25772ACFBC0E@netflix.com>

Sent from my iPhone

On Jan 25, 2013, at 10:53 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Fri, Jan 25, 2013 at 10:40 AM, Mark Watson <watsonm@netflix.com> wrote:
>> On Jan 25, 2013, at 10:25 AM, Tab Atkins Jr. wrote:
>>> "Up to the moment of play" is incompatible with FOSS, to the best of
>>> my knowledge.  If it needs to stay encrypted after hitting the
>>> destination computer, you're out of luck.
>> It's certainly incompatible with the "Anti-Tivoization" clause of GPLv3, in which the software license requires that the end user of the software must be able to modify it and still have it work.
>> It's not incompatible with "Open Source" per se.
>> As I've said before, GPLv3 licensors are just as entitled to place these restrictions on how their hard work is used as video content licensors are to place restrictions on the uses made of their work. The fact that these two groups of people have made mutually incompatible license choices is just the way things are and the fact that they are free to make those choices is a good thing. It's not a reason to object to this work.
> I disagree with you on moral grounds, but that's neither here nor
> there.  I'm talking *technically* incompatible.  If you require the
> file to be encrypted from the user you are sending it to, then you
> require a secret that the user doesn't know.  FOSS requires all the
> code to be knowable by the user, and a popular browser (FF) and a
> popular family of operating systems (Linux) are both FOSS.  If we make
> the reasonable assumption that those are the only two places the DRM
> module might live, then in a reasonable situation (FF user on Linux)
> there is no way to do DRM.  

To say DRM is incompatible with some Open Source software is different from
saying that it's incompatible with Open Source per se. One could write a media player application that is fully open source, with the intention that some parts are run on a Trusted Execution Environment (which itself could be open source) and this combination could be shipped to users in devices that meet the requirements for playback of protected content. The user would not be able to install a modified version on that device and still have the protected content aspects work, so no GPLv3 could be included, but it is still open source.

I'm not saying this is more than theoretical right now.

Protected content is not available in Firefox on Linux today - for the reasons you give - and I don't claim this specification provides a solution to that problem.

> In many other reasonable situations (FF on
> any OS, any browser on Linux), there's at least a conceptual
> disconnect between the goals of one of the pieces of software involved
> and the use of a DRM module located in the other piece.
> ~TJ
Received on Friday, 25 January 2013 19:30:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:57:21 UTC