On-premises and self-hosted
The software is installed and runs on the customer’s infrastructure: a virtual appliance, a machine image, an installation package, a set of containers, a turnkey cluster.
What actually happens
| Question | Answer |
|---|---|
| Does a third party receive the software in executable form? | Yes, in full |
| Does a third party interact with it over a network? | Yes, but the customer becomes the operator |
| Is the product a consumer good? | No — a professional customer |
| What exactly does the customer receive? | Often a whole system, operating system included |
Along with embedded, this is the scenario with by far the largest volume of distributed components.
The verdict per family
| Family | Verdict | Reason |
|---|---|---|
| Permissive | ● | Attribution owed for everything shipped |
| Weak copyleft, file (MPL, EPL) | ● | Publish modified files |
| Weak copyleft, library (LGPL) | ◐ | Workable with dynamic linking; in containers, usually the case |
| Strong copyleft (GPL) | ◐ | Full obligation, including towards the customer, who may then redistribute |
| Network copyleft (AGPL) | ○ | You distribute: sections 4 and 5 apply. Section 13 will apply to the customer, which they should be told |
| Source-available | ✕ | Almost all prohibit redistribution |
The point that changes everything: the customer gains rights
On receiving a GPL binary, the customer becomes a holder of the licence’s rights. They may:
- demand the corresponding source, including your modifications;
- redistribute it to anyone, under the same licence;
- modify the component and deploy their version.
This is not theoretical: it is how a violation becomes public. An unhappy — or merely curious — customer asks for the source. If they do not get it they hold considerable leverage, and if they themselves contribute to the upstream project, an interest in acting on it.
The commercial consequence. With strong copyleft shipped on-premises, there is no possible composition secrecy. If the combined code carries competitive value, the component must be isolated in a separate process, or replaced.
The appliance: the volume trap
Shipping a machine image or a full container image means distributing the whole system: kernel, C library, utilities, interpreters, package manager. Thousands of components, overwhelmingly GPL and LGPL.
| What you think you ship | What you actually ship |
|---|---|
| Your application | Your application plus an entire distribution |
| A dozen dependencies | Several thousand packages |
Good news: this is largely mere aggregation — your application is not a derivative work of the kernel. Bad news: every aggregated package keeps its obligations, including attribution and, for GPL components, supply of the corresponding source.
The standard remedy: start from a minimal base image, and rely on the source archives the distribution vendor already publishes, referencing them explicitly — provided you verify that they cover the exact version shipped.
Pitfalls in this scenario
The written offer that outlives the contract. Under GPL-2.0 the offer to supply the source must remain valid for three years after the last distribution — regardless of the commercial contract ending, the product reaching end of life, or the team leaving.
Patches shipped one at a time. Every patch sent to the customer is a new distribution, with its own obligations and its own corresponding source.
The customer-specific build. A bespoke development delivered to a single customer is still a distribution. Having only one recipient changes nothing.
The customer who redistributes. Nothing stops them for components under copyleft. Your contractual terms can prohibit it for your code, not for third-party code under a free licence.
The AGPL double hat. You distribute, so you owe the source. The customer operates a network service, so section 13 will apply to them if they modify it. That deserves to be written into the documentation, or you create a non-compliance on their side that they never saw coming.
What the CRA adds
The heaviest scenario in regulatory terms too. The product is placed on the market with all the obligations that follow, and two difficulties of its own:
- the SBOM must cover everything shipped, base image included. An application SBOM that ignores the thousands of packages in the underlying system is incomplete — see Quality and completeness;
- the support period covers the whole: fixing a vulnerability in the C library shipped inside your appliance falls to you, for five to ten years.
That is the technical reason minimal images are not merely a security good practice: they directly shrink the scope of your obligations, on both fronts at once.