Choosing a License

The License Decision Matters

Choosing a license is one of the first decisions you make when open sourcing a project, and one of the hardest to change later. Once users depend on your software under a particular license, changing it requires either owning all the copyright (no external contributions) or getting permission from every contributor. The Terraform license change from MPL to BSL triggered a community fork (OpenTofu). The Elasticsearch change from Apache 2.0 to SSPL triggered a fork (OpenSearch by AWS). These were not painless transitions.

Choose carefully the first time. This topic covers the practical reasoning behind the most common choices.

For Libraries: MIT or Apache 2.0

If you are building a library — something other developers will import and use in their own projects — choose the most permissive license you can. Your goal is maximum adoption. Every restriction you add reduces the number of projects that can use your library.

MIT: The Default Choice

MIT is the most common choice for libraries because it has the fewest restrictions. Users can do anything with the code as long as they include the copyright notice. This means:

A startup can use your library in a commercial product
A Fortune 500 company can embed it in proprietary software
A competitor can fork it and build a competing product
A student can copy it into a homework assignment

All of these are permitted, and all of them grow your user base. React, Vue, Svelte, Express, Lodash, and thousands of other popular libraries use MIT.

The argument for MIT over Apache 2.0 is simplicity. The MIT license is 171 words. Every developer has seen it. Every legal team understands it. There is zero friction.

Apache 2.0: When Patents Matter

If your project touches areas where patents are common — machine learning, networking protocols, compression algorithms, codecs — Apache 2.0 is the better choice. The explicit patent grant protects users from patent claims by contributors.

Consider this scenario: a developer at a large company contributes an optimization to your library. That optimization is covered by a patent held by their employer. Under MIT, the company could theoretically sue users of your library for patent infringement. Under Apache 2.0, the patent grant in the license prevents this.

Kubernetes, TensorFlow, and most CNCF projects use Apache 2.0. The Rust language itself is dual-licensed under MIT and Apache 2.0, giving users the choice.

Dual Licensing: MIT + Apache 2.0

Some projects offer dual licensing under both MIT and Apache 2.0. Users can choose whichever license suits their needs. This is common in the Rust ecosystem — the Rust compiler, standard library, and many popular crates use this approach.

The rationale: MIT is simpler but lacks patent protection. Apache 2.0 has patent protection but is incompatible with GPL v2 (due to the patent clause). Dual licensing lets GPL v2 projects use the MIT license while letting other projects choose Apache 2.0 for patent safety.

LICENSE CHOICE FOR LIBRARIES

    Want maximum simplicity?         --> MIT
    Want patent protection?          --> Apache 2.0
    Want both?                       --> MIT OR Apache 2.0 (dual)
    Want to prevent proprietary use? --> GPL (but expect less adoption)

For Applications: MIT or AGPL

Applications — tools, servers, desktop programs — have different licensing considerations than libraries. Nobody is importing your application as a dependency, so license compatibility with other projects matters less.

MIT for Applications

MIT works well for applications when you want maximum freedom for users. VS Code (MIT), Alacritty (Apache 2.0), and ripgrep (MIT/Unlicense dual license) are permissive. Users can fork them, modify them, and distribute modified versions without restriction.

The risk: a well-funded company can take your MIT-licensed application, add proprietary features, and sell a competing product without contributing back. This is exactly what happened with Elasticsearch — AWS took the Apache 2.0-licensed Elasticsearch, built Amazon OpenSearch Service, and competed directly with Elastic, the original company.

AGPL for Applications

The AGPL prevents this scenario. If a company modifies your AGPL application and offers it as a service, they must release their modifications as open source. This is why many developer tools use the AGPL:

Grafana: AGPL for the core, proprietary license for enterprise features
Nextcloud: AGPL ensures that cloud providers cannot offer a proprietary Nextcloud service
Mastodon: AGPL ensures that all instances run open source code

The AGPL is particularly effective for server-side applications. The traditional GPL only requires source distribution when you distribute the binary. Since SaaS companies never distribute the binary (users access the software over the network), the GPL does not apply. The AGPL closes this gap by requiring source distribution when users interact with the software over a network.

The downside of the AGPL: some companies have blanket policies against AGPL dependencies. Google famously prohibits AGPL software internally. If you want Google engineers to contribute to your project, the AGPL is a barrier.

For Companies: Apache 2.0

Companies open sourcing internal tools should default to Apache 2.0. The patent grant protects users (including the company's own customers) from patent claims, and the permissive terms maximize adoption and contribution.

Major corporate open source projects use Apache 2.0:

Kubernetes (Google)
TensorFlow (Google)
Kafka (LinkedIn/Confluent)
Spark (UC Berkeley/Databricks)
Airflow (Airbnb/Apache)

The Apache 2.0 license also requires a NOTICE file listing all copyright holders and any required attribution. This creates a clear chain of intellectual property ownership, which matters for companies that need to track contributions for legal compliance.

Contributor License Agreements

Companies often pair their license with a Contributor License Agreement (CLA). A CLA is a legal agreement signed by contributors that grants the company additional rights over the contributed code — typically the right to relicense it.

CLAs are controversial. They create an asymmetry: the company can change the license in the future, but contributors cannot revoke their contributions. The Elasticsearch and Terraform license changes were possible because the companies owned the copyright (through CLAs) and could relicense without contributor consent.

The alternative is a Developer Certificate of Origin (DCO), which simply requires contributors to certify that they have the right to submit the code. The Linux kernel uses a DCO (the "Signed-off-by" line). A DCO does not grant relicensing rights, which means the project cannot unilaterally change its license.

The AGPL as a Business Tool

The AGPL is not just a philosophical statement — it is a business strategy. The model works like this:

Release the software under the AGPL
Offer a commercial license for companies that do not want AGPL obligations
Revenue comes from companies that want to use the software without open sourcing their modifications

This is dual licensing: open source for open source, commercial for commercial.

How It Works in Practice

MongoDB used this model (before switching to SSPL). The MongoDB Community Server was AGPL. If you ran MongoDB in your own infrastructure and did not modify it, the AGPL had no practical effect. But if you modified MongoDB and offered it as a service (like a managed MongoDB hosting), you had to release your modifications — or buy a commercial license.

Qt uses a similar model. Qt is available under the LGPL (for most use cases), the GPL (for certain components), and a commercial license. Companies that want to use Qt in proprietary applications without complying with LGPL requirements purchase the commercial license.

Why It Works

The AGPL creates a clear value proposition for the commercial license:

AGPL VERSION:
    - Free
    - Must open source modifications if offered as a service
    - No official support
    - Community-only features

COMMERCIAL VERSION:
    - Paid
    - Keep modifications proprietary
    - Official support and SLA
    - Enterprise features (SSO, audit logging, etc.)

Companies that are building proprietary products or services on top of the software often prefer to pay for the commercial license rather than comply with the AGPL. The AGPL's restrictions are not a bug — they are the business model.

Choosing for Specific Scenarios

A CLI Tool You Want Everyone to Use

MIT. You want the tool in every developer's toolkit. No license friction.

A Database Engine

Apache 2.0 or AGPL. Apache 2.0 if you want maximum adoption (PostgreSQL approach). AGPL if you want to prevent cloud providers from offering it as a service without contributing back (pre-SSPL MongoDB approach).

A Framework for Building Web Applications

MIT or Apache 2.0. Frameworks need to be embeddable in any project, including proprietary ones. React (MIT), Django (BSD), and Rails (MIT) all use permissive licenses.

An Internal Tool Your Company Is Open Sourcing

Apache 2.0 with a CLA. The patent protection matters for corporate use, and the CLA gives the company flexibility to relicense if needed.

A Personal Project You Want to Protect

AGPL if you want modifications to stay open source. MIT if you want maximum adoption and do not care about proprietary forks.

The License Decision Tree

START

Is this a library that other projects will import?
    Yes --> Do you care about patent protection?
        Yes --> Apache 2.0
        No  --> MIT
    No  --> Is this a server-side application?
        Yes --> Do you want to prevent proprietary forks?
            Yes --> AGPL v3
            No  --> MIT or Apache 2.0
        No  --> Is this a desktop/CLI application?
            Yes --> MIT (maximum adoption)
                    or GPL v3 (if you want copyleft)
            No  --> MIT (safe default)

This is a simplified guide. Consult a lawyer for complex scenarios, especially if your company has patents in the area or if you plan to dual-license.

Common Pitfalls

Not Choosing a License at All

Choosing GPL for a Library You Want Widely Adopted

GPL libraries cannot be used in proprietary software. If your library is GPL, most commercial projects will not adopt it. If maximum adoption is your goal, use MIT or Apache 2.0.

Choosing a License Based on Ideology Alone

"I believe all software should be free" is a valid philosophical position, but it has practical consequences. If you license a library under the AGPL because you believe in software freedom, you will have fewer users than if you used MIT. Make the choice with full awareness of the tradeoffs.

Assuming You Can Change the License Later

You can only relicense code you own. If 50 people have contributed to your project, you need all 50 to agree to the license change — or you need a CLA that grants you relicensing rights. Plan for this from the beginning if you think relicensing might be needed.

Ignoring Your Dependencies' Licenses

Your project's effective license is constrained by your dependencies. If you depend on a GPL library, your project must be GPL-compatible. If you depend on an AGPL library, your project effectively becomes AGPL. Check your dependency licenses before choosing your own.

Key Takeaways

For libraries, MIT or Apache 2.0 maximizes adoption. Apache 2.0 adds patent protection that matters for corporate users.
For applications, MIT provides maximum freedom; AGPL prevents proprietary forks and enables dual-licensing business models.
For companies open sourcing internal tools, Apache 2.0 with a CLA is the standard choice.
The AGPL is a legitimate business strategy: free for open source use, commercial license required for proprietary use.
Changing a license after adoption is legally and socially expensive. Choose carefully the first time.
Your dependencies constrain your license choices. A single GPL dependency makes your project GPL.