Safeguard
Compliance

Copyleft Licenses: What They Mean for Your Code

A copyleft license requires that derivative works stay under the same license, which can force you to open-source code you thought was proprietary. Here is how copyleft works and how to manage the risk.

Safeguard Research Team
Research
6 min read

A copyleft license is an open-source license that grants you the freedom to use, modify, and distribute software on the condition that any derivative work you distribute is released under the same license terms. The name is a play on "copyright": instead of restricting reuse, it uses copyright law to guarantee that the freedoms travel with the code. That reciprocity is powerful for the commons and genuinely risky for a business that does not understand what it signed up for.

How copyleft differs from permissive licensing

Open-source licenses fall broadly into two camps. Permissive licenses like MIT, BSD, and Apache 2.0 let you do almost anything, including folding the code into a closed-source product, as long as you preserve the copyright notice. There is no obligation to share your changes.

A copyleft license adds a reciprocal condition. If you distribute software that incorporates copyleft-licensed code, you must make your corresponding source available under the same license. The classic example is the GNU General Public License (GPL). Ship a product that links GPL code into your own, distribute it to customers, and the GPL's terms can require you to offer the full source of that combined work.

This is why license classification is a compliance question, not a legal footnote. Pulling in one strongly copyleft dependency can change the obligations attached to your entire distributed application.

Strong versus weak copyleft

Not all copyleft is equally demanding, and the distinction decides how much of your code is affected.

Strong copyleft extends the reciprocal obligation to the whole combined work. The GPL family is the canonical example. If your application links GPLv2 or GPLv3 code and you distribute the result, the copyleft reaches across the linkage boundary to your own source.

Weak copyleft limits the obligation to the licensed component itself. The GNU Lesser General Public License (LGPL) is the common example: you can link an LGPL library into a proprietary application and keep your own code closed, provided you meet conditions like allowing the user to replace the library. The Mozilla Public License (MPL 2.0) is file-level copyleft, meaning changes to MPL-covered files must be shared, but code in your own separate files is not affected.

The AGPL (GNU Affero GPL) deserves special mention because it closes the so-called "SaaS loophole." Ordinary GPL obligations trigger on distribution, and running software as a network service is not traditionally distribution. AGPL treats offering the software over a network as a triggering event, so a hosted service built on AGPL code can incur the source-sharing obligation even though no binary ever leaves your servers. Many companies ban AGPL dependencies outright for this reason.

What actually triggers the obligation

The word that matters throughout copyleft licenses is "distribute." The obligations generally attach when you convey the software to someone else, whether as a binary, an appliance, or embedded in a device you ship. Purely internal use, running GPL code on your own servers for your own employees, usually does not trigger the source-sharing requirement under the standard GPL. AGPL is the exception that reframes network use as a trigger.

This is genuinely nuanced, and reasonable lawyers disagree on edge cases like dynamic linking, plugin architectures, and containerized deployment. Treat the summaries here as engineering guidance for spotting risk, not as legal advice for a specific product decision. When a copyleft obligation might attach to a commercial product, get counsel who does open-source licensing.

Building a practical policy

Most engineering organizations settle on a tiered policy that developers can follow without a lawyer on speed dial:

  • Allowed by default: permissive licenses (MIT, BSD, Apache 2.0, ISC).
  • Allowed with review: weak copyleft (LGPL, MPL) where the usage keeps the boundary clean.
  • Restricted or banned: strong copyleft (GPL) in distributed products, and AGPL in almost all commercial contexts.

The policy only works if it is enforced automatically. Nobody reads every transitive license by hand, and copyleft code most often enters through a dependency several levels deep that no one directly chose.

Detecting copyleft in your dependency tree

The dangerous case is a strongly copyleft library that arrives transitively, because your own top-level dependencies looked clean. License scanning resolves the full graph and reports the license of every package, direct and transitive. A software composition analysis tool inventories those licenses and can gate a build when a banned license appears, so an AGPL package five levels down fails CI instead of shipping quietly. An SBOM makes the same information portable, listing every component and its license so audits and customer questionnaires become lookups rather than investigations.

# Example: surface licenses from an npm project
npx license-checker --summary

Tools such as Safeguard can enforce a license policy as part of the same scan that checks for vulnerable dependencies, so compliance and security share one gate. For teams new to the topic, the Safeguard Academy covers how license obligations map to distribution models.

FAQ

Does using a GPL library mean I have to open-source my whole application?

If you distribute a work that incorporates strongly copyleft (GPL) code, the license can require you to release the corresponding source of the combined work under the GPL. Internal-only use generally does not trigger this, and weak copyleft licenses limit the obligation to the component itself. Specifics depend on how you link and distribute, so consult counsel for a real product.

What is the difference between GPL and LGPL?

GPL is strong copyleft: its obligations extend to the whole combined work you distribute. LGPL is weak copyleft: you can link the library into proprietary software and keep your own code closed, provided you meet the license's conditions such as allowing the library to be replaced.

Why do companies avoid AGPL?

AGPL treats providing the software over a network as a distribution-like trigger, closing the SaaS loophole. A hosted service built on AGPL code can incur the source-sharing obligation even without shipping a binary, so many companies ban it in commercial products.

How do I find copyleft licenses hidden in transitive dependencies?

Use a license or software composition analysis scanner that resolves the full dependency graph and reports each package's license. Generate an SBOM so the license inventory is complete and portable, and add a CI gate that fails the build when a restricted license appears.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.