• 

  Heavybit
  Heavybit

Licensing: A Key Trade-Off for Open Source Startups

Why is Heavybit putting together this guide for open-source startup founders on how to choose a license that best fits your vision while making projects more defensible and sustainable in the future? Because while open source began as a genuinely grassroots movement focused on solving common problems, it has increasingly become a battleground over ownership.

Open-source software (OSS) has been many things. It has been an incredible source of innovation that builds global communities. It has been the center of conflicts between unpaid maintainers and corporations looking to extract value. But it has never been a business model.

I think you could argue [open source is] the exact opposite of a business model: You spend a bunch of your time, which costs money, and then you create a thing, and you give it away for free. And you give up control over it.” - Joseph Ruscio, General Partner / Heavybit

As we’ll cover shortly, open-source software licenses are arguably the crucial link between your open-source project and your company that makes your startup viable. Choosing the most appropriate license for your startup early on can set you up for success, and hopefully help you avoid a painful “rug-pull” license switch in the future.

And as we’ll cover below, trademarks are the key protection that identify your products as your own.

To help you best understand your options, we’ll cover:

• Copyleft vs. Permissive Licenses
• The Most Popular Types of Open-Source Licenses (and Their Trade-Offs for Startups)
  • GNU General Public License (GPL)
    • Variations: AGPL and LGPL
  • Mozilla Public License (MPL)
  • Apache License 2.0
  • MIT License
• A Word About BSL & Fair Source (Which Are Not Open Source)
• The Importance of Copyrights, Patents, Warranties, and Trademarks
• Best Practices for OSS Startups

As the founder of a startup building a product around an open-source project, you have options among different open-source licenses. Each comes with important benefits and trade-offs we’ll outline below.

>> Click to zoom in on this infographic

Some of the most popular open-source licenses, ranked by strictness/permissiveness.

Copyleft vs. Permissive Licenses

A quick-and-dirty open-source definition–the term “open source” refers to software that, per the terms of its license, lets users inspect, modify, and redistribute–unlike the typical proprietary software license, which restricts all three.

In contrast to the Creative Commons Attribution license, which is often used for most forms of digital media and lets users modify and redistribute materials as long as the creator is credited, there are many different licenses for open source.

Rather than review the entire comprehensive list of licenses from our friends at the Open Source Initiative (OSI), we find that a useful shorthand for founders is to divvy them up into one of two categories:

Copyleft (Weak and Strong)

Copyleft (or “sharealike”) is considered a “stricter” class of open-source license. While copyleft licenses generally let users modify and use a project’s materials for their own purposes, they also stipulate reciprocity of copyright protection and information for any derivative work.

Specifically, projects derived from a copyleft project must also carry a copyleft license, and distribute source code alongside any executables. Because of their requirements, copyleft is less compatible with other software licenses, which makes joint distribution more challenging. As such, copyleft licenses aren’t used as often for closed-source, proprietary software projects.

Weak copyleft variants have lighter requirements around whether derivative projects must also be copyleft. Most commonly, weak copyleft licenses make exceptions for open-source components such as a project’s software library, which other software products (that use a different license) may link to, without being subject to copyleft licensing requirements themselves.

GPL is an example of a strong copyleft license. MPL is an example of a weak copyleft license.

Permissive

One of the earliest open-source licenses was the Berkeley Software Distribution (BSD) license. Since the advent of the BSD license, other, more startup-friendly permissive licenses have emerged, which generally carry fewer restrictions than copyleft licenses, including the BSD 3-clause variant, which covers redistributions of source code and binaries, as well as restrictions on endorsements, and the Unlicense, which carries copyright protections but little else.

Permissively-licensed open-source projects generally let users utilize, modify, and redistribute their materials, so long as they provide attribution to the original source. License compliance is generally much easier for permissively-licensed projects.

Permissive licenses are also more compatible with other types of software licenses, making joint distribution much easier. They’re commonly used for commercial products built around open-source projects, though defensibility has become an increasing concern for startups witnessing larger orgs assimilate open-source materials into massive commercial products.

