The Rise of Nonstandard Open Source Licenses Sparks Debate

The open source community is debating how free open source licenses should be. The debate, two years in the making, has its roots in dual sources of discontent: Some open source vendors are upset because open source license terms are getting in the way of them making money, while some developers are upset because their software is being used by "bad" people towards bad ends.

As a result, developers and vendors are now dealing with a spate of new "open source" licenses that are open source in name only. Developers and vendors can call any license they come up with "open source," so long as they don't say their license is “OSI approved.”

The Open Source Initiative, or OSI, is the organization that in 1998 came up with the "open source definition" – a list of ten items that specify what a software license needs in order to qualify as open source. These days, the OSI functions as something of a standards organization, and a software license must bear the organization's stamp of approval to be accepted as a bone fide.

The problem is that these non-standard open source licenses can make things tricky for IT departments.

"IT departments in particular have gotten very used to the idea that if we got it from an open source repository, something like NPM for JavaScript packages or PyPI for Python packages, then we have the core OSI or FSF permissions – right to use, modify, redistribute – and that's a very low-friction environment to live in," Luis Villa, co-founder of open source compliance and support company, Tidelift, told IT Pro Today. "If you're an IT person, you know that everything you got from those sources might have little details here and there, but the basics are very simple, very straightforward and very low friction for you as an administrator of systems. But these near open, or open but not quite open, licenses are showing up in a lot of these same repositories. All of a sudden, there are very rough edges."

A lot of the "rough edges" can be made worse by the fact that many of these licenses advertise that they are "based on" well-known OSI approved licenses, which can lead to the assumption that they play by the same rules. Finding out otherwise can be costly.

MongoDB's Server-Side Public License

The current spate of faux open source licenses began in October of 2018 as an attempt to solve a business problem when the open source database company, MongoDB, changed its license from the AGPLv3 license to something Mongo calls the Server Side Public License (SSPL). The reason for the change was to address an issue the company was experiencing with cloud providers that were using MongoDB code as the backbone to hosted software-as-a-service versions of the database without sending any cash or contributions to Mongo.

"The market is increasingly consuming software as a service, creating an incredible opportunity to foster a new wave of great open source server-side software," said Eliot Horowitz, MongoDB's co-founder and then-CTO, at the time. "Unfortunately, once an open source project becomes interesting, it is too easy for cloud vendors who have not developed the software to capture all of the value but contribute nothing back to the community. We have greatly contributed to – and benefited from – open source, and we are in a unique position to lead on an issue impacting many organizations. We hope this will help inspire more projects and protect open source innovation."

For most users, the terms of the SSPL are unchanged from the AGPLv3, and only affect SaaS operators who must either purchase a commercial license or open source all of the software they're using to support Mongo as a Service. Neither of these caveats are permitted by the Open Source Definition, specifically the ninth point, which states, “The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.”

The MongoDB folks made several modifications to its license in an attempt to get OSI to approve their license, but eventually withdrew SSPL from the approval process when it became obvious the license wouldn't be approved. However, MongoDB continues to use the SSPL to license its database.

Cockroach Labs' Business Source License

In June of 2019, another open source database company, Cockroach Labs, switched the license on its flagship product, CockroachDB, from Apache License version 2 to something it calls the Business Source License (BSL). In this case, the company isn't even pretending its license qualifies as open source, and refers to it as a "source available" license.

As with MongoDB's license, the change doesn't affect users unless they use it for a commercial SaaS offering.

"CockroachDB users can scale CockroachDB to any number of nodes," the company said in a statement. "They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license."

The issue speaks to the continuously evolving software licensing environment that IT departments are forced to deal with, said Tidelift's Villa.

"In the early days, understanding all your licenses was easy, because there were only five of them. You had a LAMP stack; you needed to know four licenses and you were good," Villa said.

"As we got more complex ecosystems, it got very complicated again and you had to track dozens or hundreds of licenses. Then we have a whole bunch of tooling – Black Duck, Tidelift, that kind of thing – so it's gotten easier again. Now we're adding a whole bunch of complexity to the licensing layer and the pendulum has swung again. Presumably, the tooling will help with that and we'll catch up and help with that. But exactly what form it takes is something we're still figuring out."

Ethical Software Licenses

Not all attempts to create open source licenses that break the mold have been to protect business interests. For example, at about the same time that Cockroach Labs was changing its license, Coraline Ada Ehmke, the creator of Contributor Covenant (the code of conduct used by Linux and other organizations) came up with the Hippocratic License, a modified MIT license that seeks to assure that software is only used for ethical purposes.

"Politics and software are so tangled that they cannot be reasonably separated," Ehmke wrote on the license's website. "Consider the GPS software that tells you how to get to a restaurant; it’s also used to direct military drones to their targets. The facial recognition software that unlocks your phone? It’s being used to record, track, and target the activities of political dissenters."

The license seeks to address these issues by forbidding use of software covered by the license to violate human rights principles as spelled out by the United Nations or human rights laws in any jurisdictions. This intent contradicts the sixth item in the OSI’s open source definition: “The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.”

The Hippocratic License is far from being the only attempt to address moral, political or ethical issues through software licensing.

Indeed, around the same time that Ehmke was creating the Hippocratic License, she founded the Ethical Source Movement to advocate for other ethical licenses. Examples include the Do No Harm License, which prohibits using covered software to promote or profit from violence and hate, environmental destruction, or to cause physical or mental injury; Atmospheric Licenses, which come with fossil fuel divestment provisions; and the (Cooperative) Non-Violent Public License, which “aims to ensure basic protections against forms of violence, coercion, and discrimination which creations are frequently leveraged for in the modern world. This license covers several formats of creative work but has extra terms for software given the power it has as a tool outside of its creative capacities.”

One of the problems with ethical open source licenses is that their caveats tend to be vague, which could possibly lead to difficulties down the line. As an example, Villa pointed to the first "ethical" license, the JSLint license, which was the MIT license but modified with the single line, "The Software shall be used for Good, not Evil."

"All it takes is one JSLint contributor under that license to really throw spokes in the wheels, so that's definitely true of the ethical licenses, but I think it's also true of business and even traditional open source licenses as well. It's just a question of who takes advantage of that vagueness."

None of these licenses have been approved by the OSI, and it's unlikely they will. The general consensus is that the problems these licenses are trying to solve fall outside the scope of mere software licensing.

Although Ehmke has said that she intends to eventually submit the Hippocratic License to OSI for approval, OSI's president Joshua Simmons says so far that hasn't happened. He added that if it is eventually submitted, approval would be unlikely.

"My personal view is that it won't pass muster," Simmons said. "Discussion of the license and others like it have identified a number of issues that would need to be addressed, and I suspect that some of those issues can't be addressed without fundamentally changing the license."