Add licenses to moby and c-util

[0xf09f95b4]

The docker and dbus-broker packages create internal dependency derivations that do not contain licenses or other meta information. This is not openly exposed when using something like https://search.nixos.org but does come up when building SBOMs or investigating dependencies in another way.

This PR adds meta info to those dependencies.

I kept the other meta information (maintainer, ...) from the main package derivation of the corresponding file.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[phanirithvij]

with lib; is usually discouraged

[0xf09f95b4]

with lib; is usually discouraged

I just copied the meta attrsets from the main package. Should I change this for the main packages as well?

[emilazy]

It would be better to define the meta in a shared location and use it for both to avoid drift and duplication.

Note that you can’t really presently rely on every derivation involved in a build having the correct SBOM info because e.g. our fetchers produce derivations that we don’t separately tag with licenses. That should arguably change, but you should be aware of that pervasive fact.

[0xf09f95b4]

I didn't try to create a complete meta copy because the involved packages do have their own descriptions etc. -- but I'll take another stab at de-duplication.

Note that you can’t really presently rely on every derivation involved in a build having the correct SBOM info because e.g. our fetchers produce derivations that we don’t separately tag with licenses. That should arguably change, but you should be aware of that pervasive fact.

Thanks for the insight!

[0xf09f95b4]

@emilazy Is this what you had in mind?

Thanks for your help!

[emilazy]

Yeah, this looks good. Thanks!