Custom Search
-- Ray Luo, Ph.D. Professor of Structural Biology/Biochemistry/Biophysics, Chemical Physics, Biomedical Engineering, and Chemical Engineering Department of Molecular Biology and Biochemistry University of California, Irvine, CA 92697-3900 On Sat, Mar 18, 2017 at 1:25 PM, Jason Swails <jason.swails.gmail.com> wrote: > 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 _______________________________________________ AMBER-Developers mailing list AMBER-Developers.ambermd.org http://lists.ambermd.org/mailman/listinfo/amber-developersReceived on Sat Mar 18 2017 - 15:30:02 PDT