How to deal with license compliance?

[AndersonTorres]

Issue description

With the recent advent of Duckstation changing its license, some issues were raised about how Nixpkgs should deal with licensing compliance.

References

Duckstation licensing issue: #341915

[Atemu]

I see two low hanging fruits:

1. Install license files into the package output. This is a bare minimum for license compliance and trivial to do. If the package script doesn't already do this by default (many do), it should be done manually.
2. Use "branding" configureFlags where available. Many packages offer configure flags that set a branding string in the resulting program, signifying that it was packaged by us. This ought to be enough to comply with the license requirement because this branding implies that we modified it.

Beyond these, we should look into manually marking packages that do not offer such flags by i.e. inserting a © Nixpkgs contributors into the license text which the program displays to users. (The GPL requires interactive programs to do this. If it doesn't, I think we can assume the author doesn't care about following the GPL extremely strictly.)
This is quite a bit more work, so I think the best course of action is to only do this when prompted to (i.e. upstream requests us to do it) or if it is conceivable that it might upset upstream if we don't. Most upstreams are pretty chill about this sort of thing but some aren't and it's those cases I think we should focus on. Duckstation is a good example.

[AndersonTorres]

In case of 1, I still prefer a separate output for this, at least by the typical rationale we provide for splitting outputs in the Nixpkgs manual.

Further, I have some conceptual concerns. Maybe it is too much perfectionism from my side, but oh well.

First, license metadata should be provided for all inputs of an expression - sources, patches, our own machinery etc.
Second, we should have something like a mathematical function that receives all the input above and output the appropriate course of action - things like "GPL requires interactive programs to display some info; create a compliance wrapper that accepts a --print-meta flag".

Third:
According to the manual, meta and passthru can't rebuild the expression.
However, some programs require further action according to their licensing info.

[emilazy]

I’m unconvinced that a separate output is sufficient for compliance, or that making every package multi‐output would be well‐received. In fact I suspect that we may be obligated to include the licence and copyright notice in all outputs.

We also cannot just copy template licence files, because the copyright notice differs between packages and must also be retained.

IIRC the interactive program thing doesn’t matter unless we apply patches, thankfully, and GPLv3 loosens the requirement further.

I think that the lowest‐hanging fruit to pick here would be to add code to stdenv that tries to automatically find and copy LICENSE and COPYING files. That won’t get us into full compliance by any means, but it will be a good start. We should also investigate the various automated SPDX/SBOM tools that could help with this kind of thing.

[JohnRTitor]

unless we apply patches

Patches from what exactly? Made by us/third party contributors or cherry-picked from upstream?

[emilazy]

  2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

[…]

    c) If the modified program normally reads commands interactively
    when run, you must cause it, when started running for such
    interactive use in the most ordinary way, to print or display an
    announcement including an appropriate copyright notice and a
    notice that there is no warranty (or else, saying that you provide
    a warranty) and that users may redistribute the program under
    these conditions, and telling the user how to view a copy of this
    License.  (Exception: if the Program itself is interactive but
    does not normally print such an announcement, your work based on
    the Program is not required to print an announcement.)

I was wrong; even the GPLv2 has the exception that means we don’t really have to care about it.

[emilazy]

BTW, I think that encoding full SPDX expressions in meta.license is probably a prerequisite to doing anything at all fancy here beyond my stdenv suggestion.

[AndersonTorres]

Disclaimer: IANAL yet.

In fact I suspect that we may be obligated to include the licence and copyright notice in all outputs.

Among the reason we split outputs, is saving some bytes and finer garbage-collection.
The location of the files in the filesystem does not look relevant, in the worst case we can just symlink them and/or force the installation of prog.licenses output.

add code to stdenv that tries to automatically find and copy LICENSE and COPYING files

Well, we can add a installLicense {licenseFiles} function to installShellFiles.

On the other hand I am not a fan of hidden automation.

[Pandapip1]

How about, as a minimum, we set the machine-readable copyright information licenses information to $outputDoc/copyright, and have a common-licenses packages that can be symlinked to?

[AndersonTorres]

to $outputDoc/copyright, and have a common-licenses packages that can be symlinked to?

A specific $outputLicense/copyright is better, since it can be injected without modifying currently installed packages.

[emilazy]

I do not think a separate output is okay, since derivative works must include at least a pointer to the licence text and in many cases must include the licence text verbatim, and the whole point of outputs is that they are distributed separately and can be downloaded in isolation. The best option is probably for multiple‐output packages to grow a license output that is symlinked into every other output. Hopefully we could share licence text between packages, but distinct copyright notices will have to be preserved. There are probably SPDX standards that we could profitably use for this.

[Pandapip1]

There are probably SPDX standards that we could profitably use for this.

That would be REUSE.

[emilazy]

REUSE is for annotating source code upstream for licence and copyright information. REUSE‐annotated code would be a lot easier for us to automate compliance with, but is a rarity in the wild; we can’t rely on it in general, though it may make sense to build our tooling around it as an ideal case and then figure out how to extend it to the common case. The REUSE tool can automate producing an SPDX‐format SBOM document, which may be closer to the kind of thing we’d want to install with packages. There is also CycloneDX; frankly, I have no idea how they compare, and asking Google for comparisons results in a bunch of incomprehensible LLM sludge.

[Pandapip1]

Proposition: we start by adding a REUSE compliance hook, and then ask package maintainers to upstream REUSE annotations if they feel they might otherwise be in legal trouble because of it.

[emilazy]

Full REUSE compliance is difficult to do retroactively and most projects won’t accept it as it adds a significant amount of annotation to every file in the repository. That’s not going to be an adequate approach to meeting our legal obligations under FOSS licences. It’s the entire NixOS project that’s exposed, not just individual package maintainers.

[Pandapip1]

I've made #353697, which is a naive setup hook that copies maintainer-specified license files into the default output. A review of it would be appreciated.

I'll continue looking into making a fully automated reuse-license-compliance-hook.

[fgaz]

[REUSE] adds a significant amount of annotation to every file in the repository

Not necessarily: https://reuse.software/faq/#bulk-license

[emilazy]

Yeah, although they make it clear in the FAQ and the specification that they’d really rather you use file headers.