- From: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
- Date: Wed, 15 Jan 2014 21:26:47 +0100
- To: Mark Watson <watsonm@netflix.com>
- Cc: "public-restrictedmedia@w3.org" <public-restrictedmedia@w3.org>
On Wednesday 15 January 2014 09:34:00 Mark Watson wrote: > IIUC, it is not necessary to become a PlayReady licensee to use the public > APIs that expose PlayReady functionality to Windows applications. > > What the above refers to, I believe, though IANAL, is where someone becomes > a PlayReady licensee in order to actually ship the PlayReady code in their > product, and then the restrictions above apply to the shipping product that > includes PlayReady. I don't know the full details of PlayReady licensing and IANAL as well. The PlayReady website offers a way to select the matching license http://www.microsoft.com/playready/licensing/ I selected "Distributing a downloadable software application to end-users" and "A downloadable application created using the PlayReady Porting Kit" (the results don't change for the other option). I just found that there is an option for "Developing a PlayReady PC Application". Which has unspecified license conditions for Windows 8 and for Windows 7/Vista refers to the "PlayReady PC Software Application Development and Distribution Agreement" which has similar points in it: 4.6 for the excluded licenses and 4.3 for the limitations on APIs. (Noteworthy: The license costs in this case are $5,000 and $10,000 for each major release.) > What you are saying is that the fundamental incompatibility between some > content licensors' insistence on non-user-modifiable players and some > software authors rejection of such components is a "violation of W3C > principles". I'm not sure what we can do about that, since I doubt either > of those two groups is going to change their position soon and certainly > not just because of the interaction of their respective positions with W3C. > It's not EME that causes this. EME makes no change to this situation. I'd argue that a non-user-modifiable player is in itself a violation of W3C principles. Because such a player is inherently impossible to make available to all people. I know that some leading W3C members have decided that content protection is within the scope of HTML. But this does not mean non-user- modifiable players are the way to approach this. But nonetheless we have to deal with the fundamental incompatibility you mention. Maybe neither group will change their position. But the few licensors who still insist on DRM need ways to license their content. So I guess they have to show a bit flexibility or implement their DRM in ways which alienate legitimate users even further. I don't see why it's the W3C's obligation to help them especially when the price being paid is the freedom of users and software authors. And as long as the fundamental incompatibility exists it is a violation of the W3C principles. > Emmanuel raised this goal again in another mail. I don't think there can be > much disagreement about the meaning of the goal. It's pretty clear. We all > know what a "goal" is. Exactly what "these benefits" are doesn't seem to be > a point of contention. It's a goal to make those benefits available widely, > as defined. > > The disagreement is whether we should be absolutist about it. Do we reject > something that makes the "benefits" more widely available, that advances > towards the goal, just because it doesn't tick every box ? Do soccer > players always shoot directly for the goal, or do they sometimes pass the > ball up the field ? Interpreted absolutely, the goal is unachievable > anyway: there will always be hardware and software that don't support web > browsers at all. There will always be new technologies that we'd like to > support in the web platform which aren't supported on older hardware or > software. There will be people who, despite our best efforts, are outside > the reach of our accessibility technologies. There is a clear difference between a technology not being available because someone uses old hardware or software and the technology not being available because of legal reasons. Old hardware and software can be upgraded. The legal limitations cannot change. Reimplementing a DRM module is a criminal offence in many jurisdictions. > Finally, regarding Free Software, whilst Open Source is an important > component to W3C earlier discussions on this list concluded that there > was't a formal policy that interpreted "Open Source" as "Free Software". A DRM implementation cannot be open source either. So the difference between free software and open source seems to be irrelevant to the discussion about EME. > > EME creates a situation where a W3C standard would implicitly depend on > > inherently closed source proprietary non-portable black boxes which are > > not > > compatible with free software. > > Not really, we already have <object> and we have plugins that are "closed > source proprietary non-portable black boxes which are not > compatible with free software > " but which are required for some services on the web. EME doesn't create > that situation. My contention is that EME improves on that situation for > reasons we've gone into in depth on this list. (See below) > > The W3C can not control the usage of such > > > > modules outside the scope of W3C standards. But at least the W3C should > > not > > encourage or help the proliferation of such modules when they are > > fundamentally incompatible with the W3C's own principles. > > EME is exactly *discouraging* the proliferation of such modules, by > having browsers take control of the one remaining function that they are > actually required for. There would then be the prospect of deprecating > <object> over time, since there would be no reason left to use <object>. > > Now, the argument has been made that EME *doesn't* in fact advance the > goal above compared to the status quo. That's a different argument which I > guess we could also repeat. EME is an interface to those modules. How is that discouraging to the proliferation of such modules? It seems to me rather that it will promote the use and thus proliferation of these modules because EME would make them de facto part of the standard. This would make it impossible for a free software browser to be effectively compliant. And trying to be compatible is actually illegal. One of the major reasons behind the HTML5 effort was to make <object> and the typical plugins obsolete. Exactly to help advance the goal above. And HTML5 seems to be quite successful in that regard and the two major plugins are now at the end of their life. However by adding EME the result will be that the web still depends on proprietary closed source plugins. EME is the backdoor or lifeline those plugins need even if they come in a slightly different form. It is therefore at least a step backwards. Regards, Rüdiger
Received on Wednesday, 15 January 2014 20:27:21 UTC