This post covers my research into open source software licensing and my analysis of real-world open source projects that profit off of open source code via proprietary licenses.

Keep reading and you’ll learn:

• What the difference between a restrictive and permissive license is
• What dual licensing is and how you can use it make money off of open source code
• What CLAs are and the specific clause your CLA needs for use with dual licensing
• Examples of companies that implement dual licensing and how they do it

And of course: I am not a lawyer and none of this is legal advice.

---

Let’s talk evil. And by evil, I mean money.

Here’s a hypothetical scenario. Let’s say you write some code and would like to open source it. But, if someone uses it to make money, you want a cut. Nefarious, right?

This kind of thinking tends to be taboo in open source. In open source, you typically choose a license for your software and it is either restrictive (copyleft) (e.g. GPL) or permissive (e.g. MIT). Restrictive licenses require parties that redistribute the code — modified or unmodified — use the same license and release source. Permissive licenses do not have these conditions. They allow distributing under any license and not releasing source.

In either case, people are allowed to profit off of your work, without restriction. This is explicitly permitted in most open source licenses:

GPL:

d) Convey the object code by offering access from a designated place (gratis or for a charge)

https://opensource.org/licenses/GPL-3.0

MIT:

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:

https://opensource.org/licenses/MIT

Indeed, the general definition of open source from the Open Source Initiative (the organization that officially approves licenses as ‘open source’) explicitly protects the ability to sell open source software.

1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

https://opensource.org/osd-annotated

A license that restricts use of the software in commercial settings would not be considered open source, even if the code was freely available and you accepted contributions.

Is this it? If we open source our code, are we doomed to lose any chance of capturing profits generated by it? 

No, there is a solution: dual licensing. It is possible to license a codebase under multiple licenses, offer users a choice, and effectively force them to pay for a commercial license.

Dual licensing for profit… and profit

We can dual license our project under two licenses and offer users a choice. Let’s say we choose the GPL (a restrictive, copyleft license) and a non-open-source, commercial license of our own.

• The restrictive license is meant for casual users, hobbyists, and other members of the open source community. They’ll need to release source but they probably won’t mind.
• The commercial license is meant for the companies that want to sell our code. That’s where we’ll include our terms about getting paid and make our money.

The critical assumption is that companies using our code commercially will not want to release their source. Their source means both their modifications to our code and their proprietary application that links to our code. This will prevent them from using the copyleft license and their only other option (barring walking away) will be to begrudgingly contact us for a commercial license.

However, if they are somehow ok with releasing source, then we’ve been foiled. If they have somehow found a business model that allows them to both sell our software and comply with the GPL (release their code), there’s nothing we can do. But the idea is that this is rare.

Abuse of the GPL

To be clear, this technique is abuse of the GPL. The GPL and copyleft philosophy are foremost about freedom of source and the reality that the GPL is unusable for businesses just happens to be an unfortunate side effect. But for us supervillains who may or may not care about free software, this makes it the perfect tool. C’est la vie.

Subtle pitfalls with CLAs (Contributor License Agreements)

We’re not done yet. In order to dual license, we need full copyright ownership over the codebase. This is because we need to relicense the codebase under our commercial license, which gets tricky if we want to exploit free labor accept contributions.

By default, the copyright on an open source contribution stays with the contributor. This means we lose copyright ownership over the full codebase and can no longer relicense it in its entirety. To maintain full ownership, we need permission from each contributor.

We’ll institute a new system. Now, before anyone can contribute, they need to sign an agreement that either:

1. Transfers their copyright to us entirely.
2. Explicitly gives us permission to relicense their contributions (which remain under their copyright) under an arbitrary license.

The latter agreement is called a CLA (Contributor License Agreement). The former is a CTA (Copyright Transfer Agreement).

So where do you get a CLA? You can use a popular one like the Apache or Harmony CLAs but be careful, not all of them are appropriate for dual licensing.

