This is proven by the statement given by the BBC:

http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0153.html

Independent interoperability is determined during the CR phase. Resolving to later.

I (strongly) disagree with this "resolution".

Open Source and DRM are incompatible. This will not change for the CR phase.

There is not path forward that has an prospect of this reaching CR.

Discussed in the telcon:
http://www.w3.org/2013/02/26-html-media-minutes.html

The reporter does not details about where in EME there is a lack of information that means independent implementation is impossible.

CDMs by design are out of scope for this document. If someone wants to design a different solution to protected content that doesn't push CDMs out of scope they are welcome to.

(In reply to comment #5)
> Discussed in the telcon:
> http://www.w3.org/2013/02/26-html-media-minutes.html
> 
> The reporter does not details about where in EME there is a lack of
> information that means independent implementation is impossible.
> 
> CDMs by design are out of scope for this document. If someone wants to
> design a different solution to protected content that doesn't push CDMs out
> of scope they are welcome to.

Discussion of this bug depended on establishing some consensus
on definitions, see bug 21104, and I would note the 'task force'
has refused to even address this technical terminology, which
leads me to believe they have are not acting in good faith to
address this issue which is critical to assessing the
suitability of the EME specification as an open standard
of the web platform.

The declaration that the CDM is out of scope is inconsistent
with the constraints that the EME specification already places
on the CDM and I believe raises a concern that the 'task force'
either lacks competence or is acting in bad faith.

comment #5 states:
"CDMs by design are out of scope for this document."

At the same time there have been no objection to the statement in comment #3
"Open Source and DRM are incompatible. This will not change for the CR phase."

The conclusion is that this issue can not be resolved without changing the design of EME.

I am not aware of a solution which would both resolve this issue and fulfill the requirements of those supporting EME. Others also do not seem to be aware of such a solution.

It therefore seems to be impossible to resolve this issue as fixed.

The only honest way to "resolve" this without dropping EME therefore seems to be as "WONTFIX".

The proprietary software used for Chromebooks seems to contain a first used implementation of a draft version of EME and illustrates this issue.

Florian Bösch on 12 Mar 2013 asked:

"Could anybody point out the specification and required libraries that'd
allow me (or anybody) to encode/host their videos compatible with
chromebooks html DRM implementation?"

Chromebook DRM specification
http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0035.html

So far his question was not answered.

(In reply to comment #7)
> comment #5 states:
> "CDMs by design are out of scope for this document."
> 
> At the same time there have been no objection to the statement in comment #3
> "Open Source and DRM are incompatible. This will not change for the CR
> phase."
> 
> The conclusion is that this issue can not be resolved without changing the
> design of EME.
> 
> I am not aware of a solution which would both resolve this issue and fulfill
> the requirements of those supporting EME. Others also do not seem to be
> aware of such a solution.
> 
> It therefore seems to be impossible to resolve this issue as fixed.
> 
> The only honest way to "resolve" this without dropping EME therefore seems
> to be as "WONTFIX".

It might help to add that the term 'independent implementation'
needs clarification.  The meaning intended in this bug report is
that anyone would be free to implement an EME/CDM
solution and expect it to be interoperable.  In contrast to an
independent but encumbered implementation where is is
necessary to agree to restrictive licensing terms.

Note that some people claim that DRM could well be 'open
source' if it is restricted by the platform to only run a
particular approved version and if some critical
components, such as keys, are not included.  Such a
solution might increase the transparency of the operation
of the CDM and help address some concerns.  However, the
system as a whole is still not open and free for anyone
to independently implement and would not be compatible
for FOSS operating systems which do not offer the
required restricted platform.

Note that the EME itself is just an API definition
and a set of stubs may qualify as an implementation.
Thus it is necessary to qualify that it is the EME,
CDM, and platform combined that implement the DRM
restrictions that is claimed not to support
independent implementation.  The ethics of allowing
a standard to be split into an API and encumbered
CDMs to avoid scrutiny is a matter for the community
to consider.

Note that the EME claims non-DRM use cases as within
scope and these could well be unencumbered and could
be independently implemented in FOSS.  The ethics
of allowing a standard to claim less controversial
use cases, that could well be split out, and to
use these to deflect analysis of the compatibility
of the standard with the open web platform is a
matter for the community to consider.

If the non-DRM use cases are split out from the
EME specification then for all use cases it is
an API to support encumbered technology that is
not compatible with the W3C processes.  The ethics
of claiming that support for such an API is not
support for uses of the API is a matter for the
community to consider.

Note that my query for a specification/library does not concern "independently implementable" per se, and also not the UA side of things.

Proponents of the DRM solution have made the following claims:

1) That it is needed to help people avoid delivering video over flash/silverlight (a stance also taken up by Tim Barners-Lee)
2) That it will lead to more compatibility for video delivering solutions (a stance taken by Netflix)

Both these claims can be shown to be wrong as of the current state of affairs.

To achieve both goals there has to be a way for a person wishing to host DRMed media to serve these UAs DRMs. This information is missing, so both goals are currently not fulfilled:

1) People (other than Netflix) will turn to flash/silverlight because they cannot serve the UAs DRM for reason of the specification/libraries being withheld.
2) Compatibility is not improved because the specification/libraryies are being withheld.

The Netflix/Google DRM is the first implementation of an EME/CDM and such already set a tone of exclusivity and incompatibility and not achieving the stated goals of EME.

The current state of affairs is far from final and one should not jump to conclusions. (Imagine making such a final assessment of HTML5 based on the first implementations.)
 
Chrome has started rolling out CDMs on various platforms, including Chromebooks, with more to come. Likewise, the CDM team is rolling out support for platforms and content providers, starting with a small number, with broader availability to come.
 
Regarding compatibility, the public already has most everything it needs to serve protected content to Chromebooks. HTML5, the EME APIs, and the container formats and encryption are already well-defined and publicly available; any server can be used to serve the player application and media streams; and the CDM is being deployed with Chrome. The only thing missing is a license server and/or specification, which, as I said above, is being rolled out.

EME is not sufficent to implement the CDM. So far nobody has pointed out a specification/library.

Until such a time that is the state of affairs, which is that it is intentionally exclusive, incompatible, undocumented, unusable and not serving the stated goal of the EME.

The information has been provided in several comments in this issue.

The editors don't know what change you are suggesting that's different to Bug 20944. Please propose specific spec text for the group to discuss. A Change Proposal [1] would be very helpful to progress the discussion.

[1] http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#change-proposal

This issue as far as I am concerned is not only about "CDM-level interop" but about the incompatibility with Open Source in general. This obviously includes CDMs, but it also includes the browser and the operating system. In other words: Realistic CDMs will not be available for user modifyable operating systems and browsers. Maybe I should better improve the subject so that this becomes clearer ?

Fixing this issue without canceling EME is (almost) as impossible as designing a working perpetuum mobile. For that reason I can not provide a change proposal.

Thanks for the follow-up. I'm changing the resolution to make this a duplicate of bug 20944, which I believe is essentially the same issue (how will the spec encourage interoperable CDMs being available).

*** This bug has been marked as a duplicate of bug 20944 ***

As a result of the discussion on the mailing list of the W3C Restricted Media Community Group I provide a simple test of formal legal compatibility with Open Source:

Can EME be implemented using the GPLv3 or AGPLv3 license ?

Due to the intended purpose of EME using these licenses also results in certain requirements which have to be satisfied by the CDMs.

This is not a duplicate of bug 20944.

