Skip to content

Common Open-Source Licenses — Reference

A quick reference to the most common open-source software licenses for BNI engineering decisions. Sorted into four categories by restrictiveness, with what each license actually does to your project.

Not legal advice

This page is a working engineering reference. For real licensing decisions (especially around MPWR token economy, hardware integration partnerships, or distribution of BNI-released software), get a qualified attorney review per the Epistemic Honesty directive — specifically [EXPERT REVIEWED]. The descriptions below summarize publicly documented license behavior, not legal opinion.

Comparison table

License SPDX ID Category Patent Grant Network Use Disclosure Most Used For
MIT MIT Permissive ❌ ❌ JS/Node ecosystem, frontend libraries
Apache 2.0 Apache-2.0 Permissive ✅ ❌ Enterprise, Google, AWS, IP-sensitive projects
BSD 2-Clause BSD-2-Clause Permissive ❌ ❌ Historical Unix-derived projects
BSD 3-Clause BSD-3-Clause Permissive (+ non-endorsement) ❌ ❌ Historical Unix-derived; Google's older projects
ISC ISC Permissive ❌ ❌ Node.js ecosystem (npm uses ISC by default)
LGPL v3 LGPL-3.0 Weak Copyleft ✅ ❌ Dynamic libraries usable in closed-source apps
LGPL v2.1 LGPL-2.1 Weak Copyleft ❌ ❌ Older dynamic libraries (GTK, glibc historically)
MPL 2.0 MPL-2.0 Weak Copyleft (file-scoped) ✅ ❌ Firefox, Thunderbird, modern weak-copyleft projects
GPL v3 GPL-3.0 Strong Copyleft ✅ ❌ Desktop applications, embedded systems
GPL v2 GPL-2.0 Strong Copyleft ❌ ❌ Linux kernel, many older Linux applications
AGPL v3 AGPL-3.0 Strong Copyleft + Network ✅ ✅ Server-side software intended to prevent proprietary SaaS forks
Unlicense Unlicense Public Domain–like ❌ ❌ Pure public-domain dedication (legally questionable in some jurisdictions)
CC0 1.0 CC0-1.0 Public Domain–like ❌ ❌ Data, documentation, sometimes code

Patent Grant: ✅ = the license explicitly grants patent rights to users. ❌ = no explicit patent clause (you may still have implicit patent protection depending on jurisdiction).

Network Use Disclosure: ✅ = SaaS / hosted-service operators must provide source to users. ❌ = no such requirement.

Category 1 · Permissive licenses

The most flexible. Use the code in anything (commercial, proprietary, derivative) with minimal obligations — typically just preserve the license notice.

MIT

The most popular open-source license, period. Allows almost anything — just keep the license notice intact. Used by nearly every Node.js package, React, Vue, jQuery, and most modern JavaScript projects.

Apache 2.0

Similar permissiveness to MIT but adds two important things:

  1. Explicit patent grant — contributors grant you a license to any patents they hold that read on the code. Protects you from patent suits by the contributors themselves.
  2. Termination clause — if you sue any contributor over patents, your patent license terminates.

This combination is why enterprise projects (Google, AWS, Apache Software Foundation projects) prefer Apache 2.0 over MIT. The patent clause matters more when many contributors and many corporate IP portfolios are involved.

BSD (2-Clause and 3-Clause)

The historical predecessors to MIT. Similar permissiveness. The 3-Clause adds a non-endorsement clause (you can't use the original authors' names to endorse your derivative). Both are less commonly used in new projects today — MIT or Apache 2.0 are the modern defaults.

ISC

Functionally equivalent to MIT, slightly simpler wording. Common in the Node.js ecosystem (npm init defaults to ISC). If MIT would work for your project, ISC works too.

Category 2 · Weak copyleft (share-alike within limits)

Modifications must be open-sourced; broader use can remain proprietary.

LGPL v3 / v2.1

Designed for libraries. The key insight:

  • If you modify the LGPL library itself → you must release your modifications under LGPL
  • If you use the LGPL library as a dependency in a larger project (especially via dynamic linking) → your larger project can remain proprietary

This makes LGPL the standard for libraries like glibc, GTK, and many GNU tools that want to allow proprietary use without forcing the proprietary code to become open.

v3 adds:

  • Explicit patent grant
  • Anti-Tivoization clause (you can't ship LGPL'd code on hardware that prevents users from running modified versions)

MPL 2.0

The Mozilla Public License — a balanced approach increasingly popular in modern projects.

The key insight: only the modified MPL-licensed files must be disclosed under MPL. The rest of your codebase can remain proprietary. This is file-scoped copyleft, distinct from LGPL's library-scoped or GPL's project-scoped copyleft.

Used by Firefox, Thunderbird, Rust language tooling, many modern projects that want some copyleft protection without GPL's full reach.

Category 3 · Strong copyleft (share-alike throughout)

