Choosing an Open-Source License

A license is the API of collaboration. Choosing one determines how others can use, modify, and redistribute your work—and what you must honor when you adopt someone else’s.

License mistakes are quiet until they are expensive. A publisher who invents custom terms discourages every corporate adopter whose legal team must review them. An adopter who ships a GPL dependency inside a proprietary appliance discovers the obligation during an acquisition's due diligence, not before. Neither failure announces itself at commit time—both surface at the worst possible moment, priced at legal-review rates.

The decision itself is smaller than it looks: two families (permissive and copyleft), a handful of well-known SPDX licenses within each, and a short checklist depending on whether you are publishing or adopting. Prefer boring, well-understood licenses and document them clearly. For commercial distribution decisions, this guide is orientation—not a substitute for qualified legal review.

Two big families

• Permissive (MIT, BSD, Apache-2.0): wide reuse, including proprietary products; Apache-2.0 adds explicit patent grants.
• Strong copyleft (GPL family): derivative distributions generally must share corresponding source under compatible terms.
• Weak/network variants (LGPL, MPL, AGPL): different triggers—linking, file-level, or network use. Read carefully.

Concrete anchors help. The permissive family powers most of the modern web stack: React, Node.js, and Rails are MIT; Kubernetes, Android's core, and most Apache Software Foundation projects are Apache-2.0; PostgreSQL uses its own BSD-style license. Strong copyleft anchors the other pole: the Linux kernel is GPL-2.0, GCC and Bash are GPL-3.0. The weak and network variants sit between—Firefox is MPL-2.0, glibc is LGPL, and projects like Nextcloud, Grafana, and Mastodon chose AGPL specifically so that hosted derivatives must share their changes. When you pick from these families you are also picking which of these communities' norms and precedents apply to you.

A separate category worth naming because it causes confusion: source-available licenses such as SSPL, BUSL, and the Elastic License. Code under these is readable and often free to use, but the licenses are not OSI-approved open source—they restrict fields of use, typically competing hosted services. If your policy says “open source only,” these fail it; know the difference before a dependency scanner surprises you.

If you are publishing a project

• Pick a well-known SPDX license instead of inventing terms—every custom clause costs adopters a legal review you cannot see.
• Add a LICENSE file and per-file headers if your community expects them; set the SPDX identifier in package metadata too.
• Decide CLA/DCO policy before the first external contribution lands—retrofitting one later requires chasing every past contributor.
• Be consistent across repos in a product family to reduce adopter confusion.
• If you may ever want dual licensing or a relicense, plan contributor agreements for it now; without them, the option closes with each merged PR.

If you are adopting a dependency

• Identify the license of the package you ship—not only the license of a SaaS you call over HTTP; distribution is what triggers most obligations.
• Watch reciprocal obligations when you distribute modified clients, appliances, or container images that bundle the dependency.
• Track third-party notices for attribution requirements; automate the notice file generation rather than maintaining it by hand.
• Re-check when upgrading majors; license changes do happen, and several prominent projects have moved to source-available terms mid-life.
• Keep a dependency license inventory (SBOM or scanner output)—due diligence during funding or acquisition will demand it on short notice.

Practical defaults (not legal advice)

• Libraries meant for broad adoption often use MIT or Apache-2.0.
• Applications where you want improvements shared often consider GPL/AGPL—with clear UX for network services on AGPL.
• Company policy may restrict copyleft in certain products; align with counsel early.

Common licensing mistakes

• Publishing with no LICENSE file at all: legally this means all rights reserved, and careful adopters—especially corporate ones—simply cannot use the code, whatever the README implies.
• Inventing custom terms or adding riders (“MIT but not for military use”): every non-standard clause forces a legal review on every adopter and usually makes the license non-open-source by definition.
• Mixing incompatible licenses in one distribution—for example bundling GPL code into a product whose license forbids source disclosure—and discovering it during a customer's vendor audit.
• Copy-pasting source from a copyleft project into a permissive or proprietary codebase; the snippet carries its license with it, and code-scanning tools used in due diligence will find it.
• Assuming the license on the repo covers the dependencies inside your built artifact; the container image or binary you ship aggregates dozens of licenses, each with its own notice duties.
• Skipping the CLA/DCO decision until a relicense or dual-license opportunity appears—by then, consent from every past contributor is required and rarely obtainable.
• Treating a dependency's license as checked forever: relicensing mid-project is rare but real, and a major-version upgrade is when it happens.

Conclusion

Choose boring, well-understood licenses and document them clearly—that single habit prevents most license problems on both sides of the table. Publishers: an SPDX license file, a CLA/DCO decision made early, and consistency across repos cost almost nothing now and are painful to retrofit later. Adopters: know what you ship, automate the notices, and re-read terms on major upgrades. The license question rewards being settled once, deliberately, rather than revisited in a crisis. For commercial distribution decisions, treat this guide as orientation—not a substitute for qualified legal review.