TLDR:
An open source license is a legal agreement granting users rights to use, modify, and distribute software, subject to specific obligations. Open source licenses range from minimal-obligation permissive licenses (MIT, BSD, Apache) to strong copyleft licenses requiring derivative works to be released under compatible terms (GPL family). License choice has major business implications for both producers and consumers of open source software.
Permissive Licenses
Permissive licenses (MIT, BSD-2-Clause, BSD-3-Clause, Apache 2.0, ISC) impose minimal obligations: typically attribution (preserve copyright notice and license text) with no requirement to share derivative works. Apache 2.0 adds an explicit patent grant. These licenses maximize adoption flexibility and are widely used by major foundation libraries (React, TensorFlow, Kubernetes), making them the de facto choice for most new open source projects optimizing for ecosystem adoption.
Copyleft Licenses
Copyleft licenses (GPL v2, GPL v3, AGPL, LGPL, MPL 2.0) impose stronger obligations: derivative works must be released under compatible copyleft terms. GPL requires that distributed software linked to GPL code must itself be GPL-licensed (the “viral” effect). AGPL extends copyleft to network distribution (using GPL code in a SaaS triggers source code disclosure). LGPL allows linking without triggering full copyleft. MPL 2.0 is file-level copyleft. Copyleft preserves the open source nature of derivative works but can complicate commercial use.
Modern Considerations: Source-Available and AI
Recent years have seen a proliferation of source-available licenses (SSPL, BSL, Elastic License) that restrict commercial use but are not OSI-approved open source. These are responses to cloud providers monetizing open source projects without contributing back. AI training has raised new license interpretation questions: do GPL-licensed code’s terms apply when used to train an LLM that generates similar code? Litigation is ongoing. For startups, license decisions should consider: contributor expectations, downstream user reception, commercial strategy (especially around cloud monetization), and compatibility with dependencies. CLA (Contributor License Agreement) infrastructure is often required for substantial open source projects.