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. The data comes from the license reports of the 28 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 the license report specification): it finds the package of each .drv file of the build of the toplevel from its name, and it adds system.extraDependencies. A unit that has a package of this repository only in a string adds the package to system.extraDependencies, for example the LLDAP provider of lldap-provision. 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). partLicenses in sbom.nix gives the licenses of a package to the parts of the package (FR-011 of spec.md). With these roots and these rules, the SBOMs of the 28 nodes have 24 component names without license data. [components] has 22 of them. The other two are github.com/tuvistavie/securerandom and simple-dark-gray-bootloader: their verdict is unknown, thus the reports of hosting-provider-postgresql and dev-fediversity-ci fail. The causes:

The meta.license of perl in nixpkgs gives only one of its licenses (artistic1, upstream Artistic-1.0 or GPL-1.0-or-later). Upstream (nixpkgs) can give [ artistic1 gpl1Plus ]. Artistic-1.0 is in [licenses].

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.

These dependencies are not in the SBOM (see "Known Deviations" in the license report specification):

• 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.

The source of the Go data

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.