The Apache CLA (pdf) should not be used for dual licensing because it does not specify a relicensing clause.

Subject to the terms and conditions of this Agreement, You hereby grant to the Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.

It does mention the ability to “sublicense” but this does not mean “relicense”. From what I could find, “sublicensing” is akin to “forwarding” existing license terms. Sublicensing permission does not allow for loosening existing license restrictions. (sources: 1 2 3)¹

Here’s an example. Let’s say we have a project on Github which is dual licensed between GPL and a commercial license, and uses the Apache CLA.

Contributions by default become GPL due to the Github terms of service. The Apache CLA gives the project owner the right to sublicense contributions. Since sublicensing does not permit loosening restrictions, when the project owner relicenses the codebase in a commercial license, that commercial license cannot remove the GPL restriction that requires source to be released. Therefore, the Apache CLA doesn’t give project owners enough permission to implement a dual licensing scheme.

Unlike the Apache CLA, the Harmony CLA, specifically with Outbound Option #5 chosen, will work. This is what Ubuntu uses. The Outbound License section specifies to what extent the contribution can be relicensed. Option 5 is the most permissive, allowing relicensing.

(Option Five) Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date.

So the quick answer is to use the Harmony CLA with Outbound License option #5 for dual licensing.

Time to make some money!

We’re finished. We have a clever scheme which lets us solve the paradox of being both an “open source” project while also restricting the ability of users to sell our code without giving us a cut 😈.

The only cost is that we have to enforce a heavyweight CTA/CLA. But most people just click through so this might be ok. Time to make some money!

Case Studies

MongoDB, Elasticsearch, Qt, and JUCE are “real life” projects that employ this scheme. Let’s look into how they implement dual licensing.²

MongoDB

The MongoDB database is dual licensed under a custom copyleft license, the Server Side Public License (SSPL), and commercial licenses. This is done to is to prevent cloud providers from freely profiting from running MongoDB as a service, especially without contributing back changes.

The SSPL is a near-verbatim copy of the AGPL variant of the GPL.

Let’s start from the top.

• The GPL requires you to release source when you distribute (“convey”) the code (i.e. ship it to a user in source or binary form). Interaction with running code via the network does not count as distribution. (GPL Section 0, Paragraph 7)³
• The AGPL does not change the source-release requirement nor does it change the definition of distribution (common misconception). It simply adds a special case (AGPL Section 13, “Remote Network Interaction”) that additionally requires source release if a modified version of the program is used over a network. (AGPL Section 13, Paragraph 1)⁴ Offering an unmodified version is allowed without source release. This subtlety points to the original goal behind the AGPL: to ensure modifications are always released (AGPL Preamble). This goal is consistent with the overall philosophy of the FSF and notably not a goal of being anti-commercial-use.
• The SSPL expands Section 13 of the AGPL to require source release for unmodified versions of the program that are specifically made “…available to third parties as a service.” (SSPL Section 13, Paragraph 1) Here we see a motivation beyond making sure all modifications are released. This is where the license begins to appear anti-commercial-use.

This is all to say that the SSPL is a highly restrictive license that puts pressure on would-be resellers to purchase a reseller license.

Note that it is always allowed to use MongoDB as a user and even run it in the infrastructure of your SaaS product. In this case, you are neither distributing MongoDB (the binary never reaches the user) nor are you offering it as a service to third parties. You are merely using it as a service for yourself.

MongoDB is also on Github and accepts contributions. To obtain permission to relicense contributions, their contributor agreement is a heavy-weight Copyright Transfer Agreement. When you contribute to MongoDB you completely relinquish copyright of your contributions.

Fun fact: MongoDB is technically not an “open source” project. This is because the SSPL was rejected by the OSI due to violating the core definition of open source (the part we looked at earlier protecting the right to profit off of open source software). So despite being on Github and accepting contributions, MongoDB is technically not open source.⁵

Elasticsearch

