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

On Wed, Jan 15, 2014 at 12:26 PM, Rüdiger Sonderfeld <ruediger@c-plusplus.de
> wrote:

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

Yes, that means you're distributing the PlayReady code itself.

Try this one: http://msdn.microsoft.com/en-us/library/windows/apps/dn466732


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


It's not a question of the technology not being available for legal
reasons. It's not available on some platforms because the implementors /
users of those platforms choose not to accept it (and they are perfectly
entitled to make that choice, btw, I have no problem with them doing that).


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


There are several counter-examples, for example OMA DRM. 


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


The expectation is that browsers will integrate with a small number of
CDMs and this integration will be fully controlled by browsers with no
option for downloadable / user-installable CDMs. Service providers will
need to adapt to the CDMs integrated with browsers.

The alternative is a proliferation of service-provider-specific plugins.


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

Whether and where DRM capabilities are used is independent of what W3C
does. Some services will use them whatever is standardized or not. We're
talking here about how we factor that technology in browsers - whether we
have a few tightly integrated solutions under browser control, or a range
of unconstrained plugins.


>
> This would make it impossible for a free software browser to be effectively
> compliant.  And trying to be compatible is actually illegal.
>

I guess you're referring to the possibility that someone reverse-engineers
a CDM, extracts the secrets and then implements their own FOSS CDM which
spoofs the original one ? That would then be software that deliberately
makes false attestations. I can well imagine there are a variety of
problems with that.

However, as explained above, it's entirely possible for a FOSS browser to
integrate with a non-FOSS CDM that is distributed separately, for example
with the OS.


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

So, I think we share the goal of making <object> plugins obsolete. To do
that, we need to provide directly all of the capabilities for which people
presently rely on plugins. I agree HTML5 is proving successful there -
almost everything that is actually used and that previously required Flash
or SIlverlight can now be done with HTML5. *Almost* everything. But just
because you don't like the one remaining thing doesn't mean you can just
not provide it and services will just shrug and remove it from their
requirements. One way or another there will be new solutions to that one
remaining piece. And so, again, I'd suggest that the EME solution is better
than the alternatives when measured against the W3C goals.

...Mark



>
> Regards,
> Rüdiger
>
>