El Dom 16 Ago 2009 18:40:15 Bruce Allen escribió: > Hi Nicolás, > > >> Thanks for the note and for the link. Does this mean for example that > >> GPLd code is not allowed to link to the CUDA libraries (which are > >> non-GPL and not normally distributed with the OS)? > > > > The libraries don't have to be GPL. They can also be a *more liberal* > > license, such as LGPL or BSD. > > I was asking specifically about the CUDA libraries: > http://developer.download.nvidia.com/compute/cuda/2_2/toolkit/docs/cudaprof >_eula.pdf This license expressly does NOT include any source code and > forbids efforts such as reverse engineering to recontruct the source code. > So it is not 'more liberal' than GPL. > > My question is, can GPL code be linked against the CUDA library? I > assume from what you wrote previously, that the answer is 'no' but > wanted to confirm it.
The answer is no, *unless* the GPL program has an exception allowing linking to the CUDA library. And then, any GPL library used by that program needs a similar exception. > >> Does this mean that GPL programs can > >> not display on an NVIDIA graphics card (since they need to send data to > >> an NVIDIA device driver, not distributed as part of the OS?). > > > > A device driver isn't "linked" to the program that uses it; they interact > > via IPC. Otherwise, it wouldn't be legal for proprietary programs to run > > on Linux, since they are making syscalls to the Linux kernel, which is > > GPL. > > I'm confused about this point. > > On Linux, device drivers are executable code blocks that can be > dynamically loaded into the running kernel. This is essentially the > same mechanism by which a running program loads a library. The kernel > (GPL in the case of Linux) has to load a '.ko' object file. If this is > (for example) a proprietary device driver from NVIDIA, this would appear > to violate GPL as you have described it. The Linux kernel has an exception allowing proprietary modules, but with many restrictions. For example, they can only use a subset of kernel APIs, and they must call a function to declare they are proprietary, which sets a global "tainted" flag in the kernel. If your kernel crashes, the error will say whether it's tainted, and you're unlikely to get help if it was (since people will immediately blame the proprietary module for the crash). > [As far as I know, data is not passed by a program to a kernel device > driver via IPC (which usuallly involves sockets). Data is passed by a > program to a device driver on the stack. The device driver code is then > executed by the kernel in 'kernel mode' rather than in 'user mode'. Data > in the heap is usually explicitly copied from the process memory segment > (userland) to kmalloc()d space in the kernel context (kernel space). > But since I'm a physicist and not a computer scientist I could be wrong > about this.] Whether programs are "linked to the kernel", and whether a system call (talking to the kernel itself or to a loaded driver) is 'legally' equivalent to a function call between a program and a library, is in fact subject of some debate; so don't quote me on the subject :) _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
