Open source code powers 95% of enterprise applications, yet 80% of organisations lack comprehensive compliance frameworks. This guide covers GPL, AGPL, Apache 2.0, MIT, and other license risks — helping procurement, legal, and engineering teams implement practical controls that prevent costly violations and audit exposure while maintaining development velocity.
Open source components are embedded in virtually every enterprise application, database, framework, and infrastructure tool. Yet while the business benefits of open source are clear — faster development, cost savings, innovation — the legal and compliance obligations are often overlooked until a problem surfaces.
The compliance risk comes from the fact that open source licenses impose obligations on downstream users. These obligations range from simple attribution requirements (MIT, Apache 2.0) to complex source code disclosure requirements (GPL, AGPL). Violating these obligations can expose organisations to legal liability, forced source code release, or costly settlements.
Unlike commercial software licenses (where the vendor owns the code and determines the terms), open source projects are typically community-controlled. A developer can embed GPL-licensed code in your application without understanding the legal implications. Six months later, your compliance team discovers the violation during an acquisition due diligence, or worse, receives a cease-and-desist letter from the software security auditor of an upstream licensor.
GPL (GNU General Public License) is "copyleft" — if your code links to or incorporates GPL-licensed code, the entire application must be released under GPL. This obligation flows downstream. AGPL adds the same obligation to network access (cloud/SaaS deployments). Many organisations unknowingly violate these terms.
Open source licenses fall into three broad categories, each with different compliance implications:
Want independent help negotiating better terms? We rank the top advisory firms across 14 vendor categories — free matching, no commitment.
MIT, Apache 2.0, BSD, and ISC licenses are permissive. They allow you to use the code for any purpose — commercial, proprietary, closed-source — with minimal obligations. The primary requirement is attribution: you must include the license text and a notice that the code is used. Attribution is typically done in a LICENSES or NOTICES file. These licenses create low compliance risk if attribution is properly maintained.
LGPL (Lesser General Public License) is weak copyleft. You can use LGPL code in proprietary applications, but any modifications you make to the LGPL-licensed code must be released under LGPL. If you use an LGPL library as a dynamic link (DLL, SO file), the copyleft obligation is typically limited. Static linking or modifications trigger disclosure obligations.
GPL (GNU General Public License) and AGPL (Affero General Public License) are strong copyleft. Any code that links to or incorporates GPL code must be released under GPL. AGPL extends this to cloud/SaaS deployments — if you modify AGPL code and run it as a service, you must release source code to users. These create the highest compliance risk.
GPL violations are the most common open source compliance issue. A typical scenario: a developer uses an open-source tool (e.g., a build tool, framework component, or library) that happens to be GPL-licensed. The developer doesn't realise the GPL obligation. The code makes its way into production. When a compliance audit surfaces the violation, the organisation faces three options: release source code (operationally and commercially infeasible), negotiate a commercial license with the copyright holder, or reach a settlement.
AGPL creates an additional risk for SaaS and cloud deployments. AGPL requires that if you modify the code and run it as a service, you must make source code available to all users. This is fundamentally incompatible with proprietary SaaS business models. A SaaS company that unknowingly incorporates AGPL-licensed code faces a choice: stop the deployment, switch to a different license, or negotiate a commercial license.
A single application can include components under five or ten different licenses. Some license combinations are incompatible. For example, GPL v2 and GPL v3 are technically compatible (both are copyleft), but GPL v2 is not compatible with the AGPL — a project that combines them violates both licenses' terms.
Get the IT Negotiation Playbook — free
Used by 4,200+ IT directors and procurement leads. Oracle, Microsoft, SAP, Cloud — all covered.
Apache 2.0 has known compatibility issues with GPL v2. The FSF (Free Software Foundation) has stated that Apache 2.0 code cannot legally be combined with GPL v2 code without violating one license or the other. This creates a compliance violation in any application that includes both.
A comprehensive compliance framework must map all component licenses and identify conflicts before code reaches production.
The first step in open source compliance is knowing what you have. Most organisations lack complete visibility into their open source footprint. This creates risk: you cannot manage what you cannot see.
Component discovery requires both automated tools and manual processes. Automated Software Composition Analysis (SCA) tools scan codebases, build logs, and dependency managers to identify open source components. These tools work well for direct dependencies (libraries you explicitly include) but miss transitive dependencies (libraries that your libraries depend on).
A complete inventory should include: component name, version, license type, dependencies, known vulnerabilities, and source location (GitHub URL, etc.). This inventory should be updated regularly as code is added or dependencies change.
An effective open source compliance framework has four layers: policy, process, tools, and training.
Policy: Define which licenses are acceptable for use. Most organisations adopt a tiered approach: Tier 1 (preferred) includes permissive licenses like MIT, Apache 2.0, and BSD. Tier 2 (acceptable with review) includes weak copyleft licenses like LGPL, where copyleft obligations can be managed through dynamic linking. Tier 3 (requires escalation or commercial license) includes GPL and AGPL. Some organisations ban Tier 3 licenses entirely.
Process: Establish a change control process for introducing new open source components. Before code merges to main or production, the component and its dependencies must be scanned and validated against policy. If a prohibited license is detected, the developer has two options: substitute a compliant component, or request a policy exception with engineering, legal, and procurement review.
Tools: Invest in automated SCA tooling integrated into your build pipeline. Tools like Black Duck, Snyk, and FOSSA perform continuous scanning and alert when violations are detected. These should feed into your bug tracking system so violations are tracked and remediated like any other defect.
Training: Developers must understand the basics of open source licensing and the organisation's compliance policy. A single hour of training per developer per year prevents 80% of compliance violations.
Manual open source compliance review does not scale. Large codebases can include hundreds of direct dependencies and thousands of transitive ones. Automated tools are essential.
Software Composition Analysis (SCA): Tools like Black Duck, WhiteSource (now part of Mend), Snyk, and FOSSA perform deep component scanning. They identify components, versions, licenses, and known vulnerabilities. Integration into your CI/CD pipeline means every code commit triggers an automated scan.
License Reporting: Automated tools should generate compliance reports showing all components, licenses, and conflicts. These reports should be reviewed quarterly and retained for audit purposes.
Vulnerability Management: Open source component vulnerabilities are common. A good SCA tool integrates vulnerability data from the National Vulnerability Database (NVD) and alerts when known CVEs are detected in your components. Vulnerability remediation should be treated like any other security defect.
Implement continuous monitoring, not point-in-time audits. As your codebase evolves and dependencies are added, compliance must be checked at each merge, not quarterly. Automated SCA tools with CI/CD integration make this practical and efficient.
When acquiring, integrating with, or partnering with vendors, open source compliance should be a standard due diligence item. Many companies have discovered GPL violations (and the associated liability) only after a vendor integration or acquisition.
During vendor assessment, request: a Software Bill of Materials (SBOM) listing all components and versions, an SCA scan report showing licenses and vulnerabilities, and attestation of the vendor's compliance practices. Many sophisticated vendors maintain this information proactively; others will need to be asked to produce it.
For M&A transactions, open source compliance review should be part of legal due diligence. A target company with significant GPL violations could face compliance obligations that become the acquirer's liability post-close.
When a compliance violation is discovered, the response depends on severity and risk tolerance.
Permissive license violations (missing attribution): Low risk. Add the missing attribution to your NOTICES file and update internal tracking. No legal exposure.
Weak copyleft violations (LGPL modifications): Medium risk. If you've modified LGPL code, you must release your modifications (not the full application) under LGPL. Release the modified component to a repository or GitHub, document the change, and update your compliance records. No forced release of proprietary code.
Strong copyleft violations (GPL in proprietary code): High risk. Options: (1) Replace the component with a non-GPL alternative if possible; (2) Negotiate a commercial license with the copyright holder; (3) If the violation is in production, consider releasing a specific module under GPL (if feasible) while keeping the rest proprietary; (4) Reach a settlement with the copyright holder if they pursue enforcement.
AGPL in SaaS: Critical risk. If AGPL code is running in your SaaS environment, you must either release source code, switch the component, or negotiate a commercial license. This cannot be delayed.
Organisations should maintain a register of all open source compliance issues, remediation actions, and resolutions. This documentation is critical if enforcement action ever occurs — it demonstrates good faith compliance efforts.
Whether you need to build a compliance framework, remediate existing violations, or prepare for an acquisition — specialist advisory ensures you have the right controls and processes in place.