Any derivative work of the code must be released under the same license. Often called "viral" — though that framing is contested.

GPL v3 / v2

Pre-existing Linux kernel, GNU project, many embedded systems and desktop applications. The rules:

  • If you include GPL code in your project → your entire project must be GPL
  • If you distribute compiled binaries → you must provide source code on request
  • Patent grants (in v3) and anti-Tivoization (in v3)

v3 vs v2 in practice:

  • v3 explicitly includes anti-Tivoization (you can't ship GPL code on locked-down hardware that prevents user modifications)
  • v3 has explicit patent grants; v2 is silent on patents
  • v3 has the "Affero compatibility" clause that allows linking with AGPL code
  • Linux remains v2 because its maintainers don't want anti-Tivoization

AGPL v3

GPL v3 plus a network clause: if you run the software as a hosted service that users interact with over a network (a SaaS), you must provide source code to those users — even if you never distribute binaries.

This closes the "SaaS loophole" that allows companies to use GPL software to build proprietary cloud services. AGPL is rare outside server-side projects that specifically want to prevent commercial SaaS forks (MongoDB historically used a related license; Elasticsearch's modern license was prompted by similar concerns).

For BNI: AGPL is the right choice for hosted-SaaS components that we want to remain open. See BNI license choices below.

Category 4 · Public domain–like

Minimal restrictions, or a dedication to the public domain.

Unlicense

Explicitly places code in the public domain with no conditions. Rare in practice because public-domain dedication is not legally enforceable in all jurisdictions — some countries don't recognize the concept of waiving copyright in this way. Apache 2.0 or MIT are more legally robust for the same intent.

CC0 1.0

Creative Commons Zero — a legal tool for waiving copyright in jurisdictions that allow it, with a fallback license for jurisdictions that don't. Used for data, documentation, and occasionally code (though most code projects prefer MIT for clearer enforceability).

Key considerations

1 · Commercial use

All major open-source licenses permit commercial use. This is a common misconception. The distinction between license categories is about disclosure and license inheritance, not whether you can charge money.

A GPL'd project can be sold; you just have to provide source to buyers. Apache code can be put in proprietary software with attribution. MIT lets you do almost anything.

2 · Patent clauses

Apache 2.0, GPL v3, LGPL v3, and MPL 2.0 include explicit patent grants. This matters more when:

  • Multiple contributors with corporate IP portfolios
  • High-stakes deployment where patent claims could be made
  • Enterprise adoption (legal teams require clear patent terms)

For solo or small-team projects, the patent-grant difference between MIT and Apache 2.0 is often marginal. For larger projects with mixed contributors, it can be important.

3 · Copyleft strength

Strength Effect
Permissive No restrictions on closed-source derivatives. Use anywhere.
Weak copyleft Restrictions only on derivatives of the licensed component.
Strong copyleft Restrictions on the entire project containing the code.
Strong copyleft + network (AGPL) Same as strong copyleft, plus extends to hosted services.
  • MIT dominates JavaScript / Node.js / npm ecosystem
  • Apache 2.0 preferred by Google, AWS, and many enterprise OSS projects
  • GPL strong in Linux kernel, embedded systems, desktop applications
  • LGPL common for dynamic libraries (GTK, glibc historically)
  • MPL 2.0 gaining adoption in modern projects (Firefox, Thunderbird, Rust tooling)

5 · Compatibility

Some licenses are compatible — you can combine code from both into one project. Others aren't:

  • MIT, Apache 2.0, BSD → can combine with each other in a permissive umbrella
  • GPL + Apache 2.0 → GPL v3 explicitly allows this; GPL v2 + Apache 2.0 has historical incompatibility issues
  • AGPL + GPL → compatible only in specific directions
  • MIT-licensed code in a GPL project → fine (GPL is more restrictive, MIT permits it)
  • GPL code in an MIT project → the resulting project must be GPL (the more restrictive license wins)

When in doubt for a real-world combination, consult the SPDX license compatibility chart and (for any production-bound decision) an attorney.

BNI's license choices

[EXPERT REVIEWED] pending — these are the working defaults established in the BNI Mission & Vision and may be refined with formal legal review:

  • Open-source software released by BNI Foundation: MIT or Apache 2.0 for core libraries (maximum adoption, minimum friction); AGPL for hosted SaaS components where we want to prevent proprietary SaaS forks of BNI-built infrastructure.
  • Hardware integration framework specs: typically CC BY 4.0 for specifications, allowing implementation in any license.
  • Documentation: this site (and most BNI docs) is implicitly licensed for reference and contribution; explicit license forthcoming.

Per the BNI mission statement: "Core libraries, frameworks, and hardware specs are MIT or Apache 2.0. Maximum adoption, minimum friction."

For any contributor or partner asking about how to license code they're contributing to a BNI project: the project's own LICENSE file in its repo is authoritative. If a repo doesn't yet have a LICENSE, ask the maintainer before contributing.

External references