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

On Wed, Jan 15, 2014 at 8:42 AM, Rüdiger Sonderfeld
<ruediger@c-plusplus.de>wrote:

> On Wednesday 15 January 2014 07:50:44 Mark Watson wrote:
> > My point was that there is at least one case where that functionality is
> > already present in the Operating System and exposed through public APIs.
> > So, in that one case, you can have a browser which is completely FOSS and
> > which supports EME, just as you can have a browser which is completely
> FOSS
> > but which benefits from (other) proprietary technologies in the OS or
> > hardware.
>
> I just looked up the licensing terms on Microsoft's PlayReady website and
> it
> explicitly states
>
> 3.1 (a) of the PlayReady Master License agreement
>
> | The licenses granted in the PlayReady License(s) do not include the
> | right to, and Company shall not, distribute the Licensed Technology
> | (or derivative works thereof, including De veloped Technology) in any
> | manner that would ca use any Licensed Technology component to become
> | subject to any of the terms of an Excluded License.  An “Excluded
> | License” means any version of the GNU General Public License (GPL), Le
> | sser/Library GPL (LGPL), Mo zilla Public License (MPL), Comm on Public
> | License (CPL), Affero GPL (AGPL) or any other li cense for software
> | where the license include s terms providing that (a) a licensee of th
> | e software is authorized to make modificati ons to, or derivative
> | works of, the source code for the software, and (b) the licensee is
> | authorized to distribute such modifications or derivative works of the
> | software only if recipients are authorized to receive th e source code
> | for, modify or make further derivativ e works of licensee’s
> | modifications or deri vative works. For purposes of this clause ,
> | “distribute” includes providing access to the functi onality of the
> | code through a computer network”.
>
> The license explicitly says that PlayReady can not be used with any
> copyleft
> license.  It is also noteworthy that the Mozilla Public License (MPL) is
> also
> excluded thus preventing one major browser vendor from using this
> technology.
>
> Therefore your claim seems to be wrong that a copyleft free software
> browser
> could support full EME functionality even on the one example platform that
> does expose an interface to its proprietary non-portable closed source CDM.
>

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.


>
> There are other noteworthy points in the license agreements.  E.g., 3.4 in
> the
> final product license
>
> | Use by Other Products. Providing access to the Licensed Technology
> | functionality in a Final Product via an API, interface, or other
> | similar mechanism created by Company, is prohibited except as
> | otherwise expressly permitted in the Compliance Rules.
>
> Which would disallow using it for EME.  Not to mention the price tag of at
> least $30,000.


See above.


> 


> And as I stated in my previous message there is an inherent legal issue
> with
> any form of DRM.  A free software browser might use a proprietary
> implementation of a video codec on one system but can provide or use a free
> software implementation on another.  However it would be illegal (even a
> criminal offence in many countries) to do the same for a DRM
> implementation.
> Therefore we can not compare DRM to just any other common technology.
>
> > This is just one platform, I am not claiming any more than that, but that
> > proof point refutes the argument that EME can never be implemented in
> FOSS.
> >
> > Of course, when the object is to have the entire software stack,
> including
> > the OS and firmware, be FOSS, then it's true that you cannot play back
> > protected/restricted content. EME doesn't create or change that
> situation.
>
> But this is exactly what violates the W3C's principles!  They explicitly
> state
> "One of W3C's primary goals is to make these benefits available to all
> people,
> whatever their hardware, software, [...]".  And that includes a free
> software
> operating system.
>

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.

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.

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


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



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

...Mark



>
> Regards,
> Rüdiger
>
>