At Heavybit, we consider it to be a best practice for startups building open-source projects to also invest in trademark and protections to ensure their products stay viable in the market and help their community remain sustainable. (More on this below.)

Apache and MIT are examples of permissive licenses.

The Most Popular OSS Licenses (and Their Trade-Offs for Startups)

GNU Public License

GPL-licensed projects give users the right to utilize, modify, study, and distribute software, free of charge. It also requires that any derivative work be distributed under similar terms.

GPL also has variants including the stricter GNU Affero General Public License (AGPL) which offers copyleft protections for software made accessible over a network.

The less-strict GNU Lesser General Public License (LGPL) allows for links between libraries and proprietary applications and its license terms allow modifications to also release under LGPL (rather than GPL), as well as allowing for distribution of proprietary software derivatives that integrate LGPL-licensed software without having to also adopt LGPL.

(However, the LGPL does not provide allowances for two-way dependencies. Products may have dependencies on LGPL-licensed software code without requiring adopting LGPL. But if a LGPL-licensed project has dependencies on the proprietary code from an external project, that project would be required to use LGPL as well.)

Most GPL-licensed projects are either licensed under GPLv2 or GPLv3

GPL was originally written by Richard Stallman, founder of the Free Software Foundation. It’s one of the stricter copyleft licenses available.

It’s perhaps worth noting that Stallman’s work, while groundbreaking, was originally in service of free software–software distributed to allow completely unfettered usage, distribution, and study without having to pay for it–rather than open source specifically.

Examples of Projects That Use GPL

Some examples of projects that use GPL include:

• Linux Kernel: The core component of the Linux OS
• MySQL: The popular relational database management system (RDBMS)
• Gnu Compiler Collection: The well-known free code compiler

Pros & Cons of GPL

✅ Pro: Strong Protections Against Other Orgs “Privatizing”

As a strong copyleft license, GPL has relatively strong restrictions in place to protect against other corporations incorporating them into their own closed-source, for-profit products.

✅ Pro: Patent Litigation Protections

GPL protects users from patent litigation sought by other users of or contributors to the project.

✅ Pro: Preserves “Openness” of Code

The license stipulates that any modified version of a GPL-licensed project must itself be made publicly available for inspection, ensuring that any changes made to the project itself, or within derivatives, are a matter of public record.

❌ Con: Clashes With Other Licenses, Corporate Products

Because of GPL’s restrictions, it doesn’t play well in joint distributions with software not licensed under GPL. Any software derived from, or distributed with, a GPL project, must also carry GPL and is subject to the same restrictions, such as providing source code (which can make GPL fundamentally incompatible with closed-source proprietary products).

For the above reasons, GPL and other copyleft licenses have been criticized for having negative “viral licensing” repercussions on commercial software development–legally, any product developed in concert with a copyleft license like GPL itself automatically becomes a GPL project as well–subject to the same requirements of offering source code with every distribution.

Projects Best Suited for GPL

GPL is potentially a good fit for projects that will involve extremely frequent community development, accompanied by heavy customization from different user groups. GPL’s required transparency and shared source code stipulations will provide important learning resources to a community that is frequently modifying and testing new features.

The content management system Wordpress is an example of a GPL-licensed project with adjacent products for commercial use, built by private companies. (Notably, licensing conflicts have arisen between co-founder company Automattic and hosting company WP Engine, which we’ll cover below.)

Mozilla Public License

While a copyleft license, MPL attempts to strike a middle ground between GPL and more-permissive licenses. MPL lets users incorporate code from MPL-licensed software into proprietary software code, so long as users can access the MPL code under the license within those new projects.

Like GPL, MPL requires users to distribute source code for any part of the project they modify–as well as to make it available under MPL. When distributing MPL-licensed code, users are also expected to document which parts of a project’s codebase they have modified.

Examples of Projects That Use MPL

Some examples of projects that use MPL include:

• Firefox and Thunderbird: Mozilla’s browser and email client
• Apache Flex: The MXML and ActionScript framework successor to Adobe Flash

Pros & Cons of MPL

✅ Pro: File-Based Copyleft Means More License Compatibility

