Home

Law vs. Interoperability

The Case of the Law vs. Interoperability Standards

by Tom Lord, 19th September 2008

Executive Summary

The EOT proposal would include in a web font W3C Recommendation some mix of normative and informative language that requires user agents (such as browsers) to not render using a given font if the meta-data accompanying the font suggests that such rendering might constitute an act of copyright, trademark, or patent law violation on the part of the user, in certain jurisdictions.

Those legally-inspired elements of the EOT proposal are the primary source of controversy over the EOT proposal and here we generalize the questions this raise and examine some specific implications for web fonts.

We explain how such legally-based standards place the implementors of a standard in a double bind: they must either be fair to users or must conform to the standard, yet can not do both at once.

We propose that such a bind is resolved by applying the "interoperability test": if the removal of a restriction from a proposed standard does not damage interoperability then the restriction must be removed. We argue that many legally-based restrictions in standards fail the interoperability test, most specifically the proposed EOT restrictions.

We conclude, therefore, that a web font proposal MUST NOT contain such legal language, either normatively or informatively and that W3C should adopt the "interoperability test" as an architectural principle.

The Problem

The call to form an EOT working group and the proposal it makes for an EOT-based web font standard presents us with a novel question, which we can express this way:

Ought W3C standards refer to legal compliance in their normative or their informative content?

That very general question can be specialized for the EOT proposal as a series of more specific questions, including but not limited to:

  1. Ought a web font standard contain words to the effect that a user agent "MUST NOT" render with a font if meta-data is present that indicates the user "lacks legal permission" to render using the font?
  2. Similarly, ought a web font standard contain words the effect that a user agent "SHOULD NOT" render if an apparent "lack of legal permission" is detected by software?
  3. Finally, ought a web font standard contain a rationale for a "MUST NOT" or "SHOULD NOT" render provision such that the rationale says the restriction "is justified by the user apparently lacking legal permission to render"?

Understanding the EOT Situation

Under the EOT proposal as it stands, we can imagine the following scenario:

  1. A user is using a browser (the "user agent") to examine some data which the user possesses.
  2. That data comprises an HTML file associated with a specific URL, and an EOT font file, both downloaded from the web.
  3. The HTML file happens to link to the font file.
  4. The font file contains a "root string" or other form of "embedding rights meta-data". This meta-data conveys to the user a legal claim, made by the publisher of the font file, that legal permission to render the HTML document with this is not given.
  5. Technologically, the user agent is perfectly capable of rendering the HTML document with the font regardless of the meta-data. The user possesses all of the necessary data about the font. That font data is sufficient to render using the font in "the ordinary way".

The EOT proposal seeks to, one way or another, have W3C assert that a user agent, such as a browser, is non-conforming unless it refuses to render.

The Double-Bind for User-Agent Implementors

The legal claims conveyed in the meta-data in an EOT file are complex, uncertain, have no universal meaning. In some situations, users are likely to be harmed if these legal claims are interpreted by a user agent which "refuses to render" (or perform some other operation) with the font on the basis of those legal claims.

First, the legal claims in a font file refer to copyright, trademark, and or patent law. It is from such laws that a user's purported "permissions" towards a font are defined. Yet, there is no world-wide jurisdiction for such laws. What is legal in one part of the world may not be in another. Thus, requiring a user agent to enforce these restrictions necessarily harms users who are not in jurisdictions where the same laws apply. Ought a W3C Recommendation require implementors to prejudicially harm a subset of users that way? We think the answer is obviously "no".

Second, the legal claims in a font file are not even always applicable even within the jurisdictions they favor. Sometimes, this can foreseeably be a matter of life and death as in this scenario:

Scenario:

An major earthquake has occurred in the San Francisco Bay region. Considerable damage has occurred and many fires have broken out.

The computing systems and communications systems of first responders are under stress. One firefighting unit has two computers, one of which contains a pre-planned priorities checklist of how to respond to the chaos. Unfortunately that computer is damaged.

The first responders are able to rescue a disk from the damaged computer and move it to a computer that still works. Their goal is to quickly view the checklist.

An unintended consequence of the web content management system used to develop the checklist is that it happens to use a font whose EOT meta-data indicates it would be illegal to view the list or print with it, using the correct font, from the still-working computer.

The still-working computer does not have installed any unrestricted back-up fonts suitable for usefully rendering the emergency checklist.

It would be entirely legal in this jurisdiction for the first responders to render with and print using this font regardless of the licensing and regardless of the EOT meta-data.

The user agent software, however, refuses to permit this. The standard has required the software to help enforce a law, specifying exactly how to do so, and as a result a perfectly lawful and life critical use of the font is precluded in a time of need.

The first responders must do without the checklist.

In order to be "standards conforming," in the case of EOT, an implementor MUST create the risk of such a scenario. Again, the implementor is in a double bind forced to choose between harming the users or ignoring the standard.

Towards a Way Out

From the perspective of an implementor, the "implementors' bind" (the choice harming users and ignoring the standard) is easy to resolve:

If, on the one hand, an implementor honors such a standard then he places life and limb at risk via restrictions on users.

If, on the other hand, an implementor refuses the standard, his software remains fully interoperable with standards-conforming software and yet avoids the risk to life and limb.

The implementor has a simple, even no-brainer moral choice: to ignore the standard and explain to users why the standard was ignored in this regard.

Towards a Policy for W3C

W3C aims to be a neutral and respected authority for global standards of software interoperability on the web. In the instance of EOT-style font restrictions, the choice confronting W3C is between rejecting such restrictions or losing respect as a neutral authority.

What general architectural principle can the W3C devise and bring to bear so as to have a rule-based, policy-driven way out of such a bind?

We propose this simple rule:

THE INTEROPERABILITY TEST

If the removal of a proposed restriction from a standard will not damage interoperability, then the restriction must be removed.

The elegance of this simple rule is that while it neatly evades any complex and ideological debates about the proper role of law in W3C standards, nevertheless it clearly rules out a broad class of DRM-like standards maneuvers such as those seen in the EOT proposal.

Interoperability standards should explain how users can use various formats of data and communications.

Interoperability standards should not (vainly) require implentors to try to prevent perfectly well-defined uses.

Conclusions

We urge W3C to adopt the "Interoperability Test" or a close variation as an architectural principle by which all future Recommendations should be judged.

Regardless, we believe that the specific application of the interoperability test to the case of EOT is sufficient reason to reject the proposed restrictions on font rendering, printing, and so forth. Our examination of the scenario of first responders after an earthquake helps to illustrate the stakes.