Internal tool
Development tooling, dashboards, operations scripts, business applications used only by employees.
What actually happens
| Question | Answer |
|---|---|
| Does a third party receive the software in executable form? | No |
| Does a third party interact with it over a network? | No — employees are not third parties |
| Is the product a consumer good? | No |
No copyleft mechanism triggers. This is the freest scenario.
The verdict per family
| Family | Verdict | Reason |
|---|---|---|
| Permissive | ● | Attribution not owed absent distribution, though crediting remains good practice |
| Weak copyleft (MPL, EPL, LGPL) | ● | No distribution, no reciprocity |
| Strong copyleft (GPL) | ● | The GPL triggers only on distribution |
| Network copyleft (AGPL) | ◐ | See below |
| Source-available (BSL, SSPL, ELv2) | ◐ | Read the restrictions: some target use itself, not only resale |
The AGPL case
Section 13 covers “all users interacting with it remotely through a computer network”. Nothing excludes employees. A strict reading therefore requires, for a modified AGPL internal tool, offering the source to internal users.
In practice this is painless: publishing the source on the internal repository is enough. But the obligation exists, and it is better known than discovered.
Source-available licences
Unlike copyleft, they sometimes restrict use itself, with no distribution involved:
- a BSL-1.1 typically prohibits production use beyond the additional use grant the vendor offers;
- an Elastic License 2.0 prohibits providing the product as a managed service, which can cover an internal platform shared between subsidiaries;
- Commons Clause removes the right to sell, not the right to use.
They must therefore be read, even in the most permissive of scenarios.
The only real risk: the boundary moves
That is the whole risk of this scenario, and it is real.
| Event | Effect |
|---|---|
| The internal tool becomes a product | Every mechanism wakes up at once |
| The tool is deployed at a customer or partner | Distribution |
| The tool goes to a subsidiary, a separate legal entity | Distribution — a subsidiary is a third party |
| An external contractor receives the binary | Distribution |
| The container image is published to a public registry | Distribution |
| The tool is opened to external users, even free of charge | The AGPL triggers |
The subsidiary point often surprises: intra-group distribution between two separate legal entities is distribution under free software licences. Consolidated accounting has no bearing here.
The recommendation. Apply the licence policy to internal tools anyway, at least in warning mode. Not because the obligation exists today, but so that promotion to a product does not run, two years later, into a component that cannot be removed.
What the CRA adds
An internal tool is not a product with digital elements: it is not placed on the market. It falls outside the Regulation — see Scope.
That does not mean it escapes every requirement: build chain tooling contributes to the security of the products you do place on the market, and falls under supply chain control on that basis.