Open source licensing has been in the news more than ever recently, thanks to license changes by Hashicorp, Cockroach and Redis (and Redis again), leading to formidable forks and constant drama. If you’re an early stage founder, you want to avoid this problem, and the best way to do that is to pick the right license the first time. This post will walk through what purpose OSS licenses really play, how to pick the right one, and how to communicate it properly.
The right license is not about legal, it’s about sales
Most founders don’t think about OSS licensing when they go open source. Often, they just pick a license that sounds good – maybe one a friend recommended or one a similar project uses. But a license has much bigger ramifications for your business than you might think.
The pervasive view is that licenses are about legal, but there have been shockingly few actual court cases about software copyright in open source. It’s rarely ever litigated: you only hear about the giants in the news (such as Google vs. Oracle back in 2021) because most companies fight copyright battles behind closed doors. Often, they’re not even fights. In most cases, one company notices another using its code in a way it’s not licensed to and sends a threatening email: “License the code or else.” The legal fight is over before it begins.
The bigger reason you need to worry about licensing early on isn’t legal – it’s sales. Buyers consider licenses when they decide whether they’re going to use software, and the wrong license can filter you out of the purchasing decision.
Enterprises have scanners that check new software for licenses and escalate the issue if a license isn’t permissive enough. If a developer wants to use your software, the scanning tool might flag a restrictive license and send the issue to a lawyer or head of engineering for analysis before they’re allowed to. Like a silent hardware failure, nobody will ever tell you that this is happening. You will just never see the deal in the first place.
I should also mention, with less hyperbole this time, that sales isn’t really the only reason you need to pick the right license. Whether you’re a FOSS stalwart or just someone who doesn’t want to piss developers off, a license is a social agreement with your future community about what you’re about and what they can expect. You should take it seriously!
The two schools of license philosophy: permissive and copyleft
Great, now you know why choosing a license is important. There’s no shortage of posts on the web that explain all of the different types of licenses; I’ll keep it short and give you a quick refresher on what your options are.
Permissive licenses
Permissive licenses include only minimal restrictions on how people can use, modify, and redistribute your software. Examples of permissive licenses include:
According to 2024 Synopsys research, the MIT license and the Apache 2.0 license are the two most popular open-source licenses today.
The MIT license, in particular, allows companies to reuse software as long as they ensure copies of the software include a copy of the terms of the MIT license. Ruby on Rails, Node.js, Angular, and React all use the MIT license.
Copyleft licenses
Copyleft licenses are more restrictive than permissive licenses, typically disallowing users from owning the code or registering the code for copyright and earning royalties from it.
Examples of copyleft licenses include:
The concept of copyleft licenses originated with FOSS pioneer Richard Stallman, back in 1985, when a company adopted and improved a Lisp interpreter he had worked on but refused to offer him the improvements. The core idea is to retain most of the permissiveness of open source while ensuring that software derived from the project uses the same license as the original project.
Adoption and competition or restriction and control
The choice between the two categories comes down to differences in philosophies about what open source really means, and each has its own set of tradeoffs.
Permissive licenses are, well, permissive, so chances are more people will use the software since they don’t need to worry about long-term implications. More usage can come with more community activity and contributions, which ideally leads to the virtuous cycle that you’ve seen with so many of your favorite OSS. The risk is that wider adoption of a project with a permissive license means a competitor could copy your work and outpace you in the market – which is exactly what precipitated so many of these recent high profile license switches.
With copyleft licenses, you can protect your work by using your license to maintain more control over how your work is used. The cost of this control is the adoption: almost all enterprises require explicit approval to use software that doesn’t have a permissive license. Hence fewer people will adopt your project, and fewer will advocate for a project whose success clearly benefits you more than the OSS community at large.
The right license for you is all about your business model
It’s tempting to consider your licensing options through some sort of open-source ideal: Will you be free as in free beer? Or as in freedom? Or free at all? But the real driving factor for your decision – outside of any strong points of view you have on FOSS ideals – should be what you think your business model will be.
Consulting/services model → Permissive license
If you’re building an open-source project and charging for consulting services, then you should adopt a permissive license.
With this model, you’re essentially selling yourself. The money is in convincing companies you’re an expert worth hiring, so it benefits you to have as many people as possible use your project. By maximizing adoption and awareness, you can increase the number of people interested in your expertise.
Managed services/servers model → Restrictive license
If you’re building an open-source project and charging for a hosted version / managed service, you should likely adopt a more restrictive license to enable open-source adoption while stifling copycat competition. The risk of major cloud providers building a competing service is extremely real: Just ask MongoDB or Redis.
With this model, you offer the core software for free but charge companies for the privilege of having you – the expert – take care of management, integration, service, and support.
As many readers will recall, back in 2018 MongoDB switched from an AGPL license to a Server Side Public License for its MongoDB community server. According to MongoDB’s press release at the time, other companies were trying to “test the boundaries of the AGPL.” They were, of course, referring to AWS and its new, puzzlingly named managed “Amazon DocumentDB (with MongoDB compatibility).”
With this new license, MongoDB has been able to retain some of the benefits of AGPL, including the freedom to use, review, modify, and redistribute, while adding a condition that requires companies that offer MongoDB as a service to open source the software they use to offer that service. In other words, charging for MongoDB services is MongoDB’s territory. Leaving aside the obvious controversy around how this was done and whether it’s compatible with FOSS principles, it gets the job done.
So if you plan on making most of your money via hosted services – said another way, if your open source project is by-and-large the product you’re selling – a restrictive license can protect you from the downside of someone else taking your OSS and doing the same.
SaaS → Commercially friendly license (with exceptions)
If you’re building an open-source project and charging for a SaaS version, you’ll have to think through some more granular tradeoffs. By SaaS, I mean that you have other features not included in the OSS version that are included in the hosted version, like backups, gated features, plugins, etc. Companies in this position have a tough license choice.
Ultimately, it’s a question of risk tolerance. The more permissive the license, the more adoption you might get, but the more risk you take when it comes to competitors. You also need to really believe that the closed-source features you’re offering (and will offer) around the OSS are compelling enough for people to want to not host it themselves.
A more permissive license is ultimately a bet on your ability to execute on a highly differentiated and long-term defensible product. However, a more restrictive license might make sense when most of the value of your SaaS is still exposed via the open source project and the product is largely enterprise-y bells and whistles.
Whatever you choose, be transparent about it
A wise man once said that it’s never the crime that does you in, it’s the coverup. The same principle is true when it comes to OSS licensing. Yes, your license is important, but the communication you do around the licensing is arguably as important. Whatever license you pick, clearly explain how it works, why you did it, and what it means for users.
Back to those enterprises we were talking about: When a developer wants to use a piece of OSS, and it gets escalated to a HoE or legal, they’re going to look up your company and your software. They can find one of two things:
- A license hidden in your source code with no explanation beyond the license itself, or if they’re lucky, it’s somewhere in the GitHub README.
- A dedicated page on your website explaining the license you’ve chosen, why you chose it, and what the implications are.
Here’s a good example from ParadeDB, an OSS alternative to Elastic built on Postgres. They explain in detail why they chose an AGPL license. It’s not the world’s most interesting content, but when the engineering manager from the Fortune 50 company reads it, they’ll have that much more confidence that this is software worth using.
Remember, choosing the right license is mostly about sales (and community), not legal. Communication about your decision is just as important as the decision itself.
