Re: [AMBER-Developers] PBSA license

From: Jason Swails <>
Date: Sat, 18 Mar 2017 16:25:10 -0400

On Sat, Mar 18, 2017 at 2:49 PM, David Case <> 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
> 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


Jason M. Swails
AMBER-Developers mailing list
Received on Sat Mar 18 2017 - 13:30:03 PDT
Custom Search