Desperately Seeking License Simplicity
In the prequel to this essay, Advancement Through License Simplicity, an effort was made to provide a sense of how license complexity hinders innovation, freedom, and legal safety and, by contrast, how license simplicity achieves the opposite, more positive goal. In service to this end, a simplified analysis of the relative sizes, and complexities of construction, of various licenses was presented. At the time of that writing, the conditions addressed by this essay did not exist as they do now. The unpleasant circumstances of difficulty finding license simplicity within a particular category of licenses was, at that time, not alleviated by the existence of a license that has since been created. In short, only the problem identified here existed, and not the solution.
This essay is not legal advice. If you need legal advice, you should pay a lawyer for it.
The Need: Patent Clauses
There is a perceived need for patent clauses in software licenses, or in copyright licenses in general. The effectiveness of patent clauses as a protective measure is somewhat in dispute, because copyright infringement is something that generally only happens intentionally by way of copying a specific party's works while patent infringement occurs by accident uncountable times every single day and there is no single patent that must be avoided in every case. While there is in theory only one person in the world whose copyright you might infringe with a particular act of copying, there are in theory over seven billion potential patent holders whose patents you might infringe as a result of your own independent act of invention. The value of a patent clause in a copyright license for a particular piece of software, then, is somewhat diminished by the fact that some other party unrelated to the software project in question may show up one day with a lawsuit for you, regardless of that patent clause. Even so, there seems little harm in using a patent clause to at least protect your project against the actions of those who might wish to use, and contribute to, your software project.
For the most part, people who liked patent clauses in their licenses have seemed to fall into three major categories in the past:
people who like complex licenses -- lawyers paid by the word and copyleftists prominent among them
people who know little or nothing about licensing
frustrated people
Unfortunately, those frustrated people are not typically the people prone to creating licenses to solve these problems. The people who know little or nothing about licensing tend to either just use whatever "everyone else" is using or make a tremendous mess of things by trying to create new licenses that are more legally dangerous than helpful.
The Problem: Complex Licensing
The world of open source licensing contains strong contingents of people who favor complex licensing. There are several reasons for this, and there will be no pretense of offering a comprehensive overview of all those reasons here. Some of those reasons, however, seem both clear and relevant to the topic at hand.
One reason is that licenses with no legal rigor tend to fall out of favor when they significantly exceed the length of a Twitter message if an apparent functional equivalent with more legal rigor exists, for obvious reasons.
Another is that the people who created licenses without any legal rigor were typically hobbyists who either couldn't be bothered to think about licensing matters beyond thinking "maybe this should have some kind of license statement" or simply did not have the means and available precedent to do a more careful job of it.
A third is that projects tend to get more contributions when they come with licenses that large corporate organizations with many lawyers on staff "like", and those are not likely to be licenses with no legal rigor to them at all.
Of course, getting lawyers to write all your licenses for you may not be a great idea. For one thing, that would tend to mean that only two groups will create licenses, because it is typically only they who can afford that kind of service: publicly traded corporations and organizations like the Free Software Foundation (and those it deigns to favor with its advice). Both big corporations and those groups the FSF favors are subject to suspicious motives, of course, and generally produce licenses that may make the rational and reasonable among us (those of us who favor license simplicity) feel a bit nauseous, or at least dizzy.
Let us not forget that the professional's propensity for producing five thousand word legal documents with the stated intent "share" does not strongly correlate with licenses whose legal rigor is quite as effective as we would like, as such licenses tend to be filled with gotchas and unintended consequences. As such, far more important than the aid of legal professionals in drafting a license is understanding why existing licenses are written using the forms and phrasing that they use, simplifying the license as much as reasonably possible to avoid the pitfalls of misunderstanding the terms used in a license and their legal intent, and being clear and unambiguous in the drafting of the license. Being a bit obsessive-compulsive about language and meaning in general helps as well.
It is difficult to find people who really grasp the intricacies of licensing legal rigor and are still willing to write their own licenses, outside of the legal profession at least. This is as it should be; anyone should be hesitant to embark on the project of writing new licenses when existing licenses may actually suit the needs of the moment, if those existing licenses have broadly accepted interpretations, and especially if those licenses have been tested in court or at least vetted by myriad lawyers and generally deemed worthy.
For this reason, the MIT/X11 License and Simplified BSD License are among the most popular licenses in the open source software world right now. In fact, the only thing that really seems to be wrong with those licenses for general use is the same thing that prompts the creation of non-software licenses such as the FreeBSD Documentation License, which is specifically oriented toward works using the FreeBSD documentation process, just as the Simplified BSD License (aka FreeBSD License) is specifically oriented toward software development. If a category-nonspecific license such as the Open Works License were used instead of the Simplified BSD License, there would be no need for the FreeBSD Documentation License, but we are only now in the adolescence of open source software development and the difficulties involved in category-specific licensing (such as licenses whose language are dependent upon an assumption that the license applies only to software, and perhaps its documentation) are only just beginning to be recognized by more than a handful of open source developers around the world.
Unfortunately, no comparable popular licenses containing open patent clauses came into being over decades of open source software development history. The simplest, most permissive, generally recognized license to contain such a patent clause for a long time was the Apache License, and in its first major version it was not even compatible with the GPL, which greatly hindered its adoption. Apache License 2.0, also known as AL2, has had some improvements made relative to the original Apache License version (including compatibility with exactly one major version of the GPL family of licenses), but it also got somewhat lengthier in the process. In addition, while AL2 is generally considered "permissive" by many software developers, that seems to be entirely based on the facts that it is an open source license and it is not a copyleft license, rather than because it is actually at all comparable to the Simplified BSD License or MIT/X11 License. In fact, the Apache License 2.0 has at times been referred to as a "BSD-like license" despite its complexity and the inconvenience of its requirements, including such gems as:
incompatibility with the huge body of GPLv2 code in the world
its bookkeeping clause
its project organization clause
After all these years, it is about time we get a proper solution to the need for a copyfree license with a patent clause.
The Work-Arounds: Dual Licensing And Separate Patent Licenses
To be fair, there are "solutions" to the problem that have existed for a long time, but the two big options for this are kludgey, ugly, and subject to some legal limitations. In one case, the limitation is the option for downstream users to remove either the simpler licensing terms from distributions of a modified work or remove the patent clause terms. The other case is potentially subject to some legal questionability, given the importance of a copyright license grant used as a lever to force patent grants from contributors. When people choose licenses with patent clauses, it is typical that neither set of legal limitations is intended by the initial licensor.
The probably better of the two work-arounds is dual licensing. This approach involves distributing a piece of software with a choice of terms, where the recipient can choose to accept the terms of either of two licenses -- one copyfree license and one license with a patent clause -- and even to offer it to others with the same choice available. The project distributor who wants both copyfree licensing and a patent clause to apply, and uses a dual licensing scheme to achieve these ends, must then insist that all contributors either assign copyright to the copyright holder for the original project or submit their contributions under terms offering the same license choice. This ensures that the contributor both allows the project to be distributed under the terms of the copyfree license and makes the required patent license grant.
The probably less desirable work-around is that of including a separate, distinct patent grant license, which essentially amounts to the same thing as the dual licensing option with two exceptions:
Instead of a choice of license, this approach mandates that both licenses apply.
The patent license is stripped of essentially everything except the use of copyright as a lever to "force" contributions to come with grants of patent license.
This second work-around is a tricky approach to take when using existing licenses for the copyfree portion of the conjunctive dual licensing scheme at least because of the lack of any body of legal knowledge and accepted practice in this area, and largely pointless because of the fact it essentially involves writing a new license anyway so that the smarter thing to do at that point would be to just create a single new license and use that.
The Solution: Tesla COIL
A license intended to fill the hole in copyfree licensing where a patent clause should be does exist, though it came along fairly late in the game. It was written with several key goals in mind.
It should have a patent clause.
It should be copyfree and maximally compatible with other licenses.
It should not be category-specific, so that it can be used for more than just software.
It should be very simple.
It should not be particularly vulnerable to legal gotchas and unintended consequences.
One additional goal, implicit in the inspiration for its creation in the first place, is to displace the Apache License 2.0 as the preferred "permissive" license with a patent clause. The license in question is called Tesla Copyfree Open Innovation License, often shortened to Tesla COIL or just COIL. The Apache License vs COIL article at WikiVS addresses the differences between the Apache License 2.0 and the COIL, and a general picture of the benefits of using the COIL over using the AL2 emerges pretty clearly.
Next time you think about licensing and think of patent clauses, you should think of the COIL instead of the AL2. Expanding upon the information presented in Advancement Through License Simplicity, you can easily see the textual simplicity advantage of the COIL over two other licenses with patent clauses:
> wc *
185 1583 10394 al2.0.txt
225 5644 34664 gplv3.txt
27 233 1533 tcoil.txt
1706 20807 131985 total
al2.0.txt = Apache License 2.0
gplv3.txt = General Public License Version 3
tcoil.txt = Tesla Copyfree Open Innovation License
The simplicity advantages in compliance, understanding, and use are even more significant.
written: 2013-04-18