The usual approach to open-source licence compliance is to memorise a list: MIT, Apache and BSD are safe; GPL and AGPL are dangerous; SSPL is blacklisted. That list will almost certainly fail in a real project, because it omits the layer that actually determines the obligation — the distribution model.
The same GPL component used internally for data analysis usually triggers no source-code obligation; offered as a SaaS to the public, it still usually does not; delivered to a customer as an on-premises deployment, the obligation arises immediately. The licence has not changed; what changed is how the code reaches the user.
The four-step order of analysis
Analysis does not begin with the licence name. It begins with the data flow.
Step one, is there distribution to third parties? Distribution means delivering a copy of the software to an external party, including on-premises deployment, SDKs, command-line tools, hardware pre-installation and image delivery. SaaS is not distribution under most licences because the user obtains no copy; AGPL and SSPL are the exceptions that bring network services within scope.
Step two, is there modification? For an unmodified component the obligation is usually limited to attribution and the full licence text; a modified component may trigger a statement of modification, provision of source code, or licensing of the entire derivative work. Modification is judged substantively, not by whether the name or package has been changed.
Step three, how is it linked? Dynamic linking, separate processes, API calls and plug-in loading produce different conclusions under different licences. LGPL permits combination with proprietary code through dynamic linking, provided the user can replace the library; GPL applies a stricter test, and a separate process is usually safer than static linking, though not absolutely so.
Step four, licence type and additional terms. The first three steps establish the facts; only now does the licence itself come into play. Watch for dual licensing, additional exceptions, and supplementary terms outside the licence, such as the Commons Clause, which adds a sales restriction on top of a permissive licence.
Only after all four steps does a conclusion hold. Starting at step four yields a label, not an analysis.
Four tiers of licences
| Tier | Examples | Core obligation | Commercial risk |
|---|---|---|---|
| Permissive | MIT, BSD-2/3-Clause, Apache 2.0 | Retain copyright notice and full licence text; Apache also requires NOTICE and a statement of modification | Low, subject to trade mark and patent terms |
| Weak copyleft | LGPL, MPL 2.0, EPL 2.0 | Modified files or components must be disclosed; LGPL requires replaceability | Medium, depending on modification and linking |
| Strong copyleft | GPL 2.0/3.0, AGPL 3.0 | The derivative work as a whole must be released under the same licence with source code; AGPL is triggered by network interaction | High; affects valuation where core code is involved |
| Non-standard | SSPL, BUSL, Commons Clause, non-commercial licences, no licence | Determined by their own terms, often containing service-use, commercialisation or time-conversion restrictions | High; each term must be read in the original |
This table is only a first filter. The real conclusion returns to step one: under strong copyleft, if there is no distribution the obligation may never arise; under a permissive licence, failure to retain the notice is still a breach.
Five core obligations
One, attribution and copyright notices. Retain the original author’s copyright notice, typically in an about page, documentation or a NOTICE file inside the binary package. Omission is the commonest form of breach and the easiest for automated checks to detect.
Two, the full licence text. Provide the complete licence with the distributed item. Placing the licence in the code repository is not the same as distributing it with the product; on-premises delivery requires a separate copy inside the delivery package.
Three, a statement of modification. Apache 2.0 and some weak copyleft licences require modified files to be identified. This is not a changelog: the point is which files were changed, not which features were altered.
Four, provision of source code. Triggered on distribution under strong copyleft. The method may be accompanying source, a written offer, or provision through a network address, depending on the licence version. AGPL covers network service scenarios and cannot be excluded on the ground that no installation package was delivered.
Five, patents and trade marks. Apache 2.0 expressly grants patent rights and contains a patent termination clause; most licences grant no trade mark rights. Using an open-source project’s name and logo in product marketing is a trade mark question outside the licence grant.
Three places specific to AI companies
Code scanning tools cover the dependency tree but not the following three, which are precisely where AI companies most often come unstuck.
Model weights. The licence for weights is independent of the training and inference code. Common types include custom community licences, Apache 2.0, OpenRAIL-style terms and licences with commercial-use thresholds. Check layer by layer: how the foundation model is licensed, whether the fine-tuned output inherits restrictions, whether the distilled output constitutes a derivative. Checking only the LICENSE file in the code repository usually produces an incomplete conclusion.
Training datasets. Dataset licences and code licences are two separate systems. Common forms are Creative Commons variants, custom research licences and research-only terms. A commercial model requires confirmation of commercial authorisation for the dataset and whether it contains third-party copyright content. A broken authorisation chain in the data source is often discovered only at financing due diligence or on overseas review.
Inference frameworks and runtime dependencies. Inference frameworks, CUDA operator libraries, quantisation tools and container base images each carry their own licence. System components in a base image may include GPL tools, usually used in separate processes without triggering copyleft — but the conclusion changes if the packaging method changes.
Four gates for day-to-day operation
Compliance is not a single audit but four interceptions.
First gate, procurement admission. Before introducing a new component, model or dataset, register the licence and source; nothing enters production unregistered. This gate determines the cost of everything downstream: without a record at source, later work can only reconstruct it by scanning.
Second gate, continuous integration scanning. Generate an SBOM in the build pipeline and compare against licence blacklists and grey lists. The value of scanning lies in transitive dependencies: direct dependencies are usually known to everyone, while a component five layers down is where the risk sits.
Third gate, release check. Reassess every change of delivery model: from SaaS to on-premises, from on-premises to SDK, from SDK to hardware pre-installation. Each change may turn a previously safe component into a source of obligation.
Fourth gate, external delivery. Check the NOTICE, full licence text, statement of modification and method of source provision inside the delivery package against a list. Due diligence materials for financing, mergers and overseas expansion are taken directly from the records left at this gate.
Five common misjudgements
One, SaaS is always safe. True for GPL in most cases, false for AGPL and SSPL. An API business using an AGPL component may trigger a source-code obligation as soon as users access it over a network.
Two, internal use is always safe. Internal use does not trigger distribution obligations, but the boundary of ‘internal’ moves. On-premises delivery, customer-site deployment and provision across group entities may all be treated as distribution.
Three, no licence means public domain. The opposite is true: no licence means all rights reserved by default. Many repositories on GitHub without a licence fall into this category and cannot be presumed usable merely because they are publicly visible.
Four, renaming or repackaging avoids disclosure. The derivative-work test turns on the relationship and combination of the code, not the name. Renaming, obfuscation and repackaging do not alter the licence obligation.
Five, Apache means anything is permitted. Apache 2.0 grants patent rights but not trade mark rights, and does not warrant freedom from patent risk. Project names, logos and third-party patent pool licences require separate treatment.
Relationship with due diligence
Day-to-day compliance and transaction due diligence are two different exercises drawing on the same records. The SBOM, licence matrix and distribution-model determinations kept in ordinary course form the working papers for diligence; what diligence adds is risk grading, alternatives and an audit opinion capable of being relied upon.
The requirements at the three moments of financing, merger and overseas expansion, and the five components of a proper deliverable, are set out in Open-Source Compliance Audit: What Investors Want at Due Diligence Is a Conclusion, Not a List. This article supplies the day-to-day method; together the two form a complete chain.
Industry consensus and policy developments in the open-source ecosystem are covered in the AI Open-Source Ecosystem Consensus Issued in Guangzhou and Shanghai’s Open-Source System Building Plan. For the wider framework of intellectual property strategy, see the intellectual property protection service page.
This article is based on publicly available licence texts and prevailing practice. It is for reference only and does not constitute legal advice. The obligations attaching to a particular component should be determined by its original terms, and matters involving core code or transaction arrangements should be assessed separately.
Frequently Asked Questions↑ Back to article
What is the difference between MIT and Apache 2.0?
Both are permissive licences and both permit commercial use. There are three differences: Apache 2.0 requires the NOTICE file to be retained, expressly grants patent rights and requires modifications to be stated; MIT requires only the copyright notice and the full licence text, and says nothing about patents or trade marks. Projects with patent pools or patent-defence needs usually choose Apache 2.0.
We only operate a SaaS. Do we have to open-source a GPL component?
Usually not. GPL's source-code obligation is triggered by distribution to third parties, and users accessing a service over a network generally do not receive a copy. AGPL article 13, however, brings network interaction within scope, and SSPL is broader still; those two require separate analysis.
What does AGPL's network interaction actually mean?
It means users interacting with the program remotely over a network. Wherever external users can use an AGPL-covered program through a service, the corresponding source code, including modified versions, must be offered to them. Internal deployment not open to external users usually does not trigger the obligation.
Are model weights subject to open-source licences as well?
Yes. The publisher of the weights attaches a separate licence, commonly a custom community licence, Apache 2.0 or OpenRAIL-style terms. Foundation models, fine-tuned outputs and distilled outputs may stack several layers of terms, so the authorisation documents must be checked layer by layer rather than by the code repository's LICENSE file alone.
Can code without a licence be used?
It cannot be assumed usable. The absence of a licence means all rights are reserved by default, so use, modification and distribution each require separate authorisation. Code of unknown provenance should be treated as high risk and replaced where possible; where replacement is not immediately possible, isolate it in a separate process and disclose it in external documents.
How much open-source compliance is enough?
At a minimum, leave three records: an SBOM including transitive dependencies, a component-by-component licence and obligation matrix, and a distribution-model determination at each release. The records must be capable of third-party review and updated whenever a new component is introduced or the delivery model changes, or they will be stale within six months.