Copyright on Industry Standards: Does Implementation Create a Derivative Work?
The standard of proof for copyright infringement includes the element of “substantial similarity.” Because copyright protects expression, an infringing work must resemble the expression of the original, not merely its underlying ideas and concepts. If they do not look alike, it will be difficult to prove that an implementation is a derivative work of a specification. In the SCO v. IBMlitigation[1], for example, the plaintiff was ultimately unable to identify any specific code in Linux that was derivative of its own UNIX software, even though they were functionally similar.
Often a specification and its implementation are very dissimilar. Specifications that contain English words describing functionality are intended to be implemented in C++ or Java or some other programming language, and the natural language description – certainly to the untrained eye – doesn’t resemble the resulting code in the slightest. The judges and juries that will determine copyright infringement won’t be able without expert advice to determine the substantial similarity of highly technical expressive works of software.
Some software experts view this dissimilarity of expression between specification and software code as a technical disadvantage, and so they are trying to create specifications that are their own software implementations. In the HTML5 project, for example, which is creating standards for structuring and presenting content in browsers on the World Wide Web, the drafters are experimenting with a specification technique that replaces specification text with public domain reference implementations in terms of an abstract state machine, in an attempt to improve compatibility by avoiding the imperfect conversion of English to source code. Implementers are encouraged to copy specification text as software. In these cases, at least, a software implementation is obviously a derivative work of the specification, and thus an infringement unless licensed.
Regardless of the style of specification writing and the programming language, it is to nobody’s advantage to argue in court whether an implementation is a derivative work of the specification. A legal argument about whether an implementation is a derivative work, no matter how convincing, is not as convincing as a written license that expressly authorizes those derivative works. And so implementers seek licenses and standards organizations offer them. Standards bodies have devised their copyright licensing policies with the expectation that software implementations will be derivative works of their specifications.
Because software implementations will often be distributed under open source licenses, the compatibility of specification copyright licenses with open source rules becomes critical. The Open Web Foundation (OWF), in its specification license, addresses the copyright issue for software specifications succinctly and directly:
I grant to you a perpetual (for the duration of the applicable copyright), worldwide, non-exclusive, no-charge, royalty-free, copyright license, without any obligation for accounting to me, to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, distribute, and implement the Specification to the full extent of my copyright interest in the Specification.
Note that the copyright license here is “to the full extent of my copyright interest,” thus effectively ignoring the question posed in the title of this section. Note also that the broad copyright grant to implement the Specification is fully compatible with all open source (and proprietary) licenses.
That copyright grant, however, is not satisfactory to some standards organizations. It goes too far with respect to allowing derivative works of a specification as a specification. These standards organizations seek to protect the purity of their specifications by forbidding other standards organizations to take over those specifications and modify them. In colloquial terms, and as they frequently justify this restriction, these organizations wish to prevent the “forking” of their specifications that might result in incompatible implementations.
This is a reasonable business and technical concern for a standards organization. Anyone who witnessed the early years of the browser software wars will remember how functionally incompatible browsers inhibited the development of advanced websites, and allowed commercial competition rather than technical benefits to dictate browser functionality. No software implementer wants to repeat that experience.
Compatibility requirements, however, are anathema to open source implementers. A requirement that all implementations function in a particular way is contrary to every open source license that guarantees complete freedom to create derivative works. The desire of standards organizations to prevent forking of open standards contradicts the requirement of open source licenses that permit any derivative works.
This problem has recently been the subject of heated discussion in W3C relating to the new HTML5 specification. Nearly 80% of the W3C members responding to a survey said they do not want W3C to permit forking of W3C specifications, but they also overwhelmingly say that they want to encourage implementation of any open source software. By way of compromise, one proposal was for a new HTML5 license to allow software derivative works but to forbid specification derivative works. The Free Software Foundation, however, has argued that this restriction means that the proposed license is incompatible with the GPL. As this paper is being written, no final decision has been made about this license.
This problem was addressed by IETF in yet another way. They require specification writers to distinguish between “text” and “code.” The IETF copyright license allows derivative works of the code but not the text portions of its specifications. Thus implementers may use the code portions, but if they seek to document those code portions they are not allowed to create derivative works of the IETF specification text. This rather arbitrary way of addressing copyright law issues of derivative works of specifications is based on distinctions between text and code that are not found in copyright law or in computer science. I do not believe this distinction is enforceable practically.
The Oracle v. Google lawsuit presents another aspect of this derivative work copyright problem. Oracle asserts in its complaint that Google has infringed Oracle’s Java copyrights (presumably relating to the Java specifications, although the complaint in that case is not clear). Java specifications are published under a license that requires implementers to validate compliance with Java specifications using test compatibility kit (TCK) software licensed by commercial companies with contractual restrictions on the types of software derivative works that can be implemented. As such, it is incompatible with the requirements of the Apache License under which the Apache Software Foundation, and Google, publish their software. The Apache Software Foundation objected publicly to Sun, the Java specification steward, when it first imposed these contractual restrictions on the kinds of software derivative works that can be created if open source implementers license the Java TCK; now Oracle is the Java steward, and the concern has been reanimated by this recent litigation.
This question of whether software is a derivative work of a specification has thus become more important recently. Indeed, there may be no single answer that would satisfy those who create and seek to protect standards and those who implement those standards under open source licenses. Agreement on specification licenses will require a degree of compromise over copyrights that neither commercial companies nor the open source community have yet achieved.