Licence exposure is rarely the only gap. If the code in question ships as a hosted product rather than a download, the copyleft analysis sits inside a wider inventory of SaaS intellectual property rights — patents, copyright registration, trade secrets, class 42 marks and the contractor assignments that decide who owns the code at all.
Table of Contents
Open source software has become foundational to modern technology development, but using open source code without understanding its licensing terms can create serious legal and business risks. Open source licenses grant broad permissions to use, modify, and distribute code, but they also impose conditions that can affect the rights of IP owners who incorporate open source components into their products. PerspireIP advises businesses on open source license compliance and IP risk management in the context of modern software development.
What Are Open Source Licenses?
Open source licenses are copyright licenses that grant recipients broad rights to use, copy, modify, and distribute software. Unlike proprietary licenses that restrict what users can do with software, open source licenses empower developers to build upon existing code. However, open source is not the same as license-free. All open source software is protected by copyright, and the license governs what you can and cannot do with the code. Violating the terms of an open source license is copyright infringement, with all the legal consequences that entails.
Types of Open Source Licenses
Permissive Licenses
Permissive open source licenses impose minimal conditions on users. The most widely used permissive licenses include the MIT License, the Apache License 2.0, and the BSD licenses. These licenses generally require only that the original copyright notice and license text be included in distributions. They allow users to incorporate the open source code into proprietary commercial software without imposing any requirements on the proprietary portions. From an IP ownership perspective, permissive licenses are the most business-friendly because they do not affect the ownership or licensing terms of your own code.
Copyleft Licenses
Copyleft open source licenses use copyright law to ensure that derivative works remain open source. The GNU General Public License (GPL) is the most prominent example. If you incorporate GPL-licensed code into your software, the GPL requires that the entire combined work be distributed under the GPL terms, effectively requiring you to make your proprietary code available as open source. This is sometimes called the viral effect. Strong copyleft licenses like the GPL v2 and v3 present significant IP risks for businesses building proprietary products.
Weak Copyleft Licenses
Weak copyleft licenses, such as the GNU Lesser General Public License (LGPL) and the Mozilla Public License (MPL), apply copyleft requirements only to modifications of the original code, not to larger works that merely use or link to it. Under the LGPL, for example, you can use an LGPL-licensed library in your proprietary software by linking to it dynamically, without being required to open source your proprietary code. Understanding the distinction between strong and weak copyleft is essential for IP owners managing open source usage in commercial software.
Key Open Source Licenses Compared
- MIT License: Maximum permissiveness, minimal conditions, IP-friendly for proprietary development
- Apache License 2.0: Permissive with an express patent license grant, protects users from patent infringement claims by contributors
- GPL v2: Strong copyleft, requires derivative works to be GPL-licensed
- GPL v3: Strong copyleft with additional provisions addressing tivoization and patent retaliation
- LGPL v2.1: Weak copyleft, allows dynamic linking from proprietary software
- MPL 2.0: File-level copyleft, modifications to MPL files must remain MPL-licensed but can be combined with proprietary code
- AGPL: Like GPL but extends copyleft to software used over networks, critical for SaaS applications
- Creative Commons: Not for software code but widely used for documentation, creative assets, and data
The Business Risks of Open Source Non-Compliance
Open source license violations can have serious consequences. The Software Freedom Conservancy and other organizations actively enforce copyleft license conditions on behalf of copyright holders. Enforcement actions can result in injunctions requiring you to stop distributing your product, demands to publish your proprietary source code, and lawsuits for copyright infringement damages. In highly publicized cases, companies have been forced to open source products they developed at great expense or to withdraw products from the market. Investors and acquirers also scrutinize open source compliance as part of due diligence, and undisclosed open source obligations can kill deals or result in price reductions.
Open Source Auditing and Compliance Programs
Every company that develops software should implement an open source governance program. This includes maintaining an inventory of all open source components used in your products and their respective licenses, reviewing license obligations before incorporating new open source components, establishing a process for approving use of open source with copyleft terms, ensuring that attribution notices required by permissive licenses are included in all distributions, and training developers on open source license compliance. Tools such as FOSSA, Black Duck, and Snyk can automate open source license scanning and help maintain compliance at scale.
Open Source and M&A Due Diligence
In merger and acquisition transactions involving software companies, open source license compliance is a critical due diligence area. Buyers conduct open source audits to identify all open source components in the target’s software, assess compliance with license obligations, and evaluate the risk that copyleft obligations might require disclosure of proprietary source code. Material open source issues can affect deal structure, representations and warranties, indemnification provisions, and valuation. PerspireIP assists both buyers and sellers in preparing for and conducting open source due diligence in M&A transactions.
What Actually Triggers Copyleft — and What AGPL Adds
The single most consequential question in compliance is not which licence applies but whether you have done the thing that activates its obligations. For the GPL family, the trigger is conveying the software to someone else. Purely internal use and internal modification generally do not oblige you to publish anything, which is why a great deal of private GPL-licensed modification sits quietly inside companies without issue.
That is also why so many teams misjudge their exposure the moment a product ships. Distributing a binary built from copyleft-licensed source brings the corresponding-source obligation with it, and embedding the code in a device is distribution. Shipping is the event that converts a licence into a deliverable.
The AGPL closes the gap that mattered most in the cloud era. Its section 13 extends the obligation to remote network interaction: if users interact with a modified version over a network, they must be offered the corresponding source. For a hosted service built on AGPL code, there is no distribution-free safe harbour — running it as a service is itself the trigger.
This is why AGPL components are frequently placed on internal prohibited lists for SaaS products, while the same organisation accepts GPL code in internal tooling without concern. The licences are not differently strict in the abstract; they are differently matched to how the software is delivered.
Patent Grants and Retaliation Clauses
Most discussion of open source licensing treats it as a copyright question. For an IP owner, the patent terms are often the more consequential half, and they differ markedly between licences that otherwise look similar in permissiveness.
Apache 2.0 contains an express patent licence in section 3: each contributor grants a patent licence covering their contribution. It pairs that with a retaliation provision — initiating patent litigation alleging that the work infringes terminates the patent licence granted to you. GPL-3.0 addresses patents in its section 11 along comparable lines. These are deliberate, negotiated grants.
MIT and the BSD licences, by contrast, are silent on patents. They grant broad copyright permissions and leave patent rights to be argued about under implied-licence and exhaustion theories, which is a materially weaker position for a user and a materially freer one for a contributing patent holder.
- Contributing code under Apache 2.0 or GPL-3.0 means granting patent rights over that contribution — review it against your portfolio before approving the contribution.
- Depending on an MIT or BSD component gives you no express patent peace from its contributors.
- A patent-assertion strategy can be undercut by your own engineers’ upstream contributions, so contribution policy and licensing strategy belong in the same conversation.
For companies that both hold patents and contribute code, this is the point at which open source governance stops being a legal-ops task and becomes an IP strategy decision.
Compatibility: Why Two Open Licences Can’t Always Be Combined
Permissive and copyleft code can usually be combined in one direction only: permissive code can generally be absorbed into a copyleft work, while copyleft code cannot be relicensed into a permissive one. That asymmetry is the whole of the practical rule, and it determines the licence of the combined result.
Within copyleft, version matters. The Free Software Foundation treats Apache 2.0 as incompatible with GPLv2 but compatible with GPLv3, because of the patent and indemnity terms GPLv2 does not accommodate. A dependency graph that mixes Apache 2.0 and strict GPLv2-only code therefore has a genuine problem that no amount of attribution fixes.
MPL-2.0 behaves differently again. Its copyleft operates at file level rather than across the whole combined work, which makes it considerably easier to use alongside proprietary code, and it includes provisions designed to ease combination with GPL-family licences.
The operational answer is to resolve compatibility at dependency-selection time. Discovering an incompatible transitive dependency during an acquisition means rewriting working software under time pressure, which is the most expensive possible moment to learn about it.
Enforcement Is No Longer Theoretical
For years the practical risk calculus rested on an assumption that enforcement was rare and resolved quietly through community pressure. That assumption has weakened, and the theory of liability has broadened in a way IP owners should understand.
The Software Freedom Conservancy’s litigation against Vizio in California advanced a notable theory: rather than suing only as a copyright holder, it framed the GPL as a contract under which downstream recipients are third-party beneficiaries entitled to demand corresponding source. The California courts allowed that contract theory to proceed rather than dismissing it as preempted by copyright law.
If that framing holds, the population of potential claimants changes shape entirely. It is no longer only upstream authors who might object; it is customers who received a device. That is a materially different risk profile for any hardware or appliance business.
Practically, the response is unglamorous and effective: maintain an accurate bill of materials, keep the corresponding source for every shipped build actually retrievable, and publish complete written offers where a licence requires one. Most compliance failures are record-keeping failures rather than deliberate decisions.
Building a Policy Engineers Will Actually Follow
Compliance programmes fail for predictable reasons. The policy is written as a prohibition, approval takes a week, and engineers route around it because a dependency is needed today. A programme that is slower than the development cycle will be bypassed, and bypassing it produces exactly the undocumented dependencies it was meant to prevent.
The design principle is to pre-decide the common cases so that almost nothing needs human review. Most organisations can classify the great majority of licences into three buckets and let tooling enforce the result.
- Pre-approved — permissive licences such as MIT, BSD and Apache 2.0 for ordinary use, with attribution handled automatically at build time.
- Conditional — copyleft licences allowed in contexts that do not trigger distribution, for example internal tooling and build infrastructure.
- Review required — AGPL and similar in anything network-facing, anything to be embedded in a shipped device, and any licence not already classified.
Enforcement belongs in continuous integration rather than in a policy document. A scanner that resolves the full transitive dependency tree and fails the build on an unclassified or disallowed licence catches problems at the moment they are cheapest to fix — when a developer is choosing a library, not when a customer is waiting for a release.
Generate a machine-readable bill of materials for every build and keep it with the artefact. Standard formats such as SPDX and CycloneDX exist precisely so this record survives staff turnover, and an accurate inventory is what converts a frightening diligence request into a routine one.
Contribution needs its own rule, because it is where the patent terms discussed above actually bite. Decide whether outbound contributions are made under the project’s inbound licence, who may sign a contributor licence agreement on the company’s behalf, and whether a particular contribution grants patent rights you would rather retain. Engineers contributing in good faith can give away more than anyone intended simply because nobody had set the rule.
Finally, assign ownership. A programme without a named owner degrades quietly: scanners drift out of date, exceptions accumulate without review, and the inventory stops matching what ships. One accountable owner and a quarterly review is usually enough to keep it honest.
It is also worth settling in advance what happens when a violation is found, because it will be. The options are narrow and both are acceptable: comply with the licence, or remove and replace the component. What is not acceptable is leaving it unresolved while continuing to ship, since that converts an inadvertent breach into a documented and knowing one.
Record the decision either way. A short written note of what was found, what was done and who approved it is the artefact that turns an awkward conversation with an acquirer or a licensor into a demonstration that the programme works. Most organisations are judged less on having had a violation than on how quickly and verifiably they closed it.
Conclusion
Open source licenses are powerful tools that enable collaborative software development, but they impose real obligations on IP owners who use open source code. Understanding the difference between permissive and copyleft licenses, maintaining a comprehensive open source inventory, and implementing a governance program are essential practices for any software business. PerspireIP provides open source compliance audits, licensing advice, and M&A due diligence support to help businesses manage open source IP risk effectively.