Add explicit license information

[SomeoneSerge]

Currently (2023-03-14) the json manifests simply say "license": "CUDA Toolkit". On the first read, I thought that it "obviously" refers to the CUDA Toolkit's EULA whose existence precedes NVIDIA's redist packages. This leaves the following questions still open:

1. How does a user or distribution maintainer resolve the "license": "CUDA Toolkit" stanza into an actual license text?

2. The redistributable packages include extra paths like e.g. pkg-config/cudart-11.7.pc that are not explicitly white-listed by the EULA text

3. The nvidia_driver redistributable package contains nvidia_driver-linux-x86_64-530.30.02-archive/lib32/libcuda.so.530.30.02 which, under the EULA text, may only be redistributed when derived from an NGC docker container image and distributed as a part of a docker image

4. The EULA's text only explicitly allows redistribution of...

   variations of these files that have version number or architecture specific information embedded in the file name -

   ...but not, for instance, in the ELF header, as would be required for some Linux distributions.

5. More of a rhetorical question: license-wise, what is the difference between the cudatoolkit's .run file and the "redistributable" packages?

A resolution might involve all or a subset of the following:

1. Permissions and restrictions are distributed in machine-readable form together with the json manifests
2. License text is distributed together with the packages: cf. e.g. cuda_cudart/LICENSE.txt
3. The license string is replaced with a dictionary { name :: String, url :: String } where url refer to a downloadable file with the license text and name be a stabilized name, from which permissions and restrictions could be inferred
4. Redistribution of the redistributable components of CUDA Toolkit is explicitly permitted by the linked license text
5. Usage of patchelf prior to redistribution is explicitly permitted by the linked license texts
6. Redistribution of the user-space cuda driver (libcuda.so) from nvidia_driver be explicitly permitted. For instance,
   1. jq .nvidia_driver.license redistrib_12.1.0.json links to a license that allows to ship the contents of nvidia_driver-linux-x86_64-530.30.02-archive.tar.xz with an application.
   2. The clarifications about docker images are dropped
7. Licenses explicitly allow to patch paths in pkg-config files

Thanks!

[kmittman]

1. The license key-value is meant as a "short name" indicator for package maintainers.
   a. There is a LICENSE.txt in top-level of each component directory, as well as the included LICENSE text file within each tarball or zip archive.
   b. For manifest schema v3, I've added a new license_path key that explicitly points to $component/LICENSE.txt

2. The pkg-config .pc files are metadata, much in the same way the JSON manifests are. IMHO, much like the .deb/.rpm package templates we provide on Github, these are outside the scope of the payload's licensing.

3. The nvidia_driver bin-archive tarball contains the extracted contents of NVIDIA-Linux-*.run
   a. Also contains extracted contents of matching nvidia-installer, nvidia-modprobe, nvidia-persistenced, nvidia-settings, nvidia-xconfig, and open-gpu-kernel-modules tarballs.
   b. The NVIDIA driver license has some interesting changes in >= 535.43.02
   c. Thinking about this some more, it's very likely the row mentioned in the table is referring to the cuda_compat component, which is only provided as .deb and .rpm packages. These are pre-installed in the official container images for Forward Compatibility; not supported on GeForce SKUs.

4. Need some clarification about what this question implies?

5. Consider the following scenarios for repackaging components for Conda, Debian, Nix, PKGBUILD, RPM, etc. formats
   a. CUDA runfile

   • i. Download the entire .run
   • ii. Run the installer or extract the contents (--tar mxvf)
   • iii. Roll new tarballs
   • iv. Run package build commands

   b. Debian or RPM packages

   • i. For each component, download multiple runtime and devel .deb/.rpm packages
   • ii. Extract the contents
   • iii. Roll new tarballs
   • iv. Run package build commands

   c. "redist" bin-archive deliverables

   • i. For each component, download one* tarball (* some are provided in split archives)
   • ii. Run package build commands