[gmx-developers] Mixed license post 5.0

[Szilárd Páll]

On Fri, Feb 7, 2014 at 10:16 AM, Roland Schulz <roland at utk.edu> wrote:
> On Thu, Feb 6, 2014 at 5:45 PM, Erik Lindahl <erik.lindahl at scilifelab.se>
> wrote:
>>
>> if you want to rely on OpenBabel, there is no legal possibility whatsoever
>> to distribute a binary using both OpenBabel (GLPv2 only) in combination with
>> GSL (GPLv3 or later).
>
> As the GPL FAQ admits
> (http://www.gnu.org/licenses/gpl-faq.html#MereAggregation) this is an open
> question which might easily dependent on the jurisdiction. It might be that
> shared linking is fine and isn't considered a derived work. But of course
> not sure whether it is legal is for practical purposes not more useful than
> known to be illegal ;-). What seems clear is that if OpenBabel isn't used as
> a library but instead as external commands which are called and communicated
> to by using e.g. pipes than it is no problem.
>
> But, why would it be important to be able to distribute those binaries if we
> have no plans to distributing binaries (especially with optional features
> enabled)?
>
>> On 06 Feb 2014, at 23:38, Erik Lindahl <erik.lindahl at scilifelab.se> wrote:
>>
>> However, personally I will vote against accepting patches into the main
>> Gromacs codebase that rely on large external libraries that are are not
>> compatlble with LGPLv2 since that will just cause further fractioning and
>> large parts of the source code that are not tested by default. Such things
>> are better distributed as separate programs, IMHO.
>
> Not sure why testing would be affected by the license. We currently also
> test with FFTW.

To extend that thought: we do have quite a few non-permissive licensed
dependencies, that can't be included, hence all concerns expressed
should apply to those too (like BLAS/LAPACK, MKL - FFT, VMD).

I see little drawback in adding a dependency if this is implemented in
a technically sound manner (without being exhaustive in the
description of requirements): implementation through a
well-encapsulated module (perhaps in contrib), optional (preferably
off by default), the main code-base stays as independent as possible,
tests included, etc.

I don't see much of a barrier for testing such additions either. If
one is worried about the testing workload getting too high, Jenkins is
capable of handling a distributed infrastructure, so certain tests can
be offloaded to external resources contributed by e.g. the maintainers
of the respective feature. Although I'd like to note that we still
have *lots* of room for non-verification testing (i.e. nigtly/weekly
which we have almost none), during the last quite
development-intensive month, even with one of our hypervisors down,
the average utilization of all cores was only 16%.

Don't you think that imposing a ban on contributions that are not
self-contained would create even more fragmentation of the community
with lots of GROMACS forks and side-project that may never even be
considered for upstream contribution?

Cheers,
--
Szilárd

> Roland
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
> send a mail to gmx-developers-request at gromacs.org.