Skip to content

Open-Source Licenses

A practical reference for choosing an open-source license. Use choosealicense.com as the canonical upstream tool — this page adds ecosystem context and clarifies the legal terms that trip up engineers.

The three columns decoded

Every license on choosealicense.com is summarised in three columns. Here is what the less obvious entries actually mean in practice.

Limitations (what the license does NOT give you)

Limitations are disclaimers written into the license text itself. They do not restrict what you can do — they restrict what the original author can be held responsible for.

Term Plain English
Liability The author cannot be sued if the software causes harm, data loss, financial loss, or any other damage. This clause protects contributors from being dragged into court because someone deployed their code in a hospital or a trading system. Without it, every open-source contributor would need professional liability insurance.
Warranty The software is provided "as-is". The author makes no guarantee that it works correctly, is fit for a particular purpose, or is free of bugs. This is the software equivalent of "sold as seen".
Trademark use The license does not grant you the right to use the project's name, logo, or brand for endorsement. You can fork and redistribute the code, but you cannot imply the original authors endorse your fork or product — e.g., you cannot call your product "Apache XYZ" just because it is built on Apache-licensed code.
Patent use The license does not grant any patent rights (only a few licenses, including Apache 2.0, explicitly do grant them). Absent an explicit patent grant, a contributor could theoretically sue you for patent infringement even though the code is open source.

Why "Limitations" is a misleading column name: these are not restrictions on you, they are protections for the author. A license listing "Liability" and "Warranty" under Limitations means: you cannot hold the author liable, and you get no warranty. The author is limiting their own exposure, not your freedoms.

Conditions (what you must do)

Term Plain English
License and copyright notice Every distribution must carry the original license text and copyright header.
State changes If you modify the code, you must document what you changed (Apache 2.0, GPL).
Disclose source You must make the source code available when you distribute the software (GPL family).
Same license Derivative works must use the same license — the "viral" or copyleft property (GPL).
Network use is distribution Providing the software as a service over a network counts as distribution, triggering source disclosure requirements (AGPL only).

License quick-reference

What each license actually lets you do

License Can use commercially? Can modify? Must share modifications? Must give credit? Patent protection?
MIT ✓ Yes ✓ Yes — No ✓ Yes — No
Apache 2.0 ✓ Yes ✓ Yes — No ✓ Yes ✓ Yes
BSD 3-Clause ✓ Yes ✓ Yes — No ✓ Yes — No
MPL 2.0 ✓ Yes ✓ Yes ✓ Only modified files ✓ Yes ✓ Yes
GPL v3 ✓ Yes ✓ Yes ✓ All code ✓ Yes ✓ Yes
AGPL v3 ✓ Yes ✓ Yes ✓ If used online ✓ Yes ✓ Yes
Unlicense ✓ Yes ✓ Yes — No — No — No

What these columns mean

  • Can use commercially? — Can a company use this software to make money? (All major licenses say yes.)
  • Can modify? — Can you change the code? (All major licenses say yes.)
  • Must share modifications? — Do you have to release your changes back publicly?
  • No = you can modify it and keep your changes private
  • Only modified files = you can modify it, but if you share it, only the files you changed must be released
  • All code = if you modify it and share it at all, the entire thing must be released
  • If used online = normal sharing doesn't trigger this, but running it as a web service does
  • Must give credit? — Must you include the original author's name / license text when you use it?
  • Patent protection? — If someone holds a patent that the code uses, do they promise not to sue you?
  • Yes (Apache, GPL, AGPL, MPL) = explicit promise
  • No (MIT, BSD, Unlicense) = no explicit promise (but they also can't grant a patent license)

Ecosystem recommendations

Cloud Native / infrastructure tools

Recommended: Apache 2.0

Apache 2.0 is the de facto standard for the CNCF ecosystem (Kubernetes, Prometheus, Envoy, containerd, Argo…). The explicit patent grant matters here: companies building on your tool need assurance they will not face a patent claim from a contributor. The permissive nature lets vendors embed it in commercial products, which drives adoption and contribution back upstream.

Projects like margot fit this category well — infrastructure-adjacent tooling that enterprises need to integrate without legal friction.

Apache 2.0 → CNCF compatible, patent-safe, vendor-friendly

Developer tools and libraries (general-purpose)

Recommended: MIT or Apache 2.0

MIT is the minimal-friction choice: one paragraph, universally understood, no patent grant overhead. Apache 2.0 is the better choice if contributors are likely to hold relevant patents (common in networking, cryptography, compression).

Most npm, PyPI, and Cargo packages use MIT or Apache 2.0 (or dual-license both).

Databases and storage engines

Recommended: Apache 2.0 or BSL (Business Source License)

Pure open-source: Apache 2.0. If you need to prevent cloud providers from reselling your product as a managed service (the "AWS problem"), consider BSL 1.1 with a conversion clause to Apache 2.0 after N years. HashiCorp (Terraform), Sentry, and MariaDB have taken this path. BSL is not OSI-approved open source — be explicit with your community about the tradeoff.

Security tools and audit software

Recommended: Apache 2.0 or GPL v3

Apache 2.0 if you want commercial integrations (SIEMs, enterprise platforms). GPL v3 if you want to ensure the tool stays open and cannot be incorporated into proprietary black boxes — useful for auditing and compliance tooling where transparency is the whole point.

Community-first, anti-SaaS projects

Recommended: AGPL v3

AGPL forces anyone running your software as a network service to release their modifications. This is the right choice if your goal is ensuring improvements flow back — and if you are comfortable accepting that most companies will avoid your project or pay for a commercial exception (the "open core" model used by GitLab, Nextcloud, Mattermost).

Academic and research software

Recommended: MIT or BSD 3-Clause

Minimal friction for citation and reuse. BSD 3-Clause's non-endorsement clause is important in academic contexts: you cannot use the university's name to imply endorsement of a derivative.

Hardware description / HDL (FPGAs, ASIC)

Recommended: CERN Open Hardware Licence v2 (Permissive or Strongly Reciprocal)

Standard software licenses do not map cleanly to hardware. The CERN OHL was designed specifically for hardware design files. Choose the Permissive variant for broad adoption; Strongly Reciprocal for copyleft behaviour.

Apache 2.0 in depth

Apache 2.0 is the right default for most infrastructure and Cloud Native projects. Key properties that differentiate it from MIT:

Explicit patent grant (Section 3) Every contributor who submits code grants you a royalty-free, worldwide patent license for any patents they hold that are necessarily infringed by their contribution. This protection disappears if you initiate patent litigation against any contributor for the covered work — a built-in patent peace clause.

State changes requirement (Section 4b) If you distribute a modified version, you must include a prominent notice stating that you modified the files and the date. This is a light attribution obligation, not source disclosure.

"NOTICE" file (Section 4d) If the original work includes a NOTICE file, you must preserve it in your distribution and include it in your own NOTICE if you add attribution entries. This is how projects like Apache Kafka attribute their dependencies.

Compatibility Apache 2.0 is compatible with GPL v3 (you can combine Apache 2.0 code into a GPL v3 work) but not with GPL v2, because GPL v2 has no equivalent patent termination clause.

flowchart TD
    Q1{Patent claims\nby contributors\na concern?} -->|Yes| Q2{Do you need\ncorpus iuris to\nstay open?}
    Q1 -->|No| MIT["MIT\n(simplest)"]
    Q2 -->|No| AP2["Apache 2.0\n✓ patent grant\n✓ permissive\n✓ CNCF standard"]
    Q2 -->|SaaS anti-enclosure| AGPL["AGPL v3\n✓ network clause\n✓ patent grant"]
    Q2 -->|Binary anti-enclosure| GPL["GPL v3\n✓ copyleft\n✓ patent grant"]

Sources