This post was first published on the blog, Copyleft Currents.

For years, my clients have asked me what to do about the “Good not Evil” license, which is most famously applied to JSON (JavaScript Object Notation), a widely used format for storing and transporting data between servers and web pages.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. The Software shall be used for Good, not Evil. – https://www.json.org/license.html

A reader could be forgiven for missing the problem in that clause. That license is essentially a conventional MIT-type license until its last line: The Software shall be used for Good, not Evil.*

This license is widely understood to violate the open source definition. The FSF’s page “Various Licenses and Comments about Them” makes this comment about the JSON license: “This is a restriction on usage and thus conflicts with freedom 0. The restriction might be unenforceable, but we cannot presume that.”

FSF’s comments represent the prevailing view about a class of licenses that might be called ethos licenses. They are open source licenses, overlaid with restrictions or conditions that are intended to change licensee behavior according to the licensor’s political beliefs. Freedom Zero, the most important quality of free software licenses, is “The freedom to run the program as you wish, for any purpose.” Its analog in the Open Source Definition straddles a few of the elements of the definition, such as “No Discrimination Against Fields of Endeavor.”

Nevertheless, the JSON license has resulted in little practical controversy, because most users could convince themselves that they were not engaged in evil activities.

More Ethos Licensing

In the last couple of years, there has been a spate of new ethos licenses. They have ranged from DIY “crayon licenses” (the pejorative term used to refer to licenses drafted without benefit of any professional license drafting experience) to sophisticated attempts to be open source licenses or something like them. Here is a list of the ethos licenses that have received the most attention.

Anti-996 License . A professionally drafted license with its own GITHUB discussion page, Anti-996 was intended to address working conditions for software engineers and others by requiring licensees to adhere to local labor laws, or at a minimum, the UN “Core International Labor Standards” which include prohibitions against human trafficking. “996” refers to a working day of nine a.m. to nine p.m., six days per week. This license remains the most professional and serious ethos license out there.

. A professionally drafted license with its own GITHUB discussion page, Anti-996 was intended to address working conditions for software engineers and others by requiring licensees to adhere to local labor laws, or at a minimum, the UN “Core International Labor Standards” which include prohibitions against human trafficking. “996” refers to a working day of nine a.m. to nine p.m., six days per week. This license remains the most professional and serious ethos license out there. Anti-ICE License . A “crayon license” that was issued and quickly withdrawn, this license purported to withdraw permission to use the software to any organization that contracted with US Immigration and Customs Enforcement.

. A “crayon license” that was issued and quickly withdrawn, this license purported to withdraw permission to use the software to any organization that contracted with US Immigration and Customs Enforcement. Hippocratic License . This license requires the licensee to use the software to do “No Harm: The software may not be used by anyone for systems or activities that actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of other individuals or groups, in violation of the United Nations Universal Declaration of Human Rights.” It clearly violates Freedom Zero.

. This license requires the licensee to use the software to do “No Harm: The software may not be used by anyone for systems or activities that actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of other individuals or groups, in violation of the United Nations Universal Declaration of Human Rights.” It clearly violates Freedom Zero. Vaccine License. This license was professionally written, addresses the needs for vaccination and an implied disdain for the anti-vax movement. It was submitted to OSI in October, 2019, resulting in a fair amount of discussion on the OSI discussion lists, but its chances for approval are probably nil. The license was submitted under the name Filli Liberandum, which roughly translates as “free the children.” The anonymity of the submission caused as much controversy as its content, and some have posted that it was submitted to test OSI’s appetite for ethos licenses.

The Arcane but Crucial Difference between Restrictions and Conditions

Comparing the Anti-996 License and the ICE License illustrates some of the controversy over ethos licensing and the OSD. Of the licenses listed listed above, Anti-996 comes the closest to meeting the open source definition. It is a thoughtfully drafted document, and its authors include a WIKI explaining some of their drafting choices. Its development team says it is “designed to be compatible with all major open source licenses.” The conditions of the license say:

The individual or the legal entity must strictly comply with all applicable laws, regulations, rules and standards of the jurisdiction relating to labor and employment…. In case that the jurisdiction has no such laws, regulations, rules and standards or its laws, regulations, rules and standards are unenforceable, the individual or the legal entity are required to comply with Core International Labor Standards.

While this is properly written as a condition rather than a restriction, the license is thought by some not to be OSD compliant, perhaps because the conditions do not relate to the use of the software or the exercise of the copyright. The license was never submitted to OSI for approval, so the isuse of its OSI compliance was never examined in detail. Moreover, this license is clearly not compatible with GPL, because it imposes conditions that are not in GPL, and GPL expressly prohibits imposing additional conditions.

In contrast, the ICE license prohibited use by any organization that contracted with US Immigration and Customs Enforcement and specifically banned 16 organizations, including Microsoft, Palantir, Amazon, Northeastern University, Johns Hopkins University, Dell, Xerox, LinkedIn, and UPS. The project to which the license was applied, Lerna, had not been implemented by all of these companies. The license has been withdrawn but its pull request for the project is here. This prohibition was a clear violation of Freedom Zero. The prohibition had been applied by one of the developers of the project, apparently without the consensus of other developers of the project, but with the approval of the core maintainer, who later stated:

