On Sat, Mar 18, 2017 at 2:49 PM, David Case <david.case.rutgers.edu> wrote:
> On Fri, Mar 17, 2017, Jason Swails wrote:
>
> > So the issue here is that by licensing libsander as LGPL, we violate the
> > terms of PBSA's GPL license.
>
> I'd like to ask Jason to help us out of this mess, if he is willing. In
> the
> statement just above, one could replace "PBSA" with "fftw", and illustrate
> a
> similar problem. (In fact, fftw is really at the root of most of our
> problems, since we can modify the PBSA license.)
>
> High-level view: we could change the licenses of anything we have written.
> But we also need to be able to create create a GPL code that is allowed
> to link to fftw libraries, and at the same time have a sander API and
> libsander that non-GPL codes can link to. So it seems like "sander" and
> "libsander" have to have different licenses.
>
I had forgotten about fftw. Fortunately, PBSA can be built *without*
fftw. But as long as it includes fftw, the whole thing would need to abide
by the GPL.
> Questions:
>
> 1. Is there a technical reason why libpbsa and libfftw3 need to be
> included
> into the Makefile target for libsander? (Stated another way: how hard
> would it be to eliminate these?) I think the sander API does not
> expose
> either pbsa or rism functionality, yet the symbols for pbsa and fftw
> are
> included in libsander, and I'm wondering if that can be changed.
>
The technical reason was ease of implementation. What might be easiest is
to make it so PBSA's periodic functionality is turned off both when -nofftw
is set *and* when that file is being built for the sander API. In that
case, we can omit fftw from sander and release the whole thing as L-GPL
(assuming we license PBSA under both the L-GPL [sans fftw] and the GPL [for
versions that include fftw]). I'm not sure how straightforward this is.
PBSA could also probably be eliminated from libsander altogether, although
that would probably require some amount of code changes to ifdef-out the
hooks into sander.
The last idea is that MKL is API-compatible with fftw, so we could also
permit MKL users to abide by the L-GPL (does PBSA link to MKL's FFT if MKL
is specified?)
> 2. Can we separate things in order to be able to make a license
> distinction: libsander (and its corresponding source code) could be
> LGPL,
> whereas the sander (as a whole) would be GPL? Alternative: go back
> to the old days, where we had separate sander.RISM (would be GPL) and
> and sander (would be LGPL) builds.
>
Yes, we can do that.
> We don't necessarily need to get this done for the AmberTools17 release,
> but
> should be trying in good faith to make any required changes. Weaning
> ourselves from fftw might be a long-term goal, but would be far from easy.
>
It *would* be nice to boot FFTW from sander from a licensing perspective.
Ray -- are the periodic options even available from sander? If not, that
makes things easy -- just remove that part from sander altogether and fftw
never enters the picture (assuming we can also get rid of from the sander
API).
Thanks,
Jason
--
Jason M. Swails
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Mar 18 2017 - 13:30:03 PDT