(In reply to Andreas Kuckartz from comment #17)
> As a result of the discussion on the mailing list of the W3C Restricted
> Media Community Group I provide a simple test of formal legal compatibility
> with Open Source:
> 
> Can EME be implemented using the GPLv3 or AGPLv3 license ?
> 
> Due to the intended purpose of EME using these licenses also results in
> certain requirements which have to be satisfied by the CDMs.

First can you please provide a pointer the exact discussion in the Restricted Media CG email discussion where this was discussed?

Second can you please explain why a W3C specification has to meet this kind of test?  I can find nothing in the W3C Process document or the W3C Patent Policy or any other W3C policy document that says this is true.

Third could you please describe a specific change that could be made to the current EME spec that would satisfy your test?

/paulc

(In reply to Paul Cotton from comment #19)
> (In reply to Andreas Kuckartz from comment #17)
> > As a result of the discussion on the mailing list of the W3C Restricted
> > Media Community Group I provide a simple test of formal legal compatibility
> > with Open Source:
> > 
> > Can EME be implemented using the GPLv3 or AGPLv3 license ?
> > 
> > Due to the intended purpose of EME using these licenses also results in
> > certain requirements which have to be satisfied by the CDMs.
> 
> First can you please provide a pointer the exact discussion in the
> Restricted Media CG email discussion where this was discussed?

There was a long thread discussing the semantics of "open web" and "open". I do not claim that there was or is consensus regarding the semantics or the suggested test. Here is an entry point:

Re: What is the "open web" ?
http://lists.w3.org/Archives/Public/public-restrictedmedia/2013Jun/0005.html

> Second can you please explain why a W3C specification has to meet this kind
> of test?  I can find nothing in the W3C Process document or the W3C Patent
> Policy or any other W3C policy document that says this is true.

The W3C officially has stated that it supports an "Open Web Platform". Before EME there were no differences regarding the semantics of "Open" in that context. This has changed. Some people within the W3C now would like to (re-)define it in a way which is incompatible with open standards and Open Source.

A standard which in practice can not be implemented using the GPLv3 is not open. EME in practice can not even be implemented using the GPLv2.

> Third could you please describe a specific change that could be made to the
> current EME spec that would satisfy your test?

As I stated in #c15:

"Fixing this issue without canceling EME is (almost) as impossible as designing a working perpetuum mobile. For that reason I can not provide a change proposal."

Another change would be for the W3C to officially declare that it no longer advocates the "Open Web Platform" but only a "Web Platform" (whatever that is).

(In reply to Andreas Kuckartz from comment #20)
> 
> As I stated in #c15:
> 
> "Fixing this issue without canceling EME is (almost) as impossible as
> designing a working perpetuum mobile. For that reason I can not provide a
> change proposal."
> 
> Another change would be for the W3C to officially declare that it no longer
> advocates the "Open Web Platform" but only a "Web Platform" (whatever that
> is).

Based on this comment, it is clear that your definition of "Open" differs from the W3C management's definition of this term.  I've encouraged you, repeatedly, to bring this up W3C management.  So far, you have declined to do so, and W3C management has repeatedly confirmed that EME is in scope.

If you do intend to follow up with W3C management, I have no problem with this bug being resolved LATER or MOVED and revisited when you complete those discussions.

If you do NOT intend to follow up with W3C management, then I have no problem with this bug being resolved INVALID, WONTFIX, or WORKSFORME; allowing you for Formally Object, at which point it will once again be an issue between you and W3C Management.

Either way, you need to work with W3C Management.  And this bug serves no purpose until or unless you do so.  Which of these two paths you chose to pursue is up to you.  Let us know what you decide.  Meanwhile, I've resolved this bug as NEEDSINFO.

(In reply to Sam Ruby from comment #21)
> Based on this comment, it is clear that your definition of "Open" differs
> from the W3C management's definition of this term.

So far I have not seen this "W3C management's definition" in writing. There are still people who erroneously think that the term "open" used by the W3C implies that W3C "open" standards can be implemented as Open Source. It would help to have such a definition in a form which avoids such misunderstandings.

I was not aware that Tim Berners-Lee had *already decided* that his final acceptance of EME will *not* depend on whether it can be implemented as Open Source. Thanks for that important clarification. I trust that you do not misrepresent his position.

(In reply to Andreas Kuckartz from comment #22)
> (In reply to Sam Ruby from comment #21)
> > Based on this comment, it is clear that your definition of "Open" differs
> > from the W3C management's definition of this term.
> 
> So far I have not seen this "W3C management's definition" in writing. 

The essence of your bug report is that EME is not in scope due to your interpretation of writings of the W3C that exist entirely outside of the HTML WG.  I again maintain that's a disagreement between you and those that produced those documents that you are citing.

I once again encourage you to work with those that produced those documents, and come back to this working group with the results.

> There
> are still people who erroneously think that the term "open" used by the W3C
> implies that W3C "open" standards can be implemented as Open Source. It
> would help to have such a definition in a form which avoids such
> misunderstandings.
> 
> I was not aware that Tim Berners-Lee had *already decided* that his final
> acceptance of EME will *not* depend on whether it can be implemented as Open
> Source. Thanks for that important clarification. I trust that you do not
> misrepresent his position.

I at no time made that statement.  Again, I think this is a misunderstanding by you on the position of W3C management.  And once again, I encourage you to work with W3C management to come to a common understanding.

(In reply to Sam Ruby from comment #23)
> The essence of your bug report is that EME is not in scope due to your
> interpretation of writings of the W3C that exist entirely outside of the
> HTML WG.

I do not think that this is a correct representation of this issue.

> > I was not aware that Tim Berners-Lee had *already decided* that his final
> > acceptance of EME will *not* depend on whether it can be implemented as Open
> > Source. Thanks for that important clarification. I trust that you do not
> > misrepresent his position.
> 
> I at no time made that statement.  Again, I think this is a misunderstanding
> by you on the position of W3C management.

Understanding the position of the W3C management seems to require a lot of effort. My conclusion now is that it is not well defined.

I suppose that the EFF and others did represent the relevant points in the debate with W3C management and therefore do not intend to repeat that effort. But I will try to formulate a question or small set of questions for the W3C management in the hope that the reply will further clarify the position of the W3C.