// 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
Using open code in a commercial product is almost always possible — the question is the terms. Permissive licences (MIT, BSD, Apache) only ask to keep the attribution notice. Copyleft licences (GPL, AGPL) require opening the source of derivative code — and in a proprietary product that is a price business is usually not ready to pay. The risk is managed not by banning open source but by a component list and two rules for developers.
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 | No | Even without distribution — upon network access | See below: the main risk for SaaS |
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
GPL obliges opening the code upon distribution of the program — a cloud service hands no binaries to anyone, which is why SaaS long circumvented GPL. AGPL closed that loophole: if users work with the program over a network, the operator must provide them the source of the derivative version. One AGPL package that gets into a service's server code theoretically drags along the duty to open that code. The rule for the team: AGPL in the runtime is always an escalation to review — no “but it's tiny”.
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.
- SDKs and clients: a wrapper over an AGPL service or an SDK with copyleft terms infects the product just like the code itself.
- “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.