License Decisions

This file gives a recommendation for each license that the matrix does not give, the decision of a maintainer when there is one, and the causes of NOASSERTION. A license that [licenses] of core/setups/nixos/license-allowlist.toml does not have makes the report fail, except NOASSERTION. The data comes from the license reports of the 30 nodes of core.

This is not legal advice. The authors are not lawyers. A person with legal knowledge must approve a decision before it goes into [licenses].

Relations between components

The compatibility of two licenses is a question only when the two works become one work. The EUPL-1.2 leaves this to the law: "This Licence does not define the extent of modification or dependence on the Original Work required in order to classify a work as a Derivative Work" (Article 1). There are three relations:

• Aggregation: separate programs on one system, for example nginx and the api. Each program keeps its own license. A node is mostly an aggregation. For aggregation, a license only has to permit the distribution of the component. The licenses of two components do not have to be compatible with each other.
• Dynamic linking: a program loads a shared library when it runs, for example a C program and libssl.so, or a Python program and a module that it imports. The European Commission says that this does not make a derivative work: "static and dynamic linking can be implemented with other programs without barriers or conditions. On this specific point, EUPL works like the LGPL" (EUPL FAQ), with recitals 10 and 15 of Directive 2009/24/EC as the reason. The FSF has a different opinion for the GPL. There is no case law.
• Static linking and incorporation: the code of the library is copied into the program, for example a Go or Rust binary with its modules and crates, or a JavaScript bundle. This is the relation that most likely makes a derivative work.

nixpkgs links C and C++ programs dynamically: each program finds its libraries in the store through its RPATH. No node uses pkgsStatic, and no node has a Haskell program. Static linking occurs in these cases:

• Go programs include their modules (for example openbao, forgejo, incus, spire, authelia, restic, rclone, grafana). cgo links glibc dynamically.
• Rust programs include their crates (for example garage, lldap, windmill, uv).
• JavaScript applications include bundles of npm packages (for example mastodon, peertube, grafana, forgejo, garage-webui, and asyncapi-docs of this repository).

The SBOM gives each of these programs as one component. It also gives the npm packages from the package.json files in the node_modules directories of the closure, and the crates from the Cargo.toml files in the vendor directories (cargoDeps) of the Rust packages of the roots in sbom.nix. It does not give the Go modules or the npm packages in a bundle. See "The dependencies that Go, Rust and npm builds vendor". Except for asyncapi-docs, these programs do not include code of this repository: their upstream projects combined the code, and the node only aggregates the programs.

The EUPL compatibility matrix

The matrix of the European Commission ("Matrix of EUPL compatible open source licences", July 2011, updated 2013 and 2017) has the columns "Incorporation", "Static link" and "Dynamic link". It is about inbound compatibility: "it allows you to merge a work covered by another F/OSS license into a larger work that you may distribute under the EUPL". The "Dynamic link" column is "OK" for each license of the matrix. "NO" and "?" occur only in the other columns, for example for the GPL ("NO (exceptions exist)" for incorporation). The reason that the matrix gives: "linking two programs does not produce a single derivative of both (each program stay covered by its primary licence)".

The Appendix of the EUPL-1.2 is a different list: it gives the licenses under which a licensee can distribute a work that combines an EUPL work with a work under that license (Article 5). It is an outbound list, not a list of the licenses that a dependency can have, thus the allowlist does not use it as a source. For a license that is not in the matrix, the allowlist uses the EUPL FAQ of the European Commission: "the simple fact of "Using" a covered component as a dependency or as a tool, does not transform your work in a derivative". Such a license is acceptable when it permits the distribution of the component.

Thus no license in the report fails because of dynamic linking. For aggregation and dynamic linking, a license is acceptable when it permits the distribution of the component, also for a commercial service.

Recommendations

"Nodes" is the number of nodes (of 30) with the license. "Accept" means: add the license to [licenses]. "Accepted" means: a maintainer accepted the license, and it is in [licenses] with its source. "Refuse" means: remove the component from the nodes. "Refused" means: a maintainer refused the license, it is in no list, and no node has a component with it. The report fails when a node has such a component.

Permissive licenses

These licenses permit distribution with notice and attribution conditions. They are acceptable for aggregation and for dynamic linking.

Weak copyleft licenses

These licenses have conditions only for changes to the component itself. The node does not change these components.

Licenses with a choice

Documentation and content licenses

Licenses of vendored components

These licenses come from the npm packages, the crates and the Go modules that the SBOM gives as vendored components (FR-010). A license that is "accepted" is in [licenses], with its source. For a module that is in [components], the licenses that only the module has are in no list. The Go rows come from a scan of 19 Go packages of the pinned nixpkgs that the configuration uses (see below), not from the reports of the nodes.

Licenses that need a person

Components without license data

A component has NOASSERTION when bombon did not find its derivation. bombon finds the derivations only through derivation values (drvAttrs), and a NixOS system gets most packages through strings. sbom.nix gives bombon more roots (see FR-002 of spec.md). The scripts that the configuration generates, for example forgejo-runner-daemon-* and gitea-register-runner-*, get the license of this repository (FR-009 of spec.md). With these roots and this rule, the reports of the 30 nodes have 281 component names without license data and outside [components] (324 pairs of name and version). The causes that remain:

The dependencies that Go, Rust and npm builds vendor

The report must check the modules, crates and npm packages that the Go, Rust and JavaScript programs include. These programs do not include code of this repository, thus they are an aggregation. But the node distributes them, thus their notice conditions apply. sbom-vendored.py adds them to the SBOM (FR-010), each one with its parent packages:

• npm: the package.json files in the node_modules directories of the closure, with their declared license. These files are in the closure, thus the build of the SBOM does not get larger.
• Rust: the Cargo.toml files in the vendor directories (cargoDeps) of the Rust packages of the roots, with their declared license. The vendor directory has all the crates of Cargo.lock, also the crates for other platforms, thus the SBOM can give more crates than the build links.
• Go: sbom-go-modules.py reads the modules that each program links from its build information (.go.buildinfo, the list of go version -m), and the license files from the root directory of each module in the module directory (goModules) of the package. In a vendor directory, a module that a replace directive changes to another module is in the directory of the path that the go.mod requires, thus the script gets that directory from modules.txt. A Go module declares no license, thus identify_license (licenseclassifier) finds the licenses in the text, and the SBOM gives them as concluded. The scan runs in one derivation for each Go package of the roots, thus the SBOM of a node gets only a small JSON file.

The source of the Go data

The cost of the Go scan

The scan of 19 Go packages of the pinned nixpkgs (the Go packages that core/ uses) took 18 s together, with the module directories in the store. The scan of otelcol-contrib, the largest, takes 2 s and 250 MB of memory. A node needs the module directory of a Go package only to build the JSON file of that package. When a binary cache has that file, the node does not download the module directory. Else, it downloads it from the binary cache of nixpkgs:

A module without a license is in the source of the package (for example the submodules github.com/grafana/grafana/apps/*, with the license in the root of the repository), or has no license file in its root directory.

These dependencies are not in the SBOM (see "Known Deviations" in spec.md):

• The crates of a Rust package and the Go modules of a Go package that is not a root, for example librsvg. A walk through all of the drvAttrs of the roots finds them, but also the packages that only the build of the toplevel uses. With their vendor directories, the build of the SBOM of a node needs 1 GB to 4 GB more.
• The Go modules of a Go package without a module directory (vendorHash = null), for example grafana-loki and tempo, and the Go standard library.
• The npm packages in the bundles of a front end, for example public/packs of Mastodon. A bundle has no package.json files.

Questions

• Does a gemspec list of licenses (spec.licenses) mean AND or OR? The documentation of RubyGems does not say. Most gems with a list give a choice, for example diff-lcs and the gems with Ruby and BSD-2-Clause.
• Does a hosted service "distribute" in the sense of the licenses? The EUPL-1.2 says yes ("providing access to its essential functionalities"), and so does the AGPL. Most other licenses apply only to copies. The recommendations above take the strict position: each component is distributed.