Open source does not mean free of obligations
96% of commercial software contains open source components. For startups and software companies, this is not a problem in itself — it is a reality of modern development. The problem arises when the licences of those components are not managed, which can generate legal risks ranging from code publication obligations to copyright infringement litigation.
Types of licences and their commercial implications
Open source licences fall into two broad families, with radically different implications:
Permissive licences (MIT, BSD, Apache 2.0). Allow using, modifying, and distributing software with few restrictions. They generally only require maintaining attribution and a copy of the licence. They are compatible with proprietary and commercial business models.
- MIT — The simplest. Permits almost any use as long as you include the copyright notice.
- Apache 2.0 — Similar to MIT but includes an explicit patent licence grant from contributors and a termination clause if you initiate patent litigation.
- BSD — 2-clause and 3-clause variants. The 3-clause version prohibits using the project name for promotion without permission.
Copyleft licences (GPL, LGPL, AGPL, MPL). Require that derivative works be distributed under the same or a compatible licence. This can force you to publish your proprietary code under certain circumstances.
- GPL v3 — Any software that links with GPL code must also be distributed under GPL. This means if you incorporate a GPL library into your product, your entire product might need to be open source.
- AGPL v3 — Extends GPL obligations to network use. If you offer a SaaS service using AGPL code, you must provide the source code to users of the service. This is especially relevant for SaaS companies.
- LGPL — More permissive than GPL for dynamic linking. You can link with LGPL libraries from proprietary code without it being “contaminated,” provided you use dynamic linking.
- MPL 2.0 — File-level copyleft. Only modified files must be distributed under MPL, not the entire project.
Concrete risks for startups
1. Inadvertent copyleft contamination. A developer incorporates a GPL dependency without review. The entire product could become subject to GPL, requiring publication of the source code.
2. Licence incompatibility. Combining components with incompatible licences (for example, GPL v2 and Apache 2.0 in certain configurations) can create situations where distributing the software is technically illegal.
3. Attribution non-compliance. Even permissive licences require attribution. Not including mandatory copyright notices is a technical infringement that can be exploited in litigation or due diligence.
4. Investment due diligence risk. VC funds and M&A buyers review the open source licence inventory. Compliance issues can reduce valuation, delay transactions, or even block the deal.
How to implement an open source compliance programme
Step 1: Dependency inventory. Use tools like FOSSA, Snyk, or Black Duck to scan your codebase and generate a complete inventory of open source components and their licences.
Step 2: Risk classification. Categorise each component by licence type and how it integrates into your product (static vs dynamic linking, distribution vs internal use, SaaS vs on-premise).
Step 3: Licence policy. Define which licences are acceptable for your business model. A typical SaaS policy might be:
- Approved: MIT, BSD, Apache 2.0, ISC
- Review required: LGPL, MPL, CDDL
- Prohibited: GPL, AGPL (except isolated use without linking)
Step 4: Approval process. Integrate licence review into your development pipeline. Each new dependency should be evaluated before being incorporated into the project.
Step 5: Documentation and attribution. Maintain an updated NOTICE or THIRD_PARTY_LICENSES file with all components and their licences. This is mandatory for many licences and valued in due diligence.
The special case of AGPL and SaaS
AGPL deserves special attention for SaaS companies. Unlike GPL, which is triggered by software distribution, AGPL is triggered when software is offered as a network service. If your SaaS incorporates AGPL code (even through an indirect dependency), you could be required to offer the complete source code of your application to any user.
Companies like Google internally prohibit the use of AGPL code. For SaaS startups, we recommend treating AGPL as a high-risk licence requiring legal review before use.
Open source and the AI Act
The AI Act includes limited exceptions for open source AI models. Models released under open source licences are exempt from certain AI Act transparency obligations, provided they are not classified as systemic risk. However, this exemption does not eliminate the obligations of the open source licence itself.
If you distribute an AI model under an open source licence, you must comply with both the licence conditions and the applicable AI Act obligations.
At A2 we help software companies design open source compliance policies that protect their intellectual property without limiting their capacity for innovation. Consult with our team.