As mentioned, MPL lets users integrate MPL-licensed code into different, proprietary projects–those projects can then be released under different licenses without violating MPL.

✅ Pro: Patent Litigation Protections

MPL grants patent rights to users, which provides protection against patent litigation.

❌ Con: Documenting and Licensing Code Burden

Using MPL code requires users to document any code modified from the original project and and make the modified code available itself under MPL–which adds overhead to any project.

❌ Con: Low Adoption

While MPL effectively offers a middle ground between copyleft and permissive, it’s not widely used, and therefore might not drive adoption of new projects using the license.

Projects Best Suited for MPL

MPL makes sense for open-source projects that will thrive when their code gets integrated into other proprietary software projects, while still allowing some measure of control over how the code gets used.

It should be noted that MPL doesn’t offer legal protections for contributors. Slightly stricter weak copyleft licenses such as Eclipse Public License (EPL) stipulate that projects must provide legal protections for contributors in the case of any legal action.

Brave Web browser is an example of a MPL-licensed open-source project that offers commercial add-ons, such as a VPN, an AI assistant, or search API access for AI model training.

The Mozilla foundation enjoys a level of control over its open-source Firefox browser even as other companies build plug-in applications for it.

Apache License

Being a permissive license, Apache lets users modify and distribute code and derivative works as commercial products without also having to also distribute source code–so long as derivative works include the original copyright notice and provide proper attribution back to the core project.

Apache’s flexibility for both individual developers and corporate orgs makes it one of today’s most popular open source licenses. The most recent version is Apache License 2.0, launched in 2004.

Examples of Projects That Use Apache

Some examples of projects that use Apache include:

• Kubernetes: The containerized workload management platform
• Apache HTTP Server: The web server used by ~25-30% of all websites
• TensorFlow: The popular ML model library

Pros & Cons of Apache

✅ Pro: Flexibility and Protections for Individual Developers

Apache gives individual developers a wide berth to use open-source code within a licensed open-source project, along with patent rights that generally protect individual developers from patent litigation when using the software.

✅ Pro: Flexibility and Protections for Organizations

Apache’s relatively loose restrictions and lack of requirements to also distribute source code for derivative projects make it a good fit to build proprietary products for conscientious organizations that follow the terms of the license.

✅ Pro: Clear, Well-Established Guidelines

While the original Apache license debuted in 1995, the current version, Apache 2.0, launched in 2004, and over 20 years, has become a well-known standard for many open-source projects with clear guidelines on copyright protection and proper usage.

❌ Con: More Complexity Than Other Licenses, Including Trademarks, Modifications

The Apache license is literally longer than other open-source licenses, and has more nuances to track. For instance, Apache contains more restrictions around trademarks–it does not grant users the right to utilize the creator’s trademarks–and requires users who significantly alter the code to document their modifications in any derivative projects.

❌ Con: Lack of License Compatibility

Apache doesn’t always play well with other licenses–in particular, its different terms for patent protection and distribution make it generally incompatible with GPLv2 and older versions (while GPLv3 allows for combined distribution under GPLv3).

Apache also requires contributors to grant patent rights–a potential source of conflict when Apache-licensed software is combined with projects with different licenses that don’t also grant patent rights, which potentially exposes other parties to risk of patent infringement claims from contributors.

Projects Best Suited for Apache

Apache 2.0 is well-suited for projects that will likely see significant modifications and multiple distributions, while granting implicit patent protections. For this reason, Apache 2.0 has been popular for commercial products adjacent to open-source projects.

The open-source AI coding assistant Continue is an example of an Apache-licensed open-source project which offers an adjacent commercial offering featuring enterprise-grade authentications and governance for security-conscious organizations.

MIT License

The MIT License is one of the most permissive open-source licenses that sees regular use. It puts very few restrictions on contributors.

Arguably, the primary difference between an MIT-licensed project and a fully public domain project is that MIT-licensed projects must retain the original copyright notice and license text in any derivative works.

MIT otherwise allows for a variety of reuse scenarios, including integrating MIT-licensed code within proprietary software products.

