Open source and SaaS: managing GPL/AGPL licence risks

In 2026, almost all SaaS products rely on open source. But not all licences are alike. “Reciprocal” (copyleft) licences — GPL, AGPL and, to a lesser extent, LGPL — may require derivative source code to be made available, including without conventional distribution for AGPL. If poorly managed, they expose you to infringement claims, withdrawal injunctions and damages.

“Restrictive” licences: what exactly do we mean?

Copyleft licences require, under certain conditions, that derivative works be licensed on the same terms and their source code be accessible. The distinction is:

• Strong copyleft: GPL v2/v3 (on distribution) and AGPL v3 (even without distribution, where access is over a network).
• Weak copyleft: LGPL, which permits linking to proprietary code under conditions (ability to relink/update the library, disclosure of library modifications, etc.).

For an educational overview, see INPI on software status and licensing and resources from OSOR (European Commission). Legally, software is copyright-protected (EU: Directive 2009/24/CE; France: CPI — exclusive software rights).

Why the SaaS model is particularly exposed (AGPL)

In SaaS, people often think “no distribution = no GPL obligation”. This is frequently true for conventional server-side GPL. But AGPL closes the “ASP loophole”: if users interact with your software over a network, you must offer access to the corresponding source code. This is central to any AGPL component used on the back end or for JavaScript running in the user's browser.

French and European authorities promote open source while reiterating compliance requirements: ANSSI has updated its open source policy and recommends governance supported by tools; CNIL — French data protection authority stresses transparency and control over components.

Practical legal risks in France and the EU

• Licence loss and infringement: failure to comply with licence terms can terminate the licence and leave you using software without rights. In France, infringement carries criminal penalties (art. L. 335‑2 CPI) and civil remedies (injunction to cease, damages, withdrawal).
• “Viral” effect: integrating a copyleft library into a proprietary module may require publication of derivative code. AGPL extends this logic to network access.
• “Product” compliance: the forthcoming European Cyber Resilience Act strengthens EU expectations for security, vulnerability management and component traceability (SBOM) (see EUR‑Lex — EU law portal).
• Reputation and costs: forced code publication, accelerated rewriting, suspended features and emergency negotiations with rights holders.

French case law has long recognised the enforceability of free software licences and copyright remedies for non-compliance. The framework is also strengthened by Directive (EU) 2019/790 (DSM), which modernises certain copyright mechanisms for the digital age.

Typical risk situations in SaaS

• AGPL microservice on the back end: if users interact with this service through your application, an obligation to offer the relevant service's complete source code may apply.
• Agent/SDK deployed at the customer: distributing a binary incorporating a GPL library triggers obligations to distribute corresponding source code (and potentially linked code).
• Modified LGPL library: you must publish library modifications and allow relinking. “Dynamic linking” alone does not always remove the risk if the architecture prevents effective relinking.
• Client-side AGPL JavaScript: code downloaded by the browser is distributed; AGPL may require the complete corresponding source code to be made available.
• Copy-paste/generative AI: a snippet introduced under GPL/AGPL contaminates the receiving module. Hence the need to audit AI-generated code too.

A “no surprises” compliance method (technical + legal)

1) Map and classify

• Exhaustive inventory of components (including transitive dependencies) and tool-generated SBOM. ANSSI — French national cybersecurity agency recommends controlled dependency and vulnerability management.
• Licence classification: permissive (MIT, BSD, Apache‑2.0) = low risk; weak copyleft (LGPL) = medium risk and technical conditions; strong copyleft (GPL/AGPL) = high SaaS risk.

2) Decide and remediate

• “Approved/prohibited licences” policy by product family. Prohibit AGPL in the SaaS back end, and GPL where agents are distributed.
• Alternatives and dual licensing: consider permissive libraries or buy a commercial licence when offered by the open source project.
• Architectural isolation: separate through processes, network APIs and open formats. Warning: AGPL triggers obligations even with network separation.

3) Equip the lifecycle with tools

• CI/CD with blocking licence scans and human review of borderline cases.
• Approval process for every new “at-risk” dependency and review of snippets/AI.
• Systematic notices and attribution (Apache‑2.0: NOTICE, etc.).

4) Contract and govern

• Subcontractor clauses (integrators, freelancers, third-party vendors): compliance with your open source policy, mandatory SBOM, no strong copyleft without written agreement, assistance with claims, indemnification. See our good practice for managing dependencies in technical subcontracting agreements.
• SaaS customer contracts: provide for a right to correct/suspend a feature following a third-party claim, a limited warranty for open source components, security update obligations and an appropriate limitation of liability. See essential SaaS contract clauses and why to avoid generic templates.
• Internal policy approved by legal and technical teams, team training and decision logging.

To legally define your use and distribution rights, revisit the foundations of software licence agreements (SaaS, open source and proprietary) and protect strategic assets: source code protection through copyright.

What if a GPL/AGPL library is already in your SaaS?

1. Freeze releases and form a technical/legal task force.
2. Assess use: server only? network interaction? distribution of agents/SDKs? modifications made?
3. Decide: (a) replace with a permissive alternative; (b) isolate the component to limit the derivative work; (c) comply (publish required code); (d) obtain a commercial licence.
4. Bring into compliance: provide corresponding source code, notices and relinking mechanisms (LGPL).
5. Document and adjust the open source policy to prevent recurrence.

Note that ANSSI — French national cybersecurity agency encourages a pragmatic approach supported by tools, and the software development security framework (ANSSI guide) aligns with good dependency and SBOM management practice. European software security requirements (see EUR‑Lex — EU law portal) point in the same direction.

30-day checklist for CTOs/general counsel

• Week 1: complete SBOM, including transitive dependencies and front-end code.
• Week 2: licence × usage-model compatibility matrix (pure SaaS, agent, on-premises, mobile/SDK).
• Week 3: priority remediation (server-side/JS AGPL, GPL in agents), alternatives selection, replacement plan.
• Week 4: contract updates (customers and subcontractors), OSS notices, CI pipeline with blocking scans, developer training + signed open source policy.

Legal points to keep in mind

• The author's exclusive software rights apply fully to free software licences: see the CPI — Intellectual Property Code and Directive 2009/24/CE.
• Non-compliance with a free software licence creates infringement exposure (L. 335‑2 CPI), with injunctions and damages.
• ANSSI and the European Commission (through OSOR — Open Source Observatory) promote responsible open source and documentary governance.
• CNIL — French data protection authority reiterates that software compliance contributes to security and trust, particularly in data/AI environments.

Quick FAQ

Can I use a server-side GPL library without publishing my code?

Often yes if you distribute nothing and it is not AGPL. But watch agents, SDKs, plug-ins, distributed images and front-end code: these cases trigger obligations.

Does AGPL require me to publish everything?

It requires offering the source code of the program accessed by the user over the network. The exact scope depends on architecture and component interactions.

Is LGPL “safe” for SaaS?

Less risky than GPL/AGPL, but with specific obligations: publish library modifications, allow relinking and independent updates.

What should I do after a formal demand?

Freeze deliveries, audit, assess use, correct (or replace), negotiate a commercial licence if needed and implement a compliance policy.

Do permissive licences (MIT/Apache) impose constraints?

Yes, attribution and sometimes specific obligations (Apache‑2.0 NOTICE). However, they are much more compatible with a proprietary SaaS model.

Need a quick dependency and contract audit? Contact us: we adapt your SaaS terms of sale/contracts and open source clauses to your architecture and risks.