On Fri, Nov 4, 2011 at 8:07 PM, Scott Brozell <sbrozell.rci.rutgers.edu> wrote:
> Hi,
>
> On Thu, Nov 03, 2011 at 08:33:57PM -0700, Ross Walker wrote:
>> 1) We unify everything into a single src tree with a single configure
>> script, single master makefile and single set of test cases.
>>
>> 2) We create a makerelease script that will either build a tar file of
>> 'AMBER' or a tar file of 'AMBERTools' - the key being that AMBER includes
>> AMBERTools explicitly.
>
> Yes on 1.
> Yes on 2; but i recommend that both are called Amber.
>
> To reiterate I recommend again that we eliminate AMBERTools.
> If x paid for the non-free parts of Amber then x gets everything.
> If x did not pay for the non-free parts of Amber then x gets only the free stuff.
> I still don't understand Dave's license issue.
> Compared to the current dev/build/test mess that we have, i expect that
> managing licenses will be trivial.
This might violate the gpl's "mere aggregate" clause.
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
If AMBERTools was a series of programs that communicated with the
non-free parts of amber through system calls and sockets and such (but
not through a shared memory address space), then inclusion of
AMBERTools would be OK.
If parts of AMBERTools were compiled with amber proper to create an
amber executable in which both parts of code shared the same address
space, then both AMBERTools and amber-proper are bound by the terms of
the gpl.
If AMBERTools was distributed separately, then this is a non-issue
because amber wouldn't then be distributing ambertools.
If AMBERTools was distributed under the LGPL, then this might also be
a non-issue.
Someone mentioned a possible licensing issue earlier - perhaps they
were referring to this.
-Tim
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Nov 05 2011 - 06:00:04 PDT
