"EME is not intended to be an interface to technical protection measures"

[wseltzer]

The specification should explicitly state that implementations MUST not be construed as "technological measures" or interfaces to technical protection measures in the meaning of DMCA Section 1201 or similar copyright laws in other jurisdictions.

EFF has proposed an anti-anticircumvention covenant, by which all participants in the Working Group would agree not to bring or join suit under anticircumvention laws. Some people have objected that such a covenant would be insufficient because it could not offer protection from criminal prosecution or suit by parties outside W3C. The spec and implementations can speak more forcefully to this objection, barring legal action by including specific indication that they must not be used or treated as a "technological measure."

(added note: this comment made as an individual)

[mwatson2]

@wseltzer Just for clarity, do you mean implementations of the specification in the narrow sense of implementation of the requirements in this specification, or in a broader sense that would include the CDM ?

[wseltzer]

@mwatson2 to encompass both cases, I suggested the language that implementations be neither TPMs nor interfaces to TPMs (technical protection measures). Does that make sense?

[mwatson2]

I see. So this would effectively prohibit implementations from being interfaces to DRMs like PlayReady or Widevine that are themselves TPMs ?

[wseltzer]

Or would prevent the CDM from being used as a DMCA-invoking TPM by EME.

[mwatson2]

Just to be clear, if the EME API implementation loads a CDM component and this component either contains or uses platform APIs to invoke something which meets the definitions of a TPM, this would not be allowed according to your proposal ?

[wseltzer]

It would not be allowed to function as a TPM under law. If the EME implementation couldn't disavow the legal operation as TPM, then it wouldn't be permitted to invoke that component.

[mwatson2]

Ok, I understand. How will compliance to this requirement be tested ?

[paulbrucecotton]

The specification should explicitly state that implementations MUST not be construed as "technological measures" or interfaces to technical protection measures in the meaning of DMCA Section 1201 or similar copyright laws in other jurisdictions. ... The spec and implementations can speak more forcefully to this objection, barring legal action by including specific indication that they must not be used or treated as a "technological measure."

@wseltzer : Upon further thought, this sounds like you are asking the HME WG to add text to a W3C technical specification that has possible "legal implications". How does this group of technical experts confidently do this? As Chair am I supposed to find consensus of the WG member's legal staff? Or how am I supposed to handle any possible Formal Objections to your proposed text on "legal grounds"?

/paulc HME WG Chair

[wseltzer]

@paulbrucecotton Yes, but EME has legal implications without this text, too. I'm trying to reduce the possible legal risks to users and researchers of the technology. In a priority of constituencies sense, I think we're better off doing that legal risk mitigation here among WG participants and their organizations, than throwing it to our users.

[paulbrucecotton]

@wseltzer : Given how late your issue has arrived please provide exact text you want added to the EME specification and please specify exactly where in the specification your proposed text should occur.

[AlexDeacon]

Hi. I object to the consideration of this issue in this group. This is a technical specification written by and for technologists. Whether or not EME is entitled to protection under the DMCA or similar laws is a legal conclusion that is outside of the group’s expertise.

[paulbrucecotton]

@wseltzer - Without a concrete proposal from you giving exact text that you want added to EME I am going to recommend that we close this issue with no action.

[wseltzer]

Text proposal: In section 2 add to the definition of CDM:

In a compliant implementation, all of the API, the CDM, and associated Key Systems with which it operates SHALL NOT be deemed "technological measure[s] that effectively control[] access to a work protected [by copyright]", in the meaning of Section 1201 of the U.S. Digital Millennium Copyright Act or similar copyright laws in other jurisdictions.

(apologies for the delayed response, just returning from vacation)

[ralph-brown]

Based on review by our legal counsel, CableLabs registers its opposition to @wseltzer's proposed addition to the definition of CDM (#288).

Whether the EME API, CDM, DRM and/or associated Key Systems are “technological measures” under 1201, or not, is a legal question and should be addressed by the Copyright Office or the Courts, not the EME technical working group.

[michaelchampion]

