Nine distribution scenarios

Each page follows the same pattern: what actually happens (is there distribution? network interaction? linking?), the verdict per family, the pitfalls specific to the scenario, and what the CRA adds.

The three questions that classify a scenario

Before looking for your case in the list, answer these three. They predict most of the outcome.

Question	If yes	If no
Does a third party receive the software in executable form?	Copyleft is triggered	The GPL has no effect
Does a third party interact with it over a network?	Network copyleft is triggered	The AGPL has no effect
Can the user replace the component with a modified version?	The LGPL is satisfied	The LGPL requires you to make it possible

These mechanisms are detailed in What triggers an obligation.

The nine scenarios

Worst case comes first because it is not a product: it is the default posture, the one to apply while you do not yet know where the component will end up — and the one that should govern a shared internal library reused everywhere.

The other eight are ordered from least to most constrained:

Rank	Scenario	What characterises it
1	Internal tool	No distribution — almost everything is permitted
2	SaaS backend	No distribution, but network exposure
3	Library / SDK	You are upstream: your licence constrains your users
4	Desktop / CLI app	Classic binary distribution
5	On-premises	Full distribution, operating system included
6	Web frontend	Source code distribution, almost always overlooked
7	Mobile app	Distribution plus restrictive store terms
8	Embedded / IoT	Distribution plus hardware lock-down

One product often spans several scenarios

This is the most frequent application error. A single product combines:

• a SaaS backend, which distributes nothing;
• a web frontend, which distributes code to every visitor;
• a mobile app, subject to store terms;
• an agent installed at the customer’s site, which is a binary distribution;
• a container image published to a registry, which is also a distribution;
• possibly an on-premises edition.

Each part must be assessed in its own scenario, with its own list of permitted licences. A component acceptable in the backend may be prohibited in the agent, and the licence policy must reflect that — see Intellectual property, which breaks your lists down by context of use.

The most-constrained-part rule. If the same repository builds both the backend and the agent shipped to customers, the agent’s regime applies to the whole repository. Splitting repositories is sometimes the only way to keep freedom of choice over backend components.