As of 2021, Elasticsearch and Kibana are dual licensed under the SSPL (see above) and a proprietary license. This is a nearly identical scenario to MongoDB — they wish to restrict cloud providers from freely reselling Elasticsearch as a service without contributing back.

The Elasticsearch CLA’s documentation claims that the CLA is “not asking you to assign copyright to us, but to give us the right to distribute your code without restriction.”

What’s interesting is that the actual CLA used seems to be the Apache CLA, which is not suitable for SSPL dual licensing as described above.

The Apache CLA used to be suitable back when Elasticsearch was licensed under the permissive Apache 2.0 license. This is because the Apache 2.0 license has few restrictions, so there was no need for Elastic to obtain permission to loosen the restrictions when it relicensed under its proprietary license.

However, now that Elasticsearch is licensed under the highly restrictive SSPL, they do need to obtain this permission. From my perspective, it would be highly advisable for them to immediately switch to a CLA that properly supports dual licensing with a restrictive license (such as the Harmony CLA with Outbound Option 5).

Qt

The Qt C++ libraries are dual licensed under the GPL and commercial licenses.

To gain permission to relicense, the Qt contributor agreement (pdf) explicitly gives permission for the Qt Company to “…distribute Licensor Contribution(s) and any derivative works thereof under license terms of The Qt Company’s choosing including any Open Source Software license.“

They opt for a contract less heavyweight than a CTA, but still more heavyweight than a standard CLA like the Apache CLA.

JUCE

Except for a few core modules, the JUCE C++ framework is licensed under a variety of proprietary licenses or the GPL.

Licensing is based on revenue generated by your entity using JUCE. If you exceed revenue thresholds, you are required to either pay for the next level’s proprietary license, or release your app under the GPL.

Despite being on Github, JUCE does not accept contributions. It appears there is no CLA, so this makes sense — since they cannot retain full copyright without one, they simply do not accept contributions.

Conclusion

Open source projects using a single OSI-approved license cannot force businesses to pay for commercial licenses. But this doesn’t mean they need to let businesses profit off them for free.

By licensing under both a restrictive & commercial license (dual licensing), open source projects can remain open source while effectively restricting use in commercial context. In order to do this, they must institute a heavyweight contributor agreement (CLA) that either explicitly assigns copyright or permits relicensing.

The MongoDB, Qt, and JUCE projects do this in real life and can serve as case studies for how to implement this yourself.

Appendix: Choosing a permissive license

This part is just for my own reference.

Let’s say you’ve decided you want to be pro-business and use a permissive license. Which should you choose?

There are three popular permissive licenses: MIT, BSD 3-clause, and Apache 2.

MIT

Extremely simple, short license. Explicitly spells out a number of rights for the licensee. Vague about if credit needs to be given when distributing a binary.

“The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software”

Is shipping a binary a “copy” of the software? I guess so.

BSD 3-clause

Extremely short license, similar in spirit to MIT but more vague about licensee usage rights. Best for ensuring credit is given: explicitly states that credit must be provided for source and binary distributions.

Apache 2

Long, industrial-strength legal document. Generally includes everything MIT and BSD-3 have, except the BSD-3 clause that ensures credit given for binary distributions. Apache 2 is actually the worst for credit – only specifies that it must be given for source distributions. Includes explicit patent license & minimal patent protection – basically says if you sue regarding patent infringement, your patent licenses expire. May or may not be useful if you actually have patents regarding the work.

Adds additional restrictions like requiring licensees to state all changes to source. That is not required by MIT/BSD.

1. “Note that the license terms for a sublicense must be consistent with ”not necessarily the same as ”the original license terms. A sublicensor cannot sublicense more rights than have been granted by the original author” (Rosen, 166) “Open Source Licensing: Software Freedom and Intellectual Property Law”
2. A few others that I didn’t research deeply are CockroachDB and Redis.
3. “To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.”
4. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
5. Other interesting examples of non-open source projects that are on github are projects from Facebook Research that use a Creative Commons NonCommercial License.