Examples of Projects That Use MIT

Some examples of projects that use MIT include:

• Javascript tools including jQuery, Node.js, and Babel
• The React and Ruby on Rails frameworks

Pros & Cons of MIT

✅ Pro: Ease of Use

The MIT License’s general lack of restrictions make it an extremely simple and easy-to-understand license that does not even require users–even private companies–to disclose that they have made modifications, or that they have incorporated MIT-licensed code into other projects or proprietary products.

✅ Pro: High Flexibility and License Compatibility

Thanks to its lack of restrictions regarding attribution, documenting modifications, or distribution of source code, MIT projects are generally highly compatible with other, differently-licensed projects.

❌ Con: No Competitive Protections

Because MIT is such a permissive license, there’s very little stopping competitors from copy-pasting the open-source code from a MIT-licensed project into their own, even if their project is a proprietary, for-profit project.

❌ Con: No Attribution Requirements May Discourage Community Contributions

Community recognition can be a powerful motivator to drive contributions, but MIT’s lack of attribution requirements means that users can largely take freely from MIT-licensed projects without providing any recognition to contributors.

Projects Best Suited for MIT

Projects in rapidly-changing spaces that are intended to provide enough flexibility so that many users adopt them may be a good fit for MIT. Atlassian’s code hosting product BitBucket is proprietary software that offers a variety of MIT-licensed plugins and extensions.

A Word About BSL & Fair Source (Which Are Not Open Source)

In addition to open-source licenses, there are emerging classes of software license that retain open-source-like features, such as some level of community sharing and exposure of source code, but also feature built-in, proprietary-like protections against commercial usage.

Such licenses have been the subject of more than a little debate. As HashiCorp’s VP of Developer Relations Adam FitzGerald explains, startups now face defensibility challenges from massive enterprises as well as challenges from orgs like OSI that refuse to refer to such projects as being truly open source.

If you're trying to use [an open-source license] to build a business, you need to understand what you're trying to do with it, and what sort of trade-offs you have once you pick one.” -Adam FitzGerald, VP Developer Relations/HashiCorp

Below, we’ll include what you need to know about some of the most well-known alternatives to open-source licenses.

About Business Source License (BSL)

In 2016, MySQL creators Michael Widenius and David Axmark created BSL–an alternative license that is not open source. As major cloud providers created forks of open-source projects to build profitable infrastructure while making few to no upstream contributions, BSL emerged as a way to protect the commercial interests of OSS companies.

Although BSL projects make source code available, as with other open-source projects, access is limited only to users who have purchased a license. The idea was to preserve the ability of open-source projects to drive community contributions while removing free access to source code to competitors, though

HashiCorp, creator of infrastructure-as-code tool Terraform, has perhaps been the most prominent adopter of BSL. The controversial change led to a fully open-source fork OpenTofu and considerable discussion in the open-source community about whether this type of license was simply too restrictive for developers to use long-term.

About Fair Source

In 2024, the monitoring platform Sentry launched fair source–a new type of source-available license (that is also not open source). According to the website, “Fair Source Software (FSS) is publicly available to read; allows use, modification, and redistribution with minimal restrictions to protect the producer’s business model; and undergoes delayed Open Source publication (DOSP).”

The key differentiator is DOSP–distributing software first under a proprietary license, and later, under an open-source license. There are two primary ideas at work here, namely:

• Limited Code Sharing, Maintaining Significant Control: Fair source’s intent is to let companies “meaningfully [share] access to the code for their core software products while retaining control of their roadmap and business model.”
• Continued Existence After Creator Companies Shut Down: FSS licenses let projects continue in perpetuity–even if companies that create them go away.

FSS is essentially the last possible step before going into full-on proprietary software. By starting out with a proprietary license, fair source projects innately provide defensibility against other companies gobbling up publicly-available source code to improve and sell more of their own products–at the cost of not actually being open source and potentially missing out on significant collaboration and reach from having exposed source code.

We're in this interesting moment of tension where, I think the ‘business’ part of open source is starting to threaten the ‘rights’ part of open source.” -Adam Jacob, Founder/System Initiative

