An open source licensing cheat sheet

The main licence families on one page, plus how code gets combined, what SaaS changes, and what due diligence looks for.

Articles

Open source is in almost every commercial codebase. A typical SaaS product pulls in numerous packages before anyone writes a line of code, and each one arrives with a licence attached.

The cheat sheet

This table assumes a closed-source commercial product where the team’s own code stays private. A tick means the licence generally allows that use without requiring the code to be published. An asterisk means conditions apply.

Licence Family Closed-source product? SaaS? Comments
MIT Permissive Yes Yes Retain copyright/licence notice
Apache 2.0 Permissive Yes Yes Retain notices; patent grant protects users
BSD Permissive Yes Yes Retain notices
MPL 2.0 Weak copyleft Yes Yes Modified MPL-covered files must remain open
LGPL Weak copyleft Yes* Yes *Assumes dynamic linking. Changes to the library itself must remain open
GPL Strong copyleft No Yes* *Server-side use generally doesn’t trigger distribution; client-side code may
AGPL Strong copyleft No No Adds network use to the GPL’s distribution triggers

The main open source licence families

Permissive

MIT, BSD, and Apache 2.0 cover most of the open source in commercial products, and they’re the easy case. The code can be used, modified, and sold in closed-source products, provided the copyright and licence notices travel with it. That notice obligation is real, and it’s the one permissive requirement teams routinely forget. Apache 2.0 adds two things worth knowing. The first is an explicit patent grant from contributors, which means that anyone using the code gets protection from patent claims. The second is a requirement for modified files to carry a notice saying they’ve been changed.

Weak copyleft

MPL 2.0 and the LGPL sit in the middle. The share-alike obligation applies to the licensed component rather than the whole product. Under MPL 2.0, changes to MPL-licensed files must be published, while everything else stays proprietary. The LGPL was designed for libraries. Using one unmodified via dynamic linking is broadly accepted in closed-source products, though modifications to the library itself must be shared, and static linking or mobile packaging complicate the picture.

Strong copyleft

This family asks for the most. Distribute a product containing GPL code, or a derivative of it, and the whole work generally has to ship under the GPL with source available. That makes it a poor fit inside proprietary desktop or mobile software. Where a copyleft component is genuinely essential, dual licensing is often the practical route: several vendors offer the same code under a commercial licence for exactly this situation.

How code gets combined

Copyleft obligations often turn on how tightly an application is combined with a library, so it’s worth being concrete about the ways that happens.

  • Static linking. The library’s compiled code is copied into the executable at build time, so the product ships as one binary with the library baked in. The clearest case of a combined work. Bundled JavaScript ends up in much the same position: the build combines dependencies into the single file that ships to the browser.

  • Dynamic linking. The library stays a separate file (such as a .dll) that the application loads at runtime. Referencing a NuGet package works this way, as does a page loading a library as a separate .js file. This separation is what the LGPL relies on: a proprietary application can dynamically link an LGPL library, provided users can swap in their own version.

  • Vendoring. Library source copied straight into the repo, anything from a whole project to a pasted function. Licensing-wise it’s the same position as static linking, and easier to lose track of because no dependency manifest records it.

Keeping notices intact

The notice obligation has a practical wrinkle in JavaScript builds: minifiers strip comments by default, and licence headers are just comments. Comments marked /*!, @license or @preserve are treated as legal comments by convention and generally survive minification. Many build tools go further, extracting licence text into a separate file alongside the bundles, which is why build output often includes a licence file nobody remembers asking for. Deleting it from deployed assets defeats its purpose.

Surviving headers only cover libraries whose authors annotated them, and many packages keep their licence in a separate file that never gets near the bundle. The dependable approach is generating notices from package metadata. Every major ecosystem has tools that walk the dependency tree and emit a complete third-party notices file. The output can ship with the product or sit behind an “open source licences” screen in the app.

What SaaS changes

The GPL’s obligations trigger on distribution. Software that runs server-side and is never shipped to users generally doesn’t count as distributed, making it attractive in SaaS backends. The frontend is different: JavaScript bundled and shipped to the browser is distributed, so GPL code there carries the usual obligations. The Free Software Foundation regards this as a loophole, and the AGPL exists to close it: its obligations can extend to software users interact with over a network.

That distinction makes the AGPL the licence most worth actively looking for in a SaaS codebase. The obligations turn on the detail of how the component is used and modified, but many larger companies don’t engage with that nuance at all. Google, for instance, simply prohibits AGPL software in its code.

Due diligence

Licence scanning is a standard part of technical due diligence, and the findings follow a pattern: a copyleft dependency in a proprietary codebase, vendored code with no licence at all, or a component whose licence changed without anyone noticing. Most findings can be addressed: swapping the dependency, isolating it behind a service boundary, buying a commercial licence, or complying with notice obligations that were being ignored. If the buyer’s advisors raise these issues during exclusivity, they can become expensive to resolve.

For sell-side teams, the preparation is cheap: run an automated licence scan against the dependency manifests, keep the output as part of a software bill of materials, and resolve anything copyleft-shaped before a buyer finds it. For buyers, the scan is expected, and the more telling question is whether the target can explain its own dependency choices.

For anyone preparing for a transaction, or simply wanting a clear view of what’s in the codebase, a short exploratory conversation is a sensible first step.

References