Open Source License Compliance Risk: The Enterprise Guide

Why Open Source Compliance Is Now a Board-Level Issue

Enterprise legal and procurement teams spent the last decade focused almost exclusively on commercial software audit risk — Oracle, SAP, IBM, Microsoft. Open source compliance lived in engineering and was treated as someone else's problem. That era is over.

Three converging forces have elevated open source licence compliance risk to board visibility. First, the Software Bill of Materials (SBOM) mandate embedded in US executive orders and EU Cyber Resilience Act requirements now places legal accountability for open source inventory on procurement and compliance functions, not just development teams. Second, the proliferation of large-scale GPL enforcement actions — including those brought by the Software Freedom Conservancy against major device manufacturers and software vendors — has demonstrated that organisations can face real legal consequences for copyleft non-compliance. Third, the explosion of AI and GenAI tooling built on open source foundations (PyTorch, TensorFlow, LLaMA, Llama-based derivatives) has introduced a new and largely uncharted compliance frontier for enterprise technology buyers.

Understanding open source licence compliance risk is no longer optional. It is a prerequisite for responsible enterprise software governance — and it connects directly to your overall software audit defence strategy.

Understanding the Open Source Licence Spectrum

Not all open source licences create equal risk. The critical variable is the level of "copyleft" obligation each licence imposes. Copyleft licences require that any software incorporating the licensed component must itself be made available under the same (or compatible) licence terms. For commercial enterprises, this can mean being compelled to publish proprietary source code — an outcome with significant competitive and commercial consequences.

Permissive Licences (Low Compliance Risk)

Permissive licences such as MIT, BSD-2, BSD-3, and Apache 2.0 impose minimal obligations. You can incorporate these components into proprietary software, modify them freely, and distribute without opening your source code. Your primary obligations are attribution (preserving copyright notices) and in some cases including the licence text with distributions. These licences represent the lowest open source compliance risk and are generally the preferred choice for enterprise procurement.

Weak Copyleft Licences (Moderate Compliance Risk)

Weak copyleft licences — most notably the GNU Lesser General Public License (LGPL) and Mozilla Public License (MPL) — occupy a middle ground. They apply copyleft obligations only to modifications of the licensed component itself, not to the broader application that links to it. An enterprise using an LGPL library in a commercial application does not need to open-source its application code, but it must make its modifications to the LGPL library available. Managing this distinction requires understanding the technical boundary between "the library" and "the application" — which in practice is often contested.

Strong Copyleft Licences (High Compliance Risk)

Strong copyleft licences — particularly the GNU General Public License (GPL v2 and v3) and the GNU Affero General Public License (AGPL) — impose the most demanding obligations. GPL requires that any software incorporating GPL-licensed code and distributed externally must be distributed as GPL (i.e., with source code made available). AGPL goes further: it captures use over a network, meaning that even SaaS products that merely run GPL software without distributing it may trigger source-disclosure requirements.

For enterprises building or distributing software products, strong copyleft components represent the highest-risk category in their open source inventory. For enterprises that are purely consumers of software (not distributors), the risk profile is different but not zero: if a software vendor you procure from is themselves non-compliant with open source obligations, that non-compliance may surface during a licence audit of your vendor ecosystem.

How Open Source Audits Are Triggered

Unlike commercial software audits, which are typically initiated by vendors asserting contractual audit rights, open source compliance actions are brought by copyright holders or organisations acting on their behalf. The three most common enforcement mechanisms are:

• Direct copyright holder enforcement: The original author or maintainer of a GPL component discovers non-compliant use (often through binary analysis or report from a third party) and issues a demand for compliance or initiates litigation.
• Advocacy organisation enforcement: Bodies such as the Software Freedom Conservancy, the Free Software Foundation, and gpl-violations.org actively monitor for GPL non-compliance and bring enforcement actions on behalf of copyright holders.
• M&A due diligence: Acquirers increasingly perform open source licence audits as part of technical due diligence. Non-compliance discovered at this stage can materially impact transaction valuation, trigger escrow requirements, or cause deals to collapse entirely.

A fourth and growing vector is supply chain audits. As enterprise procurement teams begin demanding SBOMs from software vendors as a condition of procurement, non-compliant vendors face indirect enforcement pressure through buyer requirements — a dynamic that will intensify significantly over the next three to five years.

Building an Open Source Governance Programme

The foundation of open source compliance is a functioning governance programme. For most enterprises, this means three things: inventory, policy, and process. Organisations that have invested in software asset management for their commercial estate often find they need to extend their SAM practice into open source — the tooling is different but the governance discipline is the same.

