Hi Mo, On 08-05-2023 00:55, M. Zhou wrote:
On Sun, 2023-05-07 at 22:03 +0200, Paul Gevers wrote:On 27-04-2023 21:31, M. Zhou wrote:4. debconf template default choice is changed to "I Agree". This package is in non-free section. Only by setting the debconf default choice to "I Agree", can we correctly build pytorch-cuda in sbuild without the cuDNN libraries not downloaded but the bin:nvidia-cudnn package installed.Are we legally allowed to do this? If so, why even ask the question?According to the upstream license and the package content, the URL points to a distributable tarball depending on the user's agreement. The debconf questions shows the full license texts and asks the user whether to accept the terms. These terms, was deemed problematic by ftp-masters if we directly upload the binary blobs into the archive.
I may not have phrased my question correctly. What I mean is that if a user installs the package in a non-interactive way, do you believe they agreed with the license? If not, is it OK to install the package even if the user didn't agree with it? If the answer is, the user must accept the license, then I believe that the default can't be to accept it. If it's acceptable to install without the user seeing the license and accepting it, then why even ask the question?
At least, building the reverse dependency pytorch-cuda via sbuild, where the binary blobs will be pulled and linked against, is legal according to the license. Uploading the binary form of pytorch-cuda is ok as well.
That's nice already.
Other binary distributions like ArchLinux, Anaconda, and even PyTorch upstream have been redistributing the cuDNN binaries for years though.
I have no idea if and how they would ask for license agreements.
Although I hate dealing with annoying non-free license texts, I think it not safe to remove the debconf question prompt, because the license seems to pose even more restrictions than its dependency CUDA devkit.
I conclude from this part that it's NOT ok to skip the debconf question which is what happens if the user runs the install with non-interactive debconf.
PS wasn't an autopkgtest feasible such that this didn't need to be on our radar? (too late for that now, but still)It looks like I have to refresh my memory, I thought autopkgtest won't be run for non-free packages.
Right. It was recently pointed out to me that the ci.d.n infrastructure failed to support that (always, or since last year), but the migration software of the Release Team always has supported it. That was a bug, not by design. It's fixed now.
Writing the test scripts are easy, but I think that's not needed if I can get a manual removal or refusal.
Indeed, because we're too close to the full freeze to help you; you'll need an unblock anyways.
Paul
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature