Setting the stage
Much of the current discourse on software licensing is about monetization. Work on free software does not lead to a sustainable form of income for the people making it. This had led to a myriad of solutions proposed, including novel licenses, some of which almost certainly are closer to proprietary software than free software, reviving the requirement to closely differentiate between “free software” and “open source software” in everyday parlance. Much digital ink has been spent arguing about fair compensation and how to achieve it by means of open source software licensing in particular, weighing enforcement thereof against the very real chance of being unable to see any fruit of one's labor due to a particular license hampering adoption in the first place.
That is, however, not what this post is about. I would like to take a look at the other end of the spectrum: maximally permissive licensing. What I mean with the term “maximally permissive licensing” is any form of making available your code with no conditions attached to it other than the usual disclaimer. This means no attribution, no license notice, nothing at all (please note that I will take the liberty to use the word “attribution” to also include the requirement to provide a license notice along with the software, not only individual attribution). Downstream recipients may just take the code in whole or in part and move on with their lives; in essence, a downstream recipient has no obligation to actively act a certain way and only the passive obligation refrain from holding liable the author.
Most of the open source marketplace has standardized on roughly four categories of licenses:
- the GPL family (LGPL, GPL, AGPL, each commonly found in 2.0 and 3.0 versions),
- the group of weak copyleft licenses (MPL, CDDL and Eclipse Public License),
- permissive licenses with explicit patent license grant (Apache-2.0), and
- permissive licenses with no mention of patents (MIT, ISC and the BSD license family).
Of interest for this post is a fifth category, which appears to consist exclusively of the following five legal tools, that I'm tentatively dubbing maximally permissive licensing:
- plain public domain declarations,
- Creative Commons Zero (CC0),
- the Unlicense,
- the WTFPL, and
- the BSD Zero Clause License.
The astute reader with any amount of familiarity with copyright law may (and should) protest the notion of muddling public domain declarations with the term “license” as the very notion of licensing and public domain declarations are per se mutually exclusive in the first place. It is, of course, a valid objection, but the same astute reader may also observe that there seems to be no term to refer to this same general concept, which necessitates a choice of term for this concept in the first place; suggestions for better names would certainly be welcome.
The fact that this fifth category of software licensing (in a broad, non-technical sense) exists but has not caught on might already prove that there is not much interest in this category in general. While I leave it up to sociologists to determine how many people really care about attribution when releasing code under the MIT license, I wish to draw attention to the current options and that they seem to me like they are ultimately unsatisfactory for everyone involved. To this end, I wish to examine the five forms of maximally permissive licensing mentioned above and how they stack up, particularly in light of droit d'auteur (authors' rights) jurisdictions that interweave personality rights with copyright (in a broader sense) and the Blue Oak Council's license list. For an introduction to open source software licensing, I suggest the Blue Oak Council's Open Software Licensing Primer; I assume and expect readers to have a solid understanding of the concepts outlined therein.
Why bother?
Looking at the economic backdrop of the current licensing discussions, it may indeed be difficult to understand why one might be dissatisfied with common permissive licenses that include attribution requirements. Nonetheless, I believe there to be several legitimate reasons why it is desirable to exist.
For one, the author may just have no interest in the attribution at all. When the author's livelihood is entirely independent of their creation, they have no intention of any kind of maintenance and the code is sufficiently trivial, it may seem easier to just “get rid of” all this copyright nonsense than hanging on to it and be – perhaps years or decades later – in the way of someone else's use that you hadn't even thought of at the time.
Another case to be made is the one for simplicity of compliance.
It is no secret that license compliance with permissive license is lacking,
particularly in the small and medium enterprise space.
You could perhaps stroll into a large conference hall at a conference of your
choice and select a few dozen developers to ask how to comply with the MIT
license.
I would not find it strange if at least one person would assert that there are
no strings attached or replied only with the disclaimer.
Instead of continuing poor community practice of disregarding the terms of
permissive licenses entirely,
As one such example of insufficient amounts of attention being paid to this
issue,
I would like to observe that
rust-lang/rust#67014,
which asks about the documentation that is legally required to be shipped,
is unresolved since December 2019 (two years and counting!).
Similarly, the Rust cargo license subprogram is not,
despite Rust dependency graphs easily spiraling into dozens of individual
packages for which manual review quickly gets strenuous.
It would be a net efficiency gain if people who don't care about attribution
actually licensed that way,
but maximally permissive licensing has not entered the collective mainstream,
perhaps precisely because of the unsubstantiated myths surrounding the MIT
license.
Finally, obligations to ship a license notice and do attributions may hinder adoption. This may particularly be the case with simple, but not trivial, libraries. If the license terms are close to the length to the code in question, it may seem easier to just rewrite the code and not have to bother keeping track of yet another license; particularly with regards to languages that have poor dependency management tooling, the temptation to rewrite may be all the greater. Unfortunately, this bears the risk of subtle bugs being introduced that the now-eschewed library has long since identified and fixed.
An unsolvable problem?
While open source software development is highly international and oftentimes entirely ephemeral to the point that questions like “Where is the Linux kernel development project even located anyway?” are questions that no software developer would even ask, realizing that there is no point in doing so. Legally, on the other hand, the physical locations of things, even intellectual property, is a rather relevant question and, if anything, lawyers appear to have severe difficulty grasping the nature of open source development and the frequently hugely informal structures underpinning even massive projects. This international aspect leads to the issue that software licenses need to be written for every jurisdiction at the same time, even ones whose existence the license authors may not even know of.
In that sense, drafting license terms is an unsolvable problem in the first place. With at most very general principles of law and the meager provisions of the Berne Convention for the Protection of Literary and Artistic Works to guide the creation process, it is more than challenging. Highly intricate solutions to specific worries or problems may end up not working in the first place – and that's assuming courts in some faraway jurisdiction don't throw out the case outright by not accepting the notion of a general public license (or having to severely warp it to fit local laws). Licenses (and public domain waivers) thus need to account for several issues.
But even known problems can seem insurmountable. Recall that I'm looking for a legal construction that allows maximally permissive software licensing. Recall also that some jurisdictions, such as Germany and France, split copyright into moral rights and economic rights. While moral rights are part of the author's personality rights and thus may neither be waived nor transferred, economic rights can be. Moral rights usually include the rights to being attributed as the author. This runs directly counter to the goal intended.
Perhaps a way out could be the concept of estoppel or the civil law concept venire contra factum proprium. Nonetheless, depending on the weight given to the personality rights (and as such the moral rights in the context of copyright) by courts, a fight for attribution may still end with the moral right prevailing over the contradictory behavior of the one having previously explicitly waived their right to attribution. Considering that it is exceedingly unlikely that there may be found a person who so stubbornly refuses to honor the author's wish for attribution to the point that it be brought to court in light of the cost–benefit being overwhelmingly skewed in favor of compliance, we may likely never know of practical examples; if there are any, I certainly know of none, and would be most delighted to be informed thereof.
This being the background to the issue at hand, I conclude that the problem of maximally permissive software licensing is indeed unsolvable in the general case. It is, however, possible to make an effort, if only to clearly communicate intentions.
Individual legal tools
Plain public domain dedications
Now let us turn our attention to plain public domain dedications. One such example may be found on the website of Professor Daniel J. Bernstein, whom I hope not to offend by being picking his website as an example: https://cr.yp.to/distributors.html. One such dedication reads as follows:
2018.07.29: I hereby place the checkpassword package (in particular, checkpassword-0.90.tar.gz, with SHA-256 checksum 74300364
b6be26be 08e34f76 8532e911 78982717 9e680bc8 9db3525f e415762f) into the public domain. The package is no longer copyrighted.
Given nothing but the statement above, it is quite simple to determine the exact code package. Even ignoring more asinine interpretations (such as the package as a whole, i. e. as a collection being placed in the public domain rather than the package and the individual files contained therein), I believe it remains ambiguous whether moral rights or only economic rights have been waived, especially if you moral rights are considered to be fundamental part of personality rights that may never be waived. If so, then there may be an implicit condition (perhaps geographically restricted to parts of the world with moral rights in the context of copyright) to attribute the author. Furthermore, what happens in jurisdictions that reject public domain dedications per se? Indeed, while a public domain dedication seems seemingly refreshingly simple, complexity quickly creeps in.
The issue of other intellectual property rights, such as patents, is generally not addressed by these dedications. Is such a dedication an implicit patent license? What about trademarks? Does such a dedication not affect patents at all and thus invite a patent landmine? This issue is exacerbated in the context of standardization, where a patent holder of standards-relevant patents may make available their reference implementation under such broad terms.
Another issue that arises is liability. Assume a jurisdiction in which the public domain dedication is not accepted as a waiver of rights (and thus, without speaking in a legal sense, making the code the effective equivalent of roadkill for liability purposes), but rather re-interpreted as a rather broad grant of copyright license.
In light of such ambiguities, I believe that simple public domain dedications are insufficient, although their simplicity seems attractive.
Creative Commons Zero (CC0)
The CC0 1.0 Universal Public Domain Dedication largely avoids the issues of a simple public domain dedication as outlined above: it has a clear waiver, it provides a broad public license as a fallback in case the waiver is not recognized, it contains a disclaimer and it mentions trademark and patent rights. Having said that, it does have two issues, though the first issue much more severe than the second. Unlike all other legal tools mentioned in this text, CC0 explicitly excludes any effects on trademarks and patents; its section 4.a actively prevents a patent grant. Creative Commons notes that they had not set out a public domain waiver for software. By virtue of being the only reasonably complete public domain dedication, it quickly found some amount of adoption nonetheless. This is also the reason that the Open Source Initiative (OSI) has failed to find consensus on whether to approve CC0 and even discourages its use without suggesting an alternative.
However – and that is the second issue –, it is also evident that Creative Commons does not consider software to be a first-class citizen in their offerings. While this is hardly a surprise considering that the other licenses are indeed a poor fit for software, even for CC0, the instructions how to apply CC0 to software have been banished to a section on their wiki's CC0 FAQ page. This is not very discoverable and may discourage people. There are feelings of comfort and safety in the knowledge that a legal tool is actually designed for the purpose you're trying to use it for.
It is thus clear that CC0 is stuck between a rock and a hard place, not designed for software but adopted anyway for the lack of better alternatives. The patent issue may not be much of a worry when you know ahead of time that you do not have to care about patents (for example because the author also happens to be a notoriously militant opponent of patents or because the code is so old that any patent must have expired in the meantime).
The Unlicense
Another attempt at unburdening recipients of the code of any obligations is the Unlicense. Despite what the name might suggest (pro memoria: falsa demonstratio non nocet), it is a public domain dedication like the principal idea of CC0. It is clear about its intent – at least when applied to individual files – and contains a disclaimer. What it lacks, however, is a fallback license like the CC0. The effect of a failed public domain dedication without a fallback license may lead to unexpected consequences; if a court does not re-interpret it to mean a public license instead, it may rule the Unlicense to be null and void, leaving the recipients with no rights to the code whatsoever. Since this is a terrifying thought, the Unlicense appears to be rather unpopular with certain legal teams.
Other intellectual property rights, namely patents, are not mentioned. While this is can lead to at least possibly implied patent licenses, and is indeed a clear step up from the CC0 explicitly not granting any patents, it is nonetheless dissatisfying. Ignoring whether patent fears in software are relevant to your use of the code, it is observable that there is a trend towards adoption of the Apache-2.0 for its patent grant clause and defensive patent mechanisms.
Considering this, the Unlicense is not a solution for the problem at hand.
The BSD Zero Clause License (0BSD)
The BSD Zero Clause License (0BSD) takes the well-known ISC license (interestingly not the BSD license) and removes the “provided that the above copyright notice and this permission notice appear in all copies” passage. Unlike everything mentioned thus far, 0BSD is a license, not a public domain dedication. In practical terms, this may perhaps not make a difference. In terms of legal hair splitting and ideological purity, a license with no conditions is incompatible with code that is intended to be placed in the public domain since then parts thereof would still be covered by someone's copyright. Like CC0 and the Unlicense, it contains a disclaimer. Like the Unlicense, it does not mention other intellectual property rights, namely patents.
Ignoring this sub-division in maximally permissive licensing, the 0BSD license suffers clarity issues that are only resolved by understanding its genesis. Recall that authors may, in some jurisdictions, have moral rights that cannot be waived. While the concepts of estoppel and venire contra factum proprium may have some effect to perhaps make a waiver effectively possible to some extent, the lack of conditions is merely implied in the 0BSD license. As such, a recipient of the code has no defense (except perhaps the origin story of the 0BSD license) against someone going rogue and changing their mind on the software released without any requirements for obligation.
Considering this, the 0BSD license is not a solution for the problem at hand and instead creates a new problems of inter-compatibility between maximally permissive terms.
The WTFPL
The WTFPL (Do What The F*ck You Want To Public License) deserves a mention for having similar intentions as the 0BSD license. Like the 0BSD license, this is a license, not a public domain dedication, with all the implications that come with it. For my purposes, it is essentially the 0BSD license, just with significantly more offensive wording.
Downstream hygiene: A de-facto requirement of attribution?
Assuming that at least one of the options above has been chosen and they actually work as intended, downstream now has a blob of code they can use without any active obligations and only passively being required not to hold liable the authors (to the greatest extent allowed by applicable law anyway, which is an entirely separate beast that hopefully never rears its head).
Since the issue of public domain dedication is contentious, downstreams would be well-advised to keep track of the source code origins in a source code bill of materials, even if they fervently believe that they can just integrate the code as if it were genuinely theirs. This leads to the perverse situation of having a de facto obligation to keep the license and its notice around, at least in source code form. This is not actually an issue, but I can't help myself noting this here. A similar issue arises out of a defensive angle: If ever challenged on the “ownership” of the code (whatever the precise notion may be when it happens, be it for liability reasons, be it for other reasons), keeping the original information around is essentially imperative as otherwise it becomes impossible to differentiate between code genuinely written and code taken from others.
Conclusion
I sincerely believe that we are in need for some kind of public domain dedication with fallback license akin to CC0 but with clear and explicit patent wording. Considering the popularity of the Apache-2.0 license for its patent license, it may be worth marrying the two licenses. Could someone just graft the patent language from Apache-2.0 onto CC0? Perhaps. Maybe there ought to be two versions (one with defensive patent language and one with just a clear patent grant) instead?
I could also imagine instead basing it off of the Blue Oak Council's model license, but alter the “Copyright” section to be a waiver with fallback license; I note, however, that this is may perhaps not lend itself well to the simple and concise language the Blue Oak Council's model license uses. Then the “Reliability” part needs adjusting and “Excuses” becomes moot entirely.
Is license creation by copying and pasting a good idea? I don't know, probably not. I'll leave the license drafting to people who know what they are doing and are allowed to practice law. No good can come from ham-fisted attempts of laypeople to make licensing work on their own. Yet if we look at the people interested in these kinds of maximally permissive licenses, it is probably not the kind of crowd that wishes to retain the services of a lawyer for cost reasons, as there is certainly no money to be made.