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)? What about NVIDIA
drivers (which are proprietary)? 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?).
Cheers,
Bruce
On 8/14/09 6:10 PM, Nicolás Alvarez wrote:
> El Vie 14 Ago 2009 13:00:41 Nicolás Alvarez escribió:
>> El Vie 14 Ago 2009 06:39:08 Bruce Allen escribió:
>>> Hi Eric,
>>>
>>> Thanks -- this is very helpful. Before going forward, I have a
>>> question. It sounds as if s...@home is distributing an executable that
>>> statically links the FFT libs. Is that correct? My understanding of the
>>> licensing issues is that if the linking to FFT libs is done dynamically
>>> at run-time on the hosts, rather than statically, then there are no
>>> GPL/non-GPL compatibility issues. In other words, a dynamic executable
>>> of pure-GPL code is allowed to dynamically link at run-time to a
>>> proprietary non-GPL library.
>> No, I don't think so. For the GPL, static vs dynamic linking is irrelevant.
>> You should have the right to modify, under GPL-compatible terms, all of the
>> code that ends up running within the same process, except libraries that
>> come with the operating system such as libc (or msvcrt).
>
> See:
> http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs
> _______________________________________________
> boinc_dev mailing list
> [email protected]
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
