When adding an open-source library to a commercial product, why can a permissive license (like MIT or Apache 2.0) and a copyleft license (like GPL or AGPL) lead to very different legal outcomes for your codebase, even if the two libraries do the exact same technical job?

## How license conditions travel with the code The mechanism starts with understanding that an open-source license is a set of conditions attached to the copyright of the code, and those conditions travel with the code into whatever you build with it. - **Permissive licenses** - MIT, BSD, Apache 2.0 - grant broad rights to use, modify, and redistribute the code with very few strings attached: typically just preserving the original copyright and license notice, and in Apache 2.0's case, a patent grant and a notice requirement for modifications. Under a permissive license, you can embed the library into a closed-source commercial product, modify it privately, and never publish your changes, and you are legally in the clear. - **Copyleft licenses** work differently: the GNU General Public License (GPL) requires that if you distribute a work that is a 'derivative' of GPL-licensed code (which, depending on how it's linked and used, can include your own application code), you must release the complete corresponding source under the same GPL terms. This is often called a 'viral' property, because the obligation propagates to code that touches the GPL component in certain ways. - **The Affero GPL (AGPL)** closes what its authors saw as a loophole in GPL: GPL's obligation to share source only triggers on distribution of the binary, so a company could run GPL code as a backend service without ever distributing it, and never trigger the sharing requirement. AGPL extends the trigger to include making the software available over a network, which is precisely the SaaS delivery model most modern products use, meaning an AGPL dependency embedded in a SaaS backend can obligate you to publish your entire service's source code to every user who interacts with it over the network. ## The two philosophies behind the split This distinction exists because open-source licensing was designed around different philosophies of what 'freedom' means: - **permissive licenses** maximize the freedom of downstream users, including commercial ones, to do whatever they want with the code; - **copyleft licenses** prioritize keeping the code and its derivatives free forever, using legal obligation to prevent a proprietary product from closing off improvements built on open work. Both are legitimate, well-established philosophies, but they have opposite implications for a company building closed-source commercial software, so the license attached to a candidate component is not a technical detail - it is a legal and business decision with real consequences. ## The trade-off engineers face The trade-off engineers face is that the technically best-fitting component for a job is sometimes copyleft-licensed, and the second-best option is permissively licensed, and choosing between them trades engineering quality against legal risk and business flexibility. Adopting the copyleft option might be fine if the product itself is or will become open source, or if the copyleft component is used only internally in ways that don't trigger distribution (this determination is genuinely legally nuanced and usually needs actual legal review, not just engineering judgment). Avoiding it preserves closed-source flexibility but may mean settling for a less capable or less mature component, or writing more custom code. ## Failure modes that have played out publicly Failure modes here are not hypothetical; they've played out publicly. - Companies have had to rip out and replace copyleft-licensed database or infrastructure components discovered mid-integration, after significant engineering investment had already gone into building around them, once legal counsel flagged the license during a review, contract negotiation, or acquisition due-diligence process - a pattern echoed by several database vendors that moved from AGPL to even stricter source-available licenses specifically to restrict SaaS-style offerings without a commercial license. - Another common failure mode is **license incompatibility** within a single codebase: pulling in two dependencies whose licenses can't legally coexist in the same distributed work, which usually isn't caught by engineers at all since it requires legal or specialized tooling analysis, and gets discovered late, often during an acquisition's legal due diligence, when it becomes an expensive scramble. ## A worked scenario A concrete, worked scenario: a team building a closed-source SaaS analytics product evaluates two candidate full-text search libraries. One is Apache 2.0 licensed and slightly less feature-rich; the other is AGPL licensed and has better out-of-the-box relevance tuning. If the team picks the AGPL option purely on capability fit and embeds it directly into their backend service, they may now be obligated to make their entire backend's source available to any user of the hosted service - a business-incompatible outcome for most commercial SaaS companies - unless they either: - purchase a commercial license offered by the AGPL project (many dual-license specifically to sell an exception to this obligation), or - isolate the AGPL component behind a strict process or network boundary in a way a lawyer confirms does not constitute a combined work under the license. In practice, this means license compatibility has to be checked before deep integration, ideally via automated license scanning in the dependency pipeline, not discovered after the component is load-bearing.