Hello Marcin,
Thanks for the reply.
To recap. We have a module lammpslib.py that interfaces the atomic
simulation environment (ase) with the lammps program via the lammps.py
python interface provided with lammps. It has been suggested calling the
lammps program in this way violates the GPLv2 of lammps or the LGPLv2.1
of ase. If so we cannot include lammpslib.py with the ase source
distribution.
I have read the FAQ and tend to agree with you, it seems we cannot
include lammpslib.py with ase because of using lammps as a library in
ase violates the gpl of lammps. Unless the lammps people can think of a
way around this issue I guess it would be preferable to put lammpslib.py
in ase-extra. But even so it seems if someone even runs the code ever
they will be violating something.
Although the FAQ
http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility makes this
vague reference :
"All GNU GPL versions permit such combinations privately;"
Does anyone have any ideas ?
Paul
INFO from the GPL FAQ
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
If a library is released under the GPL (not the LGPL), does that mean
that any software which uses it has to be under the GPL or a
GPL-compatible license? (#IfLibraryIsGPL)
Yes, because the software as it is actually run includes the
library.
What does it mean to say a license is “compatible with the
GPL?” (#WhatDoesCompatMean)
It means that the other license and the GNU GPL are compatible;
you can combine code released under the other license with code released
under the GNU GPL in one larger program.
All GNU GPL versions permit such combinations privately; they
also permit distribution of such combinations provided the combination
is released under the same GNU GPL version. The other license is
compatible with the GPL if it permits this too.
GPLv3 is compatible with more licenses than GPLv2: it allows you
to make combinations with code that has specific kinds of additional
requirements that are not in GPLv3 itself. Section 7 has more
information about this, including the list of additional requirements
that are permitted.
If so we cannot include lammpslib.py with the ase source
distribution.
I don’t understand this message. I think of LGPL as less restrictive
than GPL. If Ase is LGPL, then there is no problem with it
calling a GPL library (LAMMPS). If you are asking about the
piece of middleware code (lammpslib.py), then so long as it
is GPL or LGPL, I also see no problem. All of this is only
relevant if you plan to distribute code (you can use it personally however
you wish).
Steve
Hello ASE and lammps people
Back when we discussed this the last time, my (unspoken?) thought was
that an ASE interface linking directly to the underlying code would be
maintained within that code. The logic behind this assumption is that
an interface so closely integrated with the code is easier to maintain
within that code than within the ASE; after all ASE is supposed to act
like a library and be somewhat stable (some day, I know, I know),
whereas a similar demand cannot in general be made to the code. The
weakness is of course that the lammps developers, who do not
necessarily have any idea what ASE is, may not be overly eager to
include some strange aseinterface.py or similar file within their
code. The IMHO second best option is, as has already been mentioned,
to distribute the interface as/within a separate module that depends
on both ASE and lammps.
Best regards
Ask
2013/6/12 White, Paul <[email protected]...>:
I just read your message again. This is the clause you are
questioning, I think:
If a library is released under the GPL (not the LGPL), does that mean
that any software which uses it has to be under the GPL or a
GPL-compatible license? (#IfLibraryIsGPL)
LAMMPS is the lib in this case.
The calling software (Ase) is in fact under a GPL-compatible
license, is it not? I.e. LGPL. Since LGPL is less restricive
than GPL, I think this is fine.
Steve
please look at ASE is “i want to release a project under” LGPLv2.1+. “import lammps” is “I want to use a library under” GPLv2 only. Best regards, Marcin
please look at http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
good grief - can’t image the GPL people could have made
their dependencies any more complex …
ASE is “i want to release a project under” LGPLv2.1+.
import lammps" is “I want to use a library under” GPLv2 only.
The resulting box says: OK: Convey project under GPLv2 only
So you’re thinking that using LAMMPS in Ase requires Ase
to become GPL instead of LGPL? That was counter-intuitive
to me. Now my understanding
(from a local expert) is that is only true for applications
(i.e things that run by themselves), not libraries. I assume Ase
itself is a library, since you use LGPL?
If it is a library,
I think Ase can be LGPL (or BSD or whatever) and
still use GPL libraries. It is up to a 3rd party
who creates and distributes an application that uses Ase + LAMMPS
to license their software
in a way that is compatible with all the libs it uses.
If (part of) Ase is itself an application (why use LGPL for that part?),
then technically I think that part would need to be GPL if it calls LAMMPS.
But practically, we (LAMMPS) don’t care what you do, so
long as your software (source) is openly available.
Also, we have been thinking about re-licensing LAMMPS as LGPL
to projects/companies who want to use it as a lib. So maybe
that is a long-term solution for you … it’s just some painful
bookkeeping for us to get permission from all our contributors.
You mentioned distributing an Ase-specific LAMMPS wrapper
in LAMMPS vs Ase. We are happy to include it in our distro,
if that helps with this problem. We would just refer people
to you if they have questions, and update it when you send
new versions. I.e. it’s just a black-box for us.
Steve
Hello
I just read your message again. This is the clause you are
questioning, I think:
If a library is released under the GPL (not the LGPL), does that mean
that any software which uses it has to be under the GPL or a
GPL-compatible license? (#IfLibraryIsGPL)
LAMMPS is the lib in this case.
The calling software (Ase) is in fact under a GPL-compatible
license, is it not? I.e. LGPL. Since LGPL is less restricive
than GPL, I think this is fine.
Steve
Not quite. GPL enforces certain freedoms that LGPL does not, and a
code which does not enforce those freedoms may not link to (~import
things from) GPL programmes unless the result is distributed
essentially under GPL. So it would make the combination ASE+lammps.py
possible, but under the terms of the GPL.
Best regards
Ask
Den 13-06-2013 02:14, Ask Hjorth Larsen skrev:
Hello
I just read your message again. This is the clause you are
questioning, I think:
If a library is released under the GPL (not the LGPL), does that mean
that any software which uses it has to be under the GPL or a
GPL-compatible license? (#IfLibraryIsGPL)
LAMMPS is the lib in this case.
The calling software (Ase) is in fact under a GPL-compatible
license, is it not? I.e. LGPL. Since LGPL is less restricive
than GPL, I think this is fine.
Steve
Not quite. GPL enforces certain freedoms that LGPL does not, and a
code which does not enforce those freedoms may not link to (~import
things from) GPL programmes unless the result is distributed
essentially under GPL. So it would make the combination ASE+lammps.py
possible, but under the terms of the GPL.
Is it true that this is not allowed:
import lammps
lammps.do_something()
but
subprocess.call('lammps < input')
is OK? Using the command-line interface to LAMMPS is OK, but not the Python interface?
Jens Jørgen
Hello
2013/6/13 Jens Jørgen Mortensen <[email protected]...>:
Den 13-06-2013 02:14, Ask Hjorth Larsen skrev:
Hello
I just read your message again. This is the clause you are
questioning, I think:
If a library is released under the GPL (not the LGPL), does that mean
that any software which uses it has to be under the GPL or a
GPL-compatible license? (#IfLibraryIsGPL)
LAMMPS is the lib in this case.
The calling software (Ase) is in fact under a GPL-compatible
license, is it not? I.e. LGPL. Since LGPL is less restricive
than GPL, I think this is fine.
Steve
Not quite. GPL enforces certain freedoms that LGPL does not, and a
code which does not enforce those freedoms may not link to (~import
things from) GPL programmes unless the result is distributed
essentially under GPL. So it would make the combination ASE+lammps.py
possible, but under the terms of the GPL.
Is it true that this is not allowed:
import lammps
lammps.do_something()
but
subprocess.call('lammps < input')
is OK? Using the command-line interface to LAMMPS is OK, but not the Python
interface?
Jens Jørgen
What the GPL talks about is a bit more elaborate; if my memory serves
it is not exactly "linking", but rather any complex interaction
between the programmes with sharing of data structures, API calls and
so on. There is a fuzzy limit in there somewhere to be sorted out by
the courts.
The easy way is to stay away from importing. Your example is probably
fine, but an ASE interface is sufficiently complex that it would
probably not be.
The solution, of course, is for something under GPL to link to both
ASE and lammps. That combination would be conveyed under GPL as
normal and could do what it wants to.
Regards
Ask
Hello
please look at http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
good grief - can't image the GPL people could have made
their dependencies any more complex ...
ASE is "i want to release a project under" LGPLv2.1+.
import lammps" is "I want to use a library under" GPLv2 only.
The resulting box says: OK: Convey project under GPLv2 only
So you're thinking that using LAMMPS in Ase requires Ase
to become GPL instead of LGPL? That was counter-intuitive
to me. Now my understanding
(from a local expert) is that is only true for applications
(i.e things that run by themselves), not libraries. I assume Ase
itself is a library, since you use LGPL?
If it is a library,
I think Ase can be LGPL (or BSD or whatever) and
still use GPL libraries. It is up to a 3rd party
who creates and distributes an application that uses Ase + LAMMPS
to license their software
in a way that is compatible with all the libs it uses.
An evil, proprietary programme full of NSA backdoors can link to an
LGPL programme if it wants to. Now, if the LGPL programme can link to
a GPL programme, then
2013/6/13 Ask Hjorth Larsen <[email protected]...>:
Hello
please look at http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
good grief - can't image the GPL people could have made
their dependencies any more complex ...
ASE is "i want to release a project under" LGPLv2.1+.
import lammps" is "I want to use a library under" GPLv2 only.
The resulting box says: OK: Convey project under GPLv2 only
So you're thinking that using LAMMPS in Ase requires Ase
to become GPL instead of LGPL? That was counter-intuitive
to me. Now my understanding
(from a local expert) is that is only true for applications
(i.e things that run by themselves), not libraries. I assume Ase
itself is a library, since you use LGPL?
If it is a library,
I think Ase can be LGPL (or BSD or whatever) and
still use GPL libraries. It is up to a 3rd party
who creates and distributes an application that uses Ase + LAMMPS
to license their software
in a way that is compatible with all the libs it uses.
An evil, proprietary programme full of NSA backdoors can link to an
LGPL programme if it wants to. Now, if the LGPL programme can link to
a GPL programme, then
Argh, I hit some shortcut which sent the message prematurely.
..., then any evil, proprietary programme could effectively link to
any GPL programme through a thin LGPL wrapper. Which would not be so
good. That's why LGPL cannot link to GPL.
According to the FSF, LGPL should be understood as the "lesser" GPL
and not the "library" GPL. Programmes and libraries could be licensed
under either (although GPL is generally regarded as the "good"
choice).
Regards
Ask
…, then any evil, proprietary programme could effectively link to
any GPL programme through a thin LGPL wrapper. Which would not be so
good. That’s why LGPL cannot link to GPL.
According to the FSF, LGPL should be understood as the “lesser” GPL
and not the “library” GPL. Programmes and libraries could be licensed
under either (although GPL is generally regarded as the “good”
choice).
According to my licensing expert, this is not quite correct.
An evil proprietary program can link to any LGPL and/or GPL libs
if it wants. It is only if the authors distribute that code
that they would be required to license their code correctly.
E.g. if they used ASE and LAMMPS, they would be required
to license under GPL. If they only used LGPL ASE, they
would have no restriction on how they licensed their
code. Hence the advantage of LGPL for a library.
Bottom line; the onus is on the calling program that
does the linking (to create an actual executable) to have
the correct license based on whatever libs it uses and
incorporates into their executable by virtue of doing the link.
Thus if ASE can be distributed as an LGPL library, even
if it makes calls to GPL LAMMPS. B/c ASE is not doing a link to create an executable
that includes LAMMPS (you don’t need LAMMPS to make an ASE lib,
no LAMMPS code is included in the lib build).
OTOH, if ASE is an application (evil or not :)), then
the argument above holds --> it needs to be GPL if it
uses LAMMPS. That is why in my earlier email
I asked if ASE is an app or a lib (or both). And why
my expert suggests that LGPL is a good choice for a library
but makes less sense for an application.
If we get to point of re-licensing LAMMPS as LGPL,
our plan is to make all of it LGPL except the small
src/main.cpp file which is added to make it an application.
Main.cpp will remain GPL.
Steve
Hello
.., then any evil, proprietary programme could effectively link to
any GPL programme through a thin LGPL wrapper. Which would not be so
good. That's why LGPL cannot link to GPL.
According to the FSF, LGPL should be understood as the "lesser" GPL
and not the "library" GPL. Programmes and libraries could be licensed
under either (although GPL is generally regarded as the "good"
choice).
According to my licensing expert, this is not quite correct.
An evil proprietary program can link to any LGPL and/or GPL libs
if it wants. It is only if the authors distribute that code
that they would be required to license their code correctly.
(Right)
E.g. if they used ASE and LAMMPS, they would be required
to license under GPL. If they only used LGPL ASE, they
would have no restriction on how they licensed their
code. Hence the advantage of LGPL for a library.
Then LGPL does not purely have an "advantage", only a difference. The
objective of choosing (L)GPL is that the potential evil people cannot
come along and fork the code, then make their own modifications and
release that under a proprietary license. GPL further disallows
linking, which LGPL does not. It should be considered a *feature* of
GPL for libraries that a proprietary programme cannot use the library
either. LGPL only exists because it was deemed a disadvantage for the
spread of free software that proprietary programmes could not even be
linked against the GNU C library, and so would be practically
impossible to combine with the GNU OS.
(I hope the use of somewhat loaded words helps to clarify the
motivation of the license)
Bottom line; the onus is on the calling program that
does the linking (to create an actual executable) to have
the correct license based on whatever libs it uses and
incorporates into their executable by virtue of doing the link.
Thus if ASE can be distributed as an LGPL library, even
if it makes calls to GPL LAMMPS. B/c ASE is not doing a link to create an
executable
that includes LAMMPS (you don't need LAMMPS to make an ASE lib,
no LAMMPS code is included in the lib build).
OTOH, if ASE is an application (evil or not :)), then
the argument above holds --> it needs to be GPL if it
uses LAMMPS. That is why in my earlier email
I asked if ASE is an app or a lib (or both). And why
my expert suggests that LGPL is a good choice for a library
but makes less sense for an application.
If we get to point of re-licensing LAMMPS as LGPL,
our plan is to make all of it LGPL except the small
src/main.cpp file which is added to make it an application.
Main.cpp will remain GPL.
Steve
You should only do this if you would like proprietary programmes to
use your eigensolvers, XC implementations and so on; i.e. if you
literally want to help proprietary programmes. Usually the unspoken
assumption is that if someone releases something under GPL, it is with
the purpose of helping open source programmes and not proprietary
ones. So from a pro-free-software view point, the LGPL is frequently
a much worse choice, even for a library.
Of course none of this answers the original question...
Best regards
Ask