Re: Campaign for position of chair and mandate to close this community group

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