// wiki · guide · September 2026
Open source in a company product
Draft article. The licence descriptions are simplified working reference points; the text of the specific licence and its applicability are always primary.
A draft for discussion. The article answers “what to check before releasing a product”, but does not replace an audit of a specific build: the composition of dependencies matters more than the choice of the main licence.
The short answer
Permissive licences generally allow code to be included in a closed-source product subject to the particular licence’s terms. Under Apache 2.0 these include retaining the licence and required notices, identifying changes and complying with NOTICE requirements. GPL and AGPL obligations depend on the product’s components, modifications and how the program is provided; a component inventory helps identify what needs review.
The licence map
| Licence | Into a proprietary product | Duty to open code | Remember |
|---|---|---|---|
| MIT, BSD | Yes | No | Keep a copy of the licence and the authors' notice |
| Apache-2.0 | Yes | No | Authors' patent licence; NOTICE file; a list of changes |
| MPL-2.0 | Yes, with isolation | Only modified files under MPL | File-level copyleft: module boundaries must be kept clean |
| LGPL-2.1 / 3 | Yes, with dynamic linking | Changes to the library itself | Static linking and edits to the library weaken the position |
| GPL-2 / 3 | Practically no | All derivative code upon distribution | “Derivative work” is the key and contested term |
| AGPL-3.0 | Depends on the components and how they are combined | Section 13: users’ network interaction with a modified program | Review the scope of corresponding source code |
A separate category is “source-available” (SSPL, BSL and vendors' own licences): the code is visible, but it is not open source — the commercial-use terms must be read in full.
AGPL: a trap for SaaS
If a modified AGPL program interacts with users over a network, Section 13 requires offering those users the corresponding source code of the modified version. The scope of the obligations depends on the components and how they are combined. An AGPL component calls for review of the licence and product architecture, rather than an automatic conclusion that the entire service must be open-sourced.
Typical mistakes
- Copy-pasting fragments from Stack Overflow and blogs: code in answers is usually under CC BY-SA — with a share-alike condition that does not sit well with a proprietary product.
- Transitive dependencies: your MIT package pulls a GPL package — the licence map is assembled across the whole tree, not the direct dependencies.
- For API clients and SDKs, examine the component’s licence and its relationship to the product; accessing an AGPL service through an API does not itself determine the licensing regime for the whole product.
- “No licence” = “anything goes”. On the contrary: code without a licence file is protected by default — it cannot be used until the author explicitly permits it.
The component list
The working discipline is to keep an inventory of third-party code (SBOM): component, version, licence, where it is used. It is generated automatically by composition scanners; lawyers only need to control the triggers: new GPL/AGPL in the tree, licence conflicts, components without a licence. For regulatorily sensitive products the list is also part of the evidence base — by analogy with the data provenance log from the article “Training a model on someone else's works”.
Open source in deals
In investment rounds and M&A the open source list is a standard due diligence request: the investor checks whether the product is “loaded” with copyleft that devalues the asset (details — “Due diligence of an AI asset”). If there is no list, it is assembled before the deal in emergency mode — more expensive and with findings. Cheaper is a three-line policy for the team: permissive — allowed; MPL/LGPL — through review; GPL/AGPL — only with approval.
A licence audit in a product and an open source policy are part of technology rights practice.
Sources for selected points
This selection concerns only the identified issues and does not constitute a full legal review of the article.