CUDA toolkit redistributability (and other restrictively licensed software)

[msarahan]

The binaries (and only the binaries) of the CUDA toolkit can be redistributed: http://docs.nvidia.com/cuda/eula/#redistribution-rights

However, this requires addition of an additional agreed-to license:

(c) Licensee shall obtain each Customer's written or clickwrap agreement to the license terms under a written, legally enforceable agreement that has the effect of protecting the SOFTWARE and the rights of NVIDIA under terms no less restrictive than this Agreement.

I think we could handle this with a pre-link script. However, it is a pretty big damper to only have redistribution rights for the binaries. It means we have to install their tools on the docker image, or use their docker image somehow? We can't package the whole of the CUDA toolkit and just use it that way.

Generally: how do we want to handle these "clickwrap" agreements?

[jakirkham]

Kind of off topic, but do you know anything about what it would take to package cuDNN?

[msarahan]

cuDNN appears to be a 3-clause BSD license. The license is behind a registration wall. It should just be a matter of repackaging whatever installer they provide.

[msarahan]

Whoops, never mind. It is totally restricted, no redistribution. All copyrighted. Some parts are BSD, maybe. IANAL.

[jakirkham]

No worries.

Yeah, this is why it would be good if we could talk to NVIDA. There are a lot of devs that want to use this with Caffe, but not being able to package it is a huge pain when installing Caffe in different locations.

[lebedov]

Suggestion re the CUDA toolkit: why not have the hypothetical conda package download/unpack the tarball directly from NVIDIA's website at installation time to avoid redistribution issues? This approach was used to enable installation of Microsoft fonts via RPM years ago without violating redistribution restrictions.

[msarahan]

@lebedov This is a great idea. I'm not sure it's a complete solution, because their license agreement still requires some kind of "click-through" license agreement on the consumer end. For our build/test purposes, we may be able to either put that in with a command line argument, or just pipe yes to it. For people installing the package, I think we have to keep whatever installer dialogs they have as user-interactive dialogs.

[jakirkham]

Suggestion re the CUDA toolkit: why not have the hypothetical conda package download/unpack the tarball directly from NVIDIA's website at installation time to avoid redistribution issues?

Interesting suggestion. Actually, the same idea may be possible for cuDNN. We just have to delete libraries after using them. Also, I'm a little fuzzy if it is ok to be dynamically linked to cuDNN legally (even if no other bits from the libraries are present) and, if so, how well Caffe will work when built like this when cuDNN is not present.

It means we have to install their tools on the docker image, or use their docker image somehow?

I'm evaluating an option of the latter form as we will likely need this for Caffe. Also, am in discussions with an NVIDIA dev on getting cuDNN in a docker image so we can use that in a couple of cases. This will include CUDA libraries too and still be on CentOS 6.

For our build/test purposes, we may be able to either put that in with a command line argument, or just pipe yes to it. For people installing the package, I think we have to keep whatever installer dialogs they have as user-interactive dialogs.

This seems like a reasonable solution. Might be good if we can run it by NVIDIA to make sure they are ok with this.

[lebedov]

Facilitating installation of the entire CUDA toolkit would also be valuable for conda-based installation of packages such as pycuda and pyopencl that depend upon parts of the toolkit that presumably can't be redistributed, e.g., the nvcc compiler binary.

[jakirkham]

This docker image ( nvidia/cuda:7.5-cudnn5-devel-centos6 ) has CUDA and cuDNN in it using a CentOS 6.

[jakirkham]

Here is a PR ( conda-forge/docker-images#21 ) that would add a new image with CUDA and cuDNN. This might be one way to go about this. Not sure that I'm sold on it yet, but it would be a way forward for both of these problems. I have cc'd both of you ( @msarahan and @lebedov ) on the PR. Please let me know your thoughts over there.

[jakirkham]

This is still an interesting question and not at all resolved. That said, the discussion here has stalled out and it overlaps with discussion that has already occurred in issue ( conda-forge/conda-forge.github.io#63 ), which is a bit more visible. In an attempt to consolidate discussion a bit, will close this out. Thanks everyone.