Modern commercial software is built on open source foundations. Studies of enterprise software consistently find that a large majority of commercial products contain open source components, and the typical application includes hundreds of open source libraries, frameworks, and tools assembled through package managers and dependency chains. For most software businesses, this is simply how software development works today. What is less universally understood is that each open source component carries a licence with legal obligations that the incorporating company must fulfil, and that failure to fulfil those obligations creates IP infringement risk, M&A complications, and potential commercial disputes. Managing open source compliance is not a legal nicety but an operational requirement for any technology business.
The Spectrum of Open Source Licences
Open source licences range from highly permissive to strongly copyleft, and the distinction determines whether and how a component can be incorporated into commercial software. Understanding the spectrum is the foundation of any open source compliance programme.
Permissive licences — including MIT, BSD (2-clause and 3-clause), and ISC — impose minimal obligations. The primary requirements are to include the original copyright notice and licence text in the distribution, and in some cases (BSD 3-clause) not to use the original authors’ names in promotional materials without permission. Permissive components can be incorporated into proprietary software without any obligation to disclose or release the incorporating code. They are the most commercially friendly open source licences and are used in widely adopted libraries including React, Express, Flask, and many others.
The Apache 2.0 licence is also permissive but adds specific provisions regarding patents. It includes an express patent licence from contributors and contains a patent termination clause: if a licensee initiates patent litigation against the project or any contributor, the licence terminates. This patent provision makes Apache 2.0 attractive for enterprise use — the express patent licence provides more legal certainty than pure permissive licences on patent risk — but companies in patent-intensive sectors should be aware of the termination provision before building patent strategy around Apache-licensed components.
Copyleft licences — including the GNU General Public Licence (GPL), the GNU Affero General Public Licence (AGPL), the GNU Lesser General Public Licence (LGPL), and the Mozilla Public Licence (MPL) — impose the critical obligation that derivative works distributed to third parties must be released under the same (or a compatible) copyleft licence with source code available. This is the viral or share-alike mechanism: if a copyleft component is incorporated in a distributed binary, the entire combined work must be made available under the copyleft licence, including the source code for the commercial proprietary portions.
GPL: The Commercial Risk in Detail
The GPL version 2 and GPL version 3 are the licences of some of the most widely used open source software in the world, including the Linux kernel (GPL v2), GCC, and many system utilities. For most commercial software companies, the operative question is whether their use of GPL-licensed code triggers the GPL’s copyleft obligations.
The GPL’s obligations apply to distribution: if you distribute software that is a derivative work of or combined with GPL-licensed code, you must distribute the source code of the entire combined work under the GPL. Distribution means making the software available to third parties — selling it, providing it as a SaaS service does not (under GPL v2 and v3) constitute distribution, though AGPL addresses this specifically. For companies distributing software to end users — as installed applications, firmware, embedded systems, or downloadable software — any GPL component in the distribution potentially triggers the disclosure obligation for the entire product.
What constitutes a derivative work for GPL purposes is one of the most contested questions in open source law, and the answer is not definitively settled in any jurisdiction’s case law. The Free Software Foundation’s position, as expressed in the GPL’s preamble and FAQs, is that dynamic linking (using a GPL library through the operating system’s shared library mechanism) creates a derivative work requiring GPL compliance on the incorporating program, but static linking unambiguously does. Many commercial lawyers take a narrower view, arguing that dynamic linking may not create a derivative work depending on the degree of integration and the independence of the components. The lack of definitive judicial authority on this question in Europe creates genuine legal uncertainty for companies whose products use GPL-licensed libraries through dynamic linking.
LGPL: The Commercial Compromise
The GNU Lesser General Public Licence was designed specifically to allow libraries to be used in proprietary software without triggering GPL obligations on the incorporating application. LGPL-licensed libraries — including glibc (the GNU C library), GTK, and various multimedia libraries — can be incorporated in proprietary software provided that the user can replace the LGPL library with a modified version. This typically means dynamic linking and providing the object files of the proprietary application so that the user can relink with a modified version of the LGPL library.
In practice, complying with LGPL’s relinking requirement is often overlooked by commercial developers who are aware of the basic rule that LGPL allows commercial use but have not implemented the specific technical requirements. An audit of commercial software that incorporates LGPL libraries frequently reveals that the relinking mechanism has not been implemented, making the distribution technically non-compliant even though no disclosure of proprietary source code is required.
AGPL: The SaaS Trap
The GNU Affero General Public Licence version 3 was created to close the SaaS loophole in the GPL. Under AGPL, if a company uses AGPL-licensed software to provide a network service — including a web application, API, or SaaS product — users of that service have the right to receive the source code of the modified AGPL-licensed software. This provision effectively extends the copyleft obligation to SaaS use, meaning that a SaaS company whose product incorporates AGPL components must make the source code of those components (and in the FSF’s interpretation, the code they are combined with) available to users of the service.
Several significant open source projects have adopted the AGPL specifically to prevent commercial SaaS providers from offering hosted versions of the software without contributing back: MongoDB, Redis (earlier versions), Elasticsearch (earlier versions), and various developer tools have used AGPL or AGPL-inspired licences as part of a dual-licensing strategy. For SaaS companies and cloud providers, the AGPL is the most commercially sensitive copyleft licence, and standard enterprise software procurement and development policies frequently prohibit or restrict the incorporation of AGPL components without legal review.
Open Source in M&A: The Due Diligence Imperative
Open source licence compliance has become a standard component of technology M&A due diligence. Acquirers of software businesses routinely commission software composition analysis (SCA) scans of the target’s codebase to identify all open source components and their licences, assess compliance with the applicable obligations, and identify any potential copyleft contamination that could require disclosure of proprietary source code or constrain the acquirer’s ability to distribute the software. The results of this analysis feed into the representations and warranties negotiation and, where issues are identified, into the indemnity or escrow provisions of the acquisition agreement.
Acquirers have discovered copyleft obligations that were unknown to the target’s management, sometimes because the GPL component was introduced by a developer who was unaware of the implications, and sometimes because the component arrived as an indirect dependency of another library rather than being deliberately chosen. Modern dependency chains can be deep: a primary library may itself depend on dozens of libraries, each with their own licence, creating transitive licence obligations that the developer of the primary code never saw. Automated SCA tooling is now mature enough to analyse these dependency chains at scale, and using it before completing a technology acquisition is considered standard practice.
Building an Open Source Compliance Programme
For technology companies, managing open source compliance requires a combination of policy, process, and tooling. At the policy level, companies should establish an approved licence list that categorises licences by commercial use type (permissive, weak copyleft, strong copyleft, restricted) and specifies the approval requirements for each category. Components under permissive licences can typically be used without formal approval beyond standard code review; components under strong copyleft licences should require legal review before incorporation.
At the process level, open source intake — the review of new components being added to the codebase — should be integrated into the development workflow, not treated as a separate compliance exercise. Modern source code management platforms can integrate with SCA tools to flag licence issues at the pull request stage, before non-compliant components are merged into the main codebase. Periodic audits of the full dependency graph, including indirect dependencies, ensure that licence obligations introduced through upstream changes are identified promptly.
Notice management — maintaining accurate lists of incorporated open source components and providing required notices (copyright notices, licence texts, attribution statements) in distributed software — is a compliance obligation under virtually every open source licence and is frequently the most operationally demanding aspect of an open source compliance programme in practice. Automated notice generation tools that produce the required NOTICES or LICENSE files from the SCA analysis are an important element of any mature compliance programme.
Conclusion
Open source components are essential ingredients in modern commercial software, and the legal obligations they carry are real and enforceable. The range of obligations spans from the minimal attribution requirements of permissive licences to the full source code disclosure requirements of GPL and AGPL in distribution and SaaS contexts. Effective open source compliance requires systematic tooling, integrated development workflows, clear policy, and periodic legal review — and it requires the same rigour in the M&A context, where inherited open source obligations can affect the value, structure, and regulatory risk of a technology acquisition. Companies that treat open source licence management as a background task rather than a core IP discipline do so at risk of the remediation costs and commercial disruption that IP compliance failures in a scaled commercial product can cause.