Patents on Industry Standards: Can a Specification Infringe a Patent?
Copyrights are not the only intellectual property problem besetting software standards. Far more difficult are the effects of patents on the software ecosystem, because copyrights encumber only derivative works but patents can encumber any implementation. A clean room implementation of a specification will avoid copyright infringement — but it is not so easy to avoid patent infringement.
Patents are not a problem for specification writers, but rather for implementers. Anyone is free to write a description of how to perform a process or method – indeed the patent system requires the open publication of just such a specification when a patent is granted. But when that specification is transformed into functioning software and distributed for actual use by actual people and companies, those users may be patent infringers. In the proprietary software world such risks are commonly borne by the vendors of software products with offers of limited warranties and indemnity, usually capped at reasonable dollar limits. But with free and open source software that is distributed without warranties or indemnities, the risk of patent infringement when using implementations of standard specifications is borne by the user.
Note that this patent risk is in practice quite low. While hypothetical situations can be litigated easily in the mind, there have been no notable patent infringement lawsuits in U.S. federal court over software standards implemented in open source software. When major software companies cooperate openly to develop industry standards in organizations like W3C and IETF, few of them have much incentive to demand royalties or impose burdens on competing implementations. Some standards, of course, such as those for music and movie distributions on the web, are proprietary and licensed for a fee. Open source projects have typically refused to implement those encumbered standards, which may partly explain the dearth of infringement lawsuits. But when the stated goal of the standards setting organization is a royalty-free patent license for open source implementations, litigation over such patents is unnecessary.
The Oracle v. Google case is a recent exception. As I mentioned earlier in the copyright context, this lawsuit relates to Java software. Java is an industry standard for a popular programming language, and there are several proprietary and open source implementations of that language and its related programming libraries. Given the widespread reliance of the software industry on Java, it was a surprise when Oracle asserted a number of its patents (acquired in its acquisition of Sun) against Google, purportedly for Google’s implementation of the Android open source operating system.
It is far too early in this litigation to comment on the merits of the case, but the effect of the Oracle v. Google lawsuit has already been to put a cloud on the Java standard. This litigation is likely to discover some hitherto unexplored areas of software competition practices that are problematic given the explicit promises and community expectations of the parties to the Java Community Process under which Java was developed. In particular, the Apache Software Foundation has already complained about the JCP requirement that implementers acquire and pass a Test Compatibility Kit (TCK) before receiving Java patent licenses from Oracle (Sun), when those TCK licenses expressly prohibit certain kinds of implementations and derivative works. That TCK licensing practice for industry standards is not compatible with open source, and those contractual restrictions on the use of specifications have not be accepted by Apache.
Traditional standards organizations have finessed the patent problem by requiring authors of specifications to offer Reasonable and Non-Discriminatory (RAND) licenses. RAND doesn’t mean “free”, however, and it doesn’t mean “without encumbering conditions,” and so RAND promises are of little use to open source implementers. Fortunately, because open source implementations have become important as validations of open standards, most software standards are now actually published under RAND-Z, or zero-priced, RAND licensing terms. This promise of reasonable and non-discriminatory licensing terms is often made but not usually put into explicit words. For example, most contributions to IETF are accompanied by RAND promises, but actual licenses are not published anywhere on the IETF website. Nor does the W3C royalty-free patent policy require the publication of an actual patent license, although members of W3C are committed by their membership agreement to grant such a license if asked. Nobody asks.
Open source licensing practices no longer tolerate such ambiguities. Contributors to mature open source projects sign Contributor License Agreements to provide written confirmation of their copyright and patent promises. The Open Web Foundation (OWF) is drafting such explicit agreements for industry standards to mitigate the risks of patent litigation.
One important difference between the OWF proposal and traditional industry standard practices is in the identification of the patent claims being licensed for free. In most standards organizations the patent grant is to “Necessary Claims” – meaning those patent claims that are necessary to implement the specification without infringing. Actual terms differ; sometimes the rule is “actual technical impossibility” of implementation without a patent license and sometimes merely “financial or technical impracticality” of implementation unless a patent license is available. Either way, this Necessary Claims language means that if there are multiple ways of implementing a specification, then no patent claim is a Necessary Claim.
OWF takes a more generous view of patent licensing for industry standards. Its patent grant says simply:
The Promise. I, on behalf of myself and my successors in interest and assigns, irrevocably promise not to assert my Granted Claims against you for your Permitted Uses, subject to the following.
The OWF agreements then define “Granted Claims” simply as those claims that are infringed by “Permitted Uses”:
“Permitted Uses” means making, using, selling, offering for sale, importing or distributing any implementation of the Specification 1) only to the extent it implements the Specification and 2) so long as all required portions of the Specification are implemented. Permitted Uses do not extend to any portion of an implementation that is not included in the Specification.
This means that, so long as he is implementing the required portions of a specification, and even if there are multiple ways of implementing that specification, an implementer is free to choose a patented method if it is better or more efficient. The license extends only to the desirable goal of implementing the specification, however, and it is not a license for all uses of the Granted Claims.
To protect patent owners from unanticipated grants of their patents, as well as to protect implementers from game-playing by patent owners, the OWF agreements define Granted Claims as follows:
“Granted Claims” are those patent claims that I own or control, including those patent claims I acquire or control after the Date below, that are infringed by Permitted Uses. Granted Claims include only those claims that are infringed by the implementation of any portions of the Specification where the Specification describes the functionality causing the infringement in detail and does not merely reference the functionality causing the infringement.
Under the OWF, patent owners are thus able to read a Specification to determine which of their patents will be licensed to implementers, without needing to determine whether their patent claims are in some vague sense Necessary Claims because there are no alternatives. And implementers are able to read a Specification and, as long as they are implementing all the required portions of the Specification, they needn’t worry about patent litigation for that implementation.