The Importance of Copyrights, Patents, Warranties, and Trademarks

Before we continue, it may be helpful to distinguish between three confusing types of intellectual property (IP) to help you understand what you can and can’t invoke to protect the work of your open-source startup and your community:

Copyrights

Copyrights are protections for original works, and contain conditions for original works being copied, modified, and distributed. Open-source licenses generally grant copyright protection to original creators and contributors to projects for their own work, but allow usage, modification, and distribution per their specific stipulations.

Patents

Patents are specific legal protections for which creators must file separately with an agency like the USPT. Patents provide the exclusive rights to create and/or distribute a specific invention by their holders.

GPL, MPL, and Apache all contain some form of patent license from contributors that implicitly protects users against patent claims, though MIT does not contain an express patent license (or any type of patent-related language, as it predates software being patented regularly).

For project creators, patents are generally considered innovation blockers. In degenerate cases, such as the 2019 case against GNOME Foundation, patent trolls cynically attempt to enforce patents beyond any reasonable expectation of value or previous contributions.

Warranties

Warranties are commitments to a certain level of performance, guaranteed by the issuer for a set period of time. Most open-source licenses (including the four we discuss above) carry a warranty disclaimer that waives any liability for using a project.

Trademarks

According to the US Patent and Trademark Office, “a trademark can be any word, phrase, symbol, design, or a combination of these things that identifies your goods or services.” They are intended to protect your company from competitors using confusingly similar names or logos by granting you the exclusive rights to your marks.

Important: Unlike with copyrights, patents, and warranties, open-source software licenses do not confer inherent trademark protections.

Best Practices for Open-Source Startups

Choosing the “Right” License

There’s a reason there are so many OSS licenses. When selecting your license, we recommend considering at least these factors:

• Distribution: OSS licenses generally let any user obtain project code from any distribution. Source-available licenses may restrict usage or sharing earlier on to specific users–which may afford your startup more protections but limit its reach.
• Modification and Derivative Terms: Strict copyleft licenses offer strong protection for your original code, as anyone who modifies copyleft projects must also distribute the source code of their modifications. Useful protection against commercial competitors, but may also lead to licensing challenges.
• License Compatibility: Stricter licenses are generally less compatible with other software licenses–something to consider if your project’s future requires significant integrations with other proprietary products.

Defensibility via Trademarks

While your choice of license is important, it isn’t enough to keep an OSS startup defensible and sustainable. We advise all OSS founders to invest in their trademarks to complement any protections they enjoy from their license.

Trademarks are arguably the most important aspect of intellectual property (IP) for open-source founders, because OSS licenses don’t confer any trademark protections. Trademarks help keep your open-source projects defensible because they identify and prove that you are the source of your product.

When you protect your startup’s products and services with a trademark, you establish that your startup–and only your startup–may use its marks to represent, market, and sell your products and services. Trademarks protect your startup from competitive entities that attempt to misrepresent themselves as being related to your startup or your projects.

Trademarks are central to the conflict between Automattic, the company founded by Wordpress creator Matt Mullenweg, and the hosting platform WP Engine. Wordpress apparently powers about 40% of all websites worldwide, and WP Engine provides a number of plug-ins, templates, and additive services for Wordpress users.

The contention is that the “WP” in WP Engine’s name implies an association between WP Engine and Wordpress that doesn’t exist–for instance, that WP Engine may have created or is otherwise the owner of Wordpress–a claim WP Engine has strenuously disputed.

As a counter-example, the open-source DevOps platform System Initiative is both an Apache-licensed project and a venture-backed startup.

Chef co-founder Adam Jacob founded the company with the express purpose of avoiding some of the built-in challenges in launching a venture-backed open-source startup.

Its extensive open-source licensing page delineates what users are and aren’t allowed to do with the project and is an excellent example of how to explicitly set forth your OSS startup’s trademark.

More Resources

• Article: Understanding Legal Issues for OSS Start-ups with Amanda Brock
• Article: How Open-Source Startups Succeed With Adam FitzGerald
• Video: Open Source Licensing and The Future of Open Source Businesses