Despite the most noble of intentions, it is clear to me now that the impact of this change was almost 100% negative, with no appreciable progress toward the ostensible goal aside from rancorous sniping and harmful drama….I am reverting the license changes. In the future, such changes (if any) will go through a much more thorough, completely public, and fair-minded process.

The project withdrew the modified terms and kicked the developer out of the project for various conduct violations.

Access vs. Licensing

But licensing is not the only tool in the developer/activist’s arsenal. Take, for example, the problem caused earlier this year in the Chef development product environment.

In September, 2019, the developer of an open source Ruby library called Chef Sugar (a Ruby library useful for Chef) pulled his code down from his personal repository, where the code resided stating that “Chef was found to have entered into an agreement with US Immigrations and Customs Enforcement (ICE), best known for their inhumane treatment, denial of basic human rights, and detaining children in cages.” The code was developed while the developer worked at Chef, but resided in the developer’s person GitHub repository; the developer had continued to maintain it after he moved to a different company. The takedown of the code resulted in broken links that disrupted the use of Chef in the field. Chef quickly restored the code to a different repository. The controversy continued, however, until Chef promised not to renew its contracts with ICE.

This disruption echoed an earlier takedown that “broke the internet” by removing a very simple white space padding routine (left-pad) on the popular NPM repository, a massive code development platform used to locate open source Javascript dependencies. Ironically, this disruption happened because of a trademark dispute between the developer and a company that asked him to rename a routine he had posted to NPM. The dispute became heated and profane, NPM joined in asking the developer to rename his routine, and the developer reacted by simply removing his code from NPM. (The dispute was characterized by the developer as a patent dispute, but that does not appear to be accurate.) The takedown included not only the routine that was the subject of the dispute (kik), but the 11-line left-pad. Suddenly, many software packages would no longer build properly. left-pad was a dependency — direct or indirect — for many software packages. The alternative package left-pad.io was created, and the issue was soon solved, but not before wreaking havoc for a day or two. The left-pad crisis was not an overtly political dispute, but it demonstrated that build chains are only as strong as their weakest link, and those links may be subject to the whims of developers, political or not.

What Works, and What Doesn’t

There is a war of ideology at work here. Free and open source software is built on the premise that use of software should be like free speech: without moral and political judgement that function like a prior restraint. Today’s developers, however, being just as politically polarized as the society at large, prefer to impose their ethical strictures upon others. While the two approaches are mutually exclusive, open source philosophy has already won. But a few things are clear.

First, ethos licensing inevitably results in a crazy quilt of incompatible, possibly unenforceable, and often vague restrictions. As a result, the most likely result is that no one will adopt software under such licenses. The administrative burden of ensuring compliance is significant, even if the user is morally upstanding. That adds to the already non-trivial cost of open source compliance, and most users will weigh the costs as heavier than the benefits of using the software. I have not yet had a client ask me whether it is compliant with the Hippocratic License, but I doubt any lawyer could responsibly answer that question.

Second, ethos licensing tends to focus on political issues that, by their nature, are ephemeral in the grand scheme of things. Even if one agrees that a company should not supply tools to ICE in 2019 because doing so facilitates inhumane treatment, what happens when ICE changes its policies? What if vaccinations become obsolete due to gene therapy? The license restrictions in ethos licenses may be a cure that outlives the disease — they will persist long after their justification is gone. Those who have tried to write open source licenses know how difficult it is to write terms that will work for the foreseeable future. Licensors may assume that, once conditions change, they can then re-state the license terms. But that is an assumption that only young people make. Unfortunately, licensors, too, are ephemeral, because we are all mortal. Developers who want to create a legacy with the fruits of their labor needs to think about the effect of their actions in the long term.

Third, ethos licensing is not an effective tool to control behavior. If ethos licenses impose license conditions, then the only real remedy for violating them is an injunction not to use the software. There is no legal mechanism to curb immoral behavior, nor compel good behavior, with a license condition.

Fourth, ethos licensing is ineffective in gross. What actually works best is good old-fashioned advocacy. For example, the Anti-996 License was as much an exercise in advocacy as in licencing, and it generated robust interest and discussion about working conditions. And the Chef/ICE issue had a real result, but not because of the takedown, which was ultimately toothless and at most mildly disruptive; it happened because of the concomitant advocacy, mostly by those in the community at large.

In short, ethos licensing is a publicity stunt. If we believe in free speech, then we must acknowledge that people can write whatever licenses they want in order to garner attention. But developers should not be so quick to trample Freedom Zero, which is an idea so powerful that it has fundamentally changed the world.

* Lexicographers might ponder why the terms “Good” and “Evil” are capitalized. If you think this does not matter, you are not a lawyer! Perhaps the author spoke German as a native language, or was referring to avatars of good and evil? But no, the capitalization is probably not the key to understanding this license.