Hi Eric,
Do I understand correctly that the only GPL code used by the s...@home
app is FFTW?
Cheers,
Bruce
On 8/15/09 1:48 AM, Eric J Korpela wrote:
> 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]
> <mailto:[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 <http://fftw.org> ) or Steven ( stevenj at fftw.org
> <http://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] <mailto:[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] <mailto:[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.