After discussing with counsel, Microsoft does not support making this change since it mingles legal edicts into the EME technical specification. We believe the adoption of this proposal will be a distraction to completing EME and a potentially damaging precedent where future W3C charters might try to layer a “legal” scope on top of the already complex technical scope of work.

[mwatson2]

I talked with our legal team about this as well and we fully agree with the comments made by @michaelchampion above.

[dwsinger]

I agree with Mike. The proposed change purports to interpret a term in a statute, which I don't think we should do. I also think that if we try to claim that neither EME nor the modules they link to are TPMs, this might backfire, as in some cases some people might consider the DRMs to be TPMs and hence question the entire statement, and actually put the EME more at risk than if we were silent.

[AlexDeacon]

Thanks to Wendy for the concrete text to review. However my opposition to the proposed change still stands. Whether or not EME is entitled to protection under the DMCA or similar laws is a legal conclusion that is outside of the group’s expertise. I'd like to also add my support to the comments made by @michaelchampion regarding the potentially damaging precedent adding this (or similar) legal language to W3C specifications would set.

[wseltzer]

In that case, perhaps we need a legal review panel, similar to the Patent Advisory Group W3C convenes when patent issues threaten the royalty-free nature of a spec, to get review and input from the appropriate participants.

[dwsinger]

Yes, the whole question of how we get advice about aspects of specifications that may have legal aspects or angles is tricky. I am not sure how to address it (sorry).

[ralph-brown]

CableLabs is still of the opinion that the question of whether the EME API, CDM, DRM and/or associated Key Systems are “technological measures” under 1201, or not, is a legal question and should be addressed by the Copyright Office or the Courts.

[j-helman]

After discussing with counsel, MovieLabs opposes the proposed change and agrees with CableLabs. The statute already provides a definition of a "technological measure." What meets that definition is a legal question. It's as if a specification for a self-driving car were to say that an "implementations of this specification SHALL NOT be deemed a motor vehicle under the California Vehicle Code or similar codes." It not the role of a technical specification to attempt to make law, and as Microsoft points out, it would set a bad precedent for this group to do so.

[mavgit]

Comcast has reviewed this issue with counsel and does not support making the proposed addition (issue 288) to the definition of EME, CDM and associated Key Systems for the reasons stated by CableLabs.

[steelejoe]

Adobe has discussed this internally and we also do not support making the proposed addition. Introducing legal language into a technical spec does not seem like an appropriate solution.

[paulbrucecotton]

This issue will be closed with no action as per HME WG decision and added to the list of current Formal Objections against EME.

/paulc HME WG Chair

[wseltzer]

Do any of those who have objected to this proposal (and to the EFF covenant) have alternative suggestions to allay the concerns of users and researchers about DMCA liability?

[jdsmith3000]

Closing per https://github.com/w3c/encrypted-media/issues/288#issuecomment-245045850.

[josephlhall]

@wseltzer I've been thinking about this and the subsequent discussion and it seems that folks here are objecting to legal language in a spec. I doubt coming up with non-legal language that achieved the same goal would be acceptable, but let me take a shot.

It seems like an option that might work would be something where the spec essentially rendered neutral the TPM aspect, which would deal with any chilling effect a researcher or tinkerer might encounter. So what about the following (everyone will hate this):

"Interoperability and secure functionality of EME and associated CDMs are important for widespread adoption of EME across UAs. As EME serves as an interface to interacting with protected content provided to UAs by CDMs, it is crucial that security researchers and other third parties be able to evaluate, study, and modify both EME and any CDM with which it interacts, free from fear of non-technical repercussions to their work, including legal threats, law enforcement attention, and in general uncertainty about what they can and cannot do with these technologies.

Each UA that implements EME will provide a method for a CDM to operate in such a manner that it is not protecting a copyrighted work (by protecting nonsensical content or content out of copyright or dedicated to the public domain) for research purposes."

[josephlhall]

Not that this doesn't mean a CDM vendor or rightsholder couldn't sue, but it might allow for a way for a TPM to operate in a UA that was not actually protecting a copyrighted work... I'm not sure that is even a start of a solution, but it's what I've got at the moment.