Step 1: Build and Maintain an SBOM

A Software Bill of Materials is the authoritative inventory of all open source components used across your software estate — including direct dependencies and transitive dependencies (the dependencies of your dependencies). Generating an SBOM requires integration with your build and development toolchain. Standard formats include SPDX (Software Package Data Exchange) and CycloneDX, both now widely supported by tooling providers.

Maintaining SBOM accuracy requires automated updates: every new dependency introduced by a development team should trigger an SBOM update and a licence compliance check. Manual SBOM maintenance in large enterprises is impractical and reliably produces gaps.

Step 2: Define an Approved Licence Policy

An approved licence policy establishes which open source licences may be used in which contexts. A typical enterprise policy distinguishes between: licences approved for use in any context (usually permissive licences), licences approved with conditions (often weak copyleft with specific technical controls), licences requiring legal review before use (usually GPL and AGPL), and licences prohibited entirely (licences with field-of-use restrictions or unduly onerous obligations).

The policy should be aligned with your distribution model: whether you distribute software externally, build only for internal use, or operate cloud-hosted services each produces a different obligation profile under copyleft licences.

Step 3: Implement Automated Compliance Scanning

Manual licence audits are periodic and incomplete. Automated scanning tools — such as FOSSA, Black Duck (Synopsys), WhiteSource (Mend), or open source tools like FOSSology — continuously scan your codebase and flag components that violate your approved licence policy. Integration into CI/CD pipelines allows compliance checks to run at every code commit, catching issues before they reach production.

Step 4: Establish a Remediation Process

When a non-compliant component is identified, the governance programme needs a defined remediation pathway. Options typically include: replacing the component with a permissively licensed alternative; obtaining a commercial licence from the open source vendor (many major open source projects offer dual licensing); modifying the architecture to isolate the component and eliminate distribution obligations; or seeking a legal opinion on whether the specific use case triggers the licence obligation. Remediation timelines should be defined by risk level, with high-risk GPL violations tracked to resolution with defined escalation paths.

AI and GenAI: The Emerging Open Source Compliance Frontier

The rapid enterprise adoption of AI and GenAI tools has introduced a new dimension of open source compliance risk that most governance programmes are not yet equipped to handle. The core challenge is that AI foundation models and fine-tuned derivatives are often built on open source code, trained on datasets that may include open source-licensed material, and distributed under licences that are themselves novel and untested in courts.

Models such as Meta's Llama series are released under custom licences that impose commercial restrictions not found in standard open source licences. Other models use Apache 2.0 for the model weights but separately licence the training code under GPL. Organisations deploying AI tools — whether open source models run on-premise or third-party AI APIs — need to extend their open source governance programme to cover AI component procurement. This is an area where specialist advisory support is frequently sought, given the pace of licence evolution and limited established legal precedent.

Open Source Compliance in M&A and Due Diligence

Open source compliance has become a standard element of technical due diligence in enterprise M&A transactions. Acquirers seek to understand the target's open source inventory, the proportion of code under copyleft licences, whether copyleft obligations have been honoured, and whether any enforcement actions are pending or threatened.

Non-compliance discovered in due diligence creates negotiating leverage for buyers and can result in price chips, indemnification requirements, or restructured representations and warranties. For sellers, having a mature open source governance programme in place before a process begins is increasingly a prerequisite for a clean transaction. Organisations that have deferred open source compliance work may find remediation is required as a condition of closing.

The same logic applies to procurement: enterprise buyers are increasingly including open source compliance representations in vendor contracts and requiring SBOMs from new software suppliers. If you are a software buyer, your vendors' open source compliance posture is becoming part of your risk profile — and how we work with procurement teams includes assessing this vendor supply chain risk.

Linking Open Source to Your Broader Audit Defence Programme

Open source compliance does not exist in isolation. It is one component of a broader licence and compliance risk management framework. Enterprises that have invested in software audit defence for their commercial estate should ensure open source governance is integrated into the same oversight structure — not siloed in engineering.

The integration points are practical: an SBOM that maps open source components connects naturally to an effective licence position statement. The governance committee that reviews commercial audit readiness should receive open source compliance status as a standing agenda item. The legal and procurement teams that manage commercial vendor relationships should also own the process for open source licence reviews in due diligence and procurement.

Organisations that approach open source governance as an engineering problem rather than a compliance and risk management problem consistently underinvest in it until an audit or transaction brings it into sharp focus. Building the governance programme ahead of that inflection point is significantly less expensive than remediating under duress. For support in building or assessing your programme, contact our advisory team.