I have nothing to add regarding GPL and such, but let me just provide a
voice on compiler flags for the masses who are operating on slightly less
up-to-date equipment.
gcc 4.1.2 is what we currently on run on our local computing systems.
However, we do have Intel V12, so we can survive if the minimal gcc version
were increased.
And the -nosse flag is vital to our clusters (I had been making custom
makefiles until this flag was added).
Cheers,
Brent
On Thu, Oct 16, 2014 at 2:35 AM, Scott Brozell <sbrozell.rci.rutgers.edu>
wrote:
> On Wed, Oct 15, 2014 at 11:18:52PM -0400, Jason Swails wrote:
> > > On Oct 15, 2014, at 10:26 PM, Scott Brozell <sbrozell.rci.rutgers.edu>
> wrote:
> > >> On Wed, Oct 15, 2014 at 03:51:41PM -0400, David A Case wrote:
> > >>> On Tue, Oct 14, 2014, Ross Walker wrote:
> > >>>
> > >>> Huh? - IANAL but seems to me that since we don't distribute any
> binaries
> > >>> and we require the user to build their own copy of AMBER that by
> doing so
> > >>> - that is manually running ./configure themselves and then typing
> make
> > >>> they are themselves manually linking to FFTW3 and we are not doing
> > >>> anything 'automatic' for them so this is probably not an issue.
> > >>>
> > >> I don't think you are a lawyer. And I don't think "automatic" vs.
> > >> "manual" is really important here. But I'd urge people to read
> paragraph
> > >> 4 of the GPLv3 license (in $AMBERHOME/AmberTools/LICENSE; this also
> > >> applies to fftw). All we are doing with fftw3 is distributing
> verbatim
> > >> source code, which is explicitly allowed. We never distribute
> non-source
> > >> code (covered by paragraph 6), so basically I think we are fine:
> remember
> > >> that the GPL rights are based on copyright. In this regard, GPLv3 is
> much
> > >> more explicit about what can and should not be done than is GPLv2.
> > >
> > > Wink, wink, nod, nod.
> > > ---
> > > tail $AMBERHOME/AmberTools/LICENSE
> > >
> > > The GNU General Public License does not permit incorporating your
> program
> > > into proprietary programs. If your program is a subroutine library,
> you
> > > may consider it more useful to permit linking proprietary applications
> with
> > > the library. If this is what you want to do, use the GNU Lesser
> General
> > > Public License instead of this License. But first, please read
> > > <http://www.gnu.org/philosophy/why-not-lgpl.html>.
> > > ---
> > >
> > > And note that we are put into this position of saying
> > > "ohh, we didn't know that users would actually (illegally)
> > > link the fftw3 (that we legally distributed) with our proprietary
> programs"
> > > by lawyers:
> > > http://fftw.org/faq/section1.html#nonfree
> >
> > There is nothing illegal about this. If users want to link free software
> they download with proprietary software they download that has a license
> permitting that use (like Amber does), that is perfectly acceptable. They
> are free to use free software however they like. The strictness in the GPL
> is just for relicensing and distributing... It's not at all restrictive for
> use.
> >
>
> Yes, i really obfuscated that by not stating outright that we WOULD be
> in that position IF we facilitated linking pmemd to fftw.
>
> > What I'm not certain about is when do we cross the line of "the user is
> choosing to link fftw themselves by changing Amber" versus "we support
> fftw-enabled pmemd as a build option".
> >
>
> If we follow the GPL intent (as in the above cut-n-paste and elsewhere)
> then the line is crystal clear:
> IF we offer a build mechanism that directly produces
> pmemd linked with fftw then we are in violation of the GPL intent
> (the end user must have to modify Amber, even if it were only the build
> process, in order to produce pmemd linked to fftw).
>
> If we do not follow the GPL intent then we enter the wink, nod world.
> Since we are people of good conscience in agreement with free software,
> we should continue to not produce pmemd linked to fftw.
> In this way we rise above the legal issues of whether the GPL can
> consider linking as a derivative process through copyright law.
>
> scott
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
--
_______________________________________________
Brent P. Krueger.....................phone: 616 395 7629
Professor................................fax: 616 395 7118
Hope College..........................Schaap Hall 2120
Department of Chemistry
Holland, MI 49423
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Oct 16 2014 - 05:00:02 PDT
