The Fundamentals of Open-Source Licensing for Startup Founders

Contents

• Intro
• Copyleft vs Non-copyleft
• MIT License
• Apache License
• BSD License
• GPLv3 License
• AGPL License
• Licensing for premium features
• Summing Up

Intro

As an open-source founder, you must make numerous critical decisions from the start of your company. Without a doubt, one of the most important ones is licensing. Founders are frequently overwhelmed by the variety of licensing options available - and here at crowd.dev, we’ve experienced the same and understand the struggle.

In this blog post, I'll go over the most common open-source licenses, how they differ, and when one is preferable to another. I'll also show you a few examples of how open-source startups use these licenses in practice.

What is software licensing?

The concept of licensing might be unfamiliar to those who mostly worked with closed-source SaaS. In the SaaS world the primary document that regulates the relationship between a company and its customers is the “Terms of Service”, but in the open-source world it also includes the software license. In broad terms a software license does two main things:

1. It protects the authors of software from liabilities.
2. It defines terms and conditions regulating modification, distribution, and usage of the software.

Copyleft vs Non-copyleft

Before we get into the specifics of the most popular licenses, let me first explain an important concept of copyleft licenses.

Copyleft licenses

Copyleft licenses specify that distributed copies and derivative works must be covered by the same license. To put it simply, it is forbidden to relicense any part of a software under a different license. For example, you cannot create a closed-source software that includes software licensed under a copyleft license because it implies changing the license. But at the same time, you are free to modify and share the source code as long as it is still licensed under the same terms. 

Examples of copyleft licenses include:

• GNU General Public License (GPL)
• GNU Affero Public License (AGPL)
• Mozilla Public License (MPL)
• Server Side Public License (SSPL)

Non-copyleft licenses (AKA permissive licenses)

Permissive licenses allow everyone to do virtually anything with the source code. It is possible to relicense it and use it in other open-source and even closed-source software. According to this report by Nauta Capital, 78% of all European open-source startups choose permissive licenses. So it’s important to be familiar with them.

Example of non-copyleft (permissive) licenses:

• MIT License
• Apache License 2.0
• BSD License

Now let's get into some of the most common licenses out there.

MIT License

This is the most well-known open-source license by far. It is extremely permissive, meaning anyone can use your code for personal, internal, and commercial purposes, change it, distribute it, and do almost anything with it. On the other hand, as a programmer, you have no liability in terms of software quality. The MIT License is used by 30% of open-source startups.

When to use it?

An MIT license is especially helpful when creating something new, such as a library. Developers need time to experiment with it in order to master it, which is why making it completely open is critical - developers despise being told they can't do something. If your open-source product is intended to be a component of other projects rather than a standalone product, the MIT license is most likely your best option. GatsbyJS, a Javascript framework for creating static React websites, is a good example here.

How to use it?

Here is the link to the full text of this license. It is quite short and simple. You should just create a txt file and copy-paste the license text into it. Add your name and current year, put the file alongside your source code, and you are done! By the way, GitHub can do it automatically.

Apache License

The Apache License 2.0 is similar to the MIT license in that it permits anyone to use the code for personal, internal, and commercial purposes. Although, there are some differences between the MIT License and Apache:

1. The Apache License 2.0 requires developers to explicitly mark any major changes to the source code (when someone modifies and distributes the software).
2. The Apache License 2.0 includes explicit patenting rules. The end user may patent software under the Apache license that has been modified. The MIT license, on the other hand, contains no provision for patenting.
3. The Apache License 2.0 does not permit the use of the licensor's trade names, trademarks, or product names. This is a crucial clause for anyone concerned about brand identity.

Besides that, Apache License 2.0 appears to be the most popular license among open-source startups (34% use it).

When to use it?

Apache License 2.0 may be a good choice if you want all of the permissiveness of the MIT license but also want control over your trademarks and protection from patent trolling.

Among open-source startups using Apache 2.0 there are Supabase, Amplication, and Deepset. 

How to use it?

Here is the link to the full text of Apache License 2.0. It is longer and more complex than the MIT license, but using it is also very simple - just fill in the two placeholders in square brackets and that's it!

BSD License

The BSD license comes in three flavors: two-clause, three-clause, and four-clause. In practice, a two-clause BSD license is equivalent to an MIT license. The three-clause BSD license includes a clause that prohibits using the names of organizations and contributors to endorse and promote third-party products derived from this software. The four-clause BSD license goes one step further by requiring the organization's name to be attributed in all advertising materials mentioning the software or its features. It should be noted that the four-clause BSD license is considered obsolete and is not accepted by the Open Source Initiative. This is due to the fact that advertising clause in 4-clause BSD is too impractical and it also incompatible with GPL, making bundling of 4-clause BSD software with any copyleft software impossible.

When to use it?

To be honest, open-source startups rarely use the two-clause BSD license because the MIT license is more popular and nearly identical to it. Furthermore, additional clauses from three-clause and four-clause BSD licenses are not really beneficial for startups, because every mention counts in an early-stage project. Still, among BSD licenses, the three-clause BSD is the most popular one and accounts for 6% of all open-source startups.

One of the well-known startups using three-clause BSD is Appwrite.

How to use it?

Here are the links to two-clause, three-clause, and four-clause BSD licenses. To use them, simply add a file with the text of the license to your repo. Don’t forget to change the current year and name of the company in the placeholders.

GPLv3 License

The GNU General Public License is a copyleft license. Copyleft implies that all derivative works should be licensed under the same terms. In practice, the GPL license allows you to modify the source code and use it internally unless you distribute it to others in binary form. If you distribute the modified software version as a binary, you must also distribute the source code. This occurs because the modified version of the software is GPL-licensed by default (copyleft concept).

You may have noticed a peculiar "via binary" requirement. So, technically, you could distribute the modified version of the software via network access (read SaaS) without releasing the source code because you are not distributing the binary. This is a fairly lax loophole in today's world, which is why the AGPL license was created to address it.

To summarize, in order to distribute the modified GPL'd code, several rules must be followed:

• Preserve the original copyright notice
• Include the full text of the GPL license
• Mark all major changes made with the source code
• Release the source code of the modified software then distributing it via binary

Aside from these requirements, GPLv3 allows end users to patent the modified version of the software. The language is very similar to the Apache License 2.0's patent clause.

When to use it?

The GPL license is not a common choice for an open-source startup, because it potentially slows the commercial adoption of the software - many companies simply couldn’t comply with this license. Still, if you want to run a more traditional business (not a VC-backed startup), it could be a good option. Wordpress, for example, is available under a GPL license. This is most likely done to prevent people from monetizing Wordpress plugins and themes without going through the company.

How to use it?

The full text of the GPLv3 license can be found here. It is quite long and requires some additional work to use, such as obtaining a copyright disclaimer from your employer or school and adding a license notice to each source code file.

AGPLv3 License

The AGPL license is nearly identical to the GPLv3 license except for one additional clause. It closes the loophole that allows GPL-licensed software to be distributed over the network (read SaaS). So, under the AGPL license, you must make the source available for download even if you never distribute the binary but do provide a service.

When to use it?

If you don't want your code to be turned into SaaS by someone else, AGPL is the way to go. While it seems to be a good option for an early-stage startup, in practice it is actually very rarely used (again, because of compliance and slower commercial adoption). However, AGPL is used by some late-stage open-source startups (with dual licensing). Consider how Grafana recently transitioned from Apache 2.0 to AGPL.

How to use it?

The full text of the AGPL license can be found here. The usage guide is the same as for GPLv3.

Licensing for premium features

Now that we looked through the most widespread licensing options, we can discuss a bit how modern open-core startups approach licensing. As you may know, the idea of open-core is simple: you give away the core for free (open-source license) and charge for premium features (proprietary license).

Recently, it has become quite popular to include source code for the premium features right in the monorepo on GitHub, to make the development easier. But how can one combine proprietary code and open-source code in one repo? 

The standard way to do this is to keep all the proprietary code in a top-level folder called “ee” or “premium” (the name of the folder doesn’t really matter, these two are just the most popular ones). After that, you should change the text of your license. Specifically, you should add a preamble in License.txt saying that all the code in the repo is licensed under the open-source license of your choice (MIT, Apache, AGPL, etc) and “ee” or “premium” folder is licensed under a proprietary license. Usually, the text of the open-source license is included right in the License.txt after the preamble, and the text of the proprietary license is included in something like a Premium_License.txt or just inside the “premium” folder. You can take a look at how real world startups like PostHog (MIT + proprietary) and Cal.com (AGPL + proprietary) do that.

While the steps mentioned above are pretty straightforward, there are still some nuances regarding the compatibility of proprietary and open-source licenses in one repo. In general, there should be no problems combining permissive and proprietary licenses, but combining copyleft and proprietary licenses might be trickier. These nuances depend on the business goals of your project (if any), so we really recommend consulting a lawyer (one who knows about open-source licensing) before making any decisions.

Summing Up

As you see, there is a whole zoo of open-source licenses available out there. We only mentioned the most popular ones.

It is difficult to provide universal advice, but usually, licenses should be picked based on your business model. For instance, if you go for open core and you plan to make money on SaaS and premium features for self-hosted users, then probably a permissive license for the core and proprietary license for the premium features is the way to go. In this case you will get more adoption than if you use a copyleft license. 

On the other hand, if you plan to make most of your money from enterprise sales, dual licensing with proprietary and copyleft licenses might be a good option. It is usually the case for more infrastructural projects, for example, Grafana. 

Here at crowd.dev we picked Apache License 2.0 as it corresponds to our business model – SaaS subscription fees and paid premium features for self-hosted users.

Whichever model describes your situation best, we recommend consulting with a lawyer before making any decisions. However, we hope this blog gives you a better understanding of licensing and has prepared you for discussions with your team and legal advisors. Best of luck to you!