I think Nicolas is right. There isn't a dynamic linking loophole. Libraries have to be under a GPL compatible license except for libraries that normally are distributed with the compiler or operating system.
Another way of looking at is is that you need to include everything that someone needs in order to be able to build the executable you ship including headers and libraries. This shows up in a lot of dual licensed applications where you use an "--enable-gpl" option to configure to enable GPL compatibile libraries to be linked in or a "--disable-gpl" option to link in proprietary licensed libraries and disable linking in any GPL libraries. It's part of the price we pay for FFTW. Without an exception from FFTW you'd need to have a version that only links to the AMD and Intel libraries and doesn't include FFTW. Eric On Fri, Aug 14, 2009 at 2:39 AM, Bruce Allen <[email protected]> wrote: > 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. > > Cheers, > Bruce > > > On 8/14/09 3:53 AM, Eric J Korpela wrote: > >> Hi Bruce, >> >> We do timing tests of several routines in s...@home before choosing >> the one to use. Our timing code is in our subversion repository >> (http://setisvn.ssl.berkeley.edu/) in the seti_boinc/client/vector >> directory if you want to use it. >> >> There may be one hitch, though. You may need to get a non-GPL licence >> for FFTW in order to allow you to also link in IMKL and ACML in the >> same distributed binary. You might want to Matteo ( athena at >> fftw.org ) or Steven ( stevenj at fftw.org ) to see if they have a >> problem with also linking in non-GPL-compatible non-operating-system >> libraries. They might be able to give you a non-GPL license (they >> gave s...@home one before we were open source) or they might allow it >> as long as the rest of your app is GPL compliant. They are sticklers >> on distributing a copy of the GPL and a source offer with the >> binaries, and got on my case at one point about that before we started >> putting the COPYING and COPYRIGHT files in the application. >> >> Because of this linking difficulty we had to put a license exception >> in the s...@home copyright to allow linking non-GPL FFT libraries. A >> GPL without exceptions wouldn't allow the use of proprietary FFT >> libraries. It's annoying but was necessary if we wanted to use FFTW >> while allowing others to use the Intel or AMD libraries... >> >> // In addition, as a special exception, the Regents of the University of >> // California give permission to link the code of this program with >> libraries >> // that provide specific optimized fast Fourier transform (FFT) functions >> // as an alternative to FFTW and distribute a linked executable and >> // source code. You must obey the GNU General Public License in all >> // respects for all of the code used other than the FFT library itself. >> // Any modification required to support these libraries must be >> distributed >> // under the terms of this license. If you modify this program, you may >> extend >> // this exception to your version of the program, but you are not >> obligated to >> // do so. If you do not wish to do so, delete this exception statement >> from >> // your version. Please be aware that FFTW is not covered by this >> exception, >> // therefore you may not use FFTW in any derivative work so modified >> without >> // permission of the authors of FFTW. >> >> Sorry to be the bearer of complexity. >> >> Eric >> >> On Mon, Aug 3, 2009 at 3:39 AM, Bruce Allen<[email protected]> >> wrote: >> >>> Dear BOINC devs, >>> >>> For some of the einst...@home code which is FFT-bound, we are going to >>> try the following strategy: >>> >>> (1) Link our application to FFTW, Intel Math Kernel Library (IMKL) and >>> to the AMD Core Math Library (ACML). >>> >>> (2) At app start up, do some timing tests to measure the speed of each >>> different library. We have a fixed data size. >>> >>> (3) Dynamically use the library which is tested as the fastest on the >>> host machine. >>> >>> I have two questions: >>> >>> (A) Has someone else already tried this approach? >>> >>> (B) Is anyone currently redistributing the ACML or IMKL with their >>> application? If so, did you sign a licensing agreement like this: >>> >>> >>> http://developer.amd.com/cpu/Libraries/acml/redistribution/Pages/default.aspx >>> >>> Cheers, >>> Bruce >>> >>> >>> >>> _______________________________________________ >>> 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.
