Re: GPL V2 and GPLv3
Michael Poole <mdpoole@troilus.org> wrote:
> Peter S Galbraith writes:
>
> >> > If it explicitely calls the interface...
> >>
> >> ... that does not resolve the question, even for bytecompiled files.
> >
> > So why do need the freer LGPL versus the GPL for libraries? I guess we
> > can do whatever we want so it doesn't matter.
>
> When there is only one implementation of a library, there is an
> argument -- not everyone agrees with this, but I will assume it is
> strong enough to be cautious -- that the inclusion by reference is
> enough to make the library's license apply.
>
> That is not the case for Emacs, especially for standalone packages
> that are not distributed as part of an upstream Emacs package: the
> same elisp file typically works with more than one version or branch
> of Emacs (XEmacs is still alive and is still GPLv2 or GPLv2-or-later).
So I'm fine using GPL-v2 code with GPL-v3 libraries as long as (1)
there's a GPL-v2 version of the libraries with the same interface, such
that (2) the GPL-v2 code does not need to be modified to run on the
GPL-v3 version of the libraries?
I could buy that. It won't be fun to watch out for cases where we need
to modify code to work on GPL-v3 libraries.
> >>>> In this case, there are older emacsen -- distributed under licenses
> >>>> other than the GPLv3 -- that provide the interfaces needed by most or
> >>>> all of the elisp in question.
> >>>
> >>> Sure, the code is fine with older Emacs. We simply shouldn't install it
> >>> and set it up for GPL v3 versions of Emacs.
> >>
> >>I suggest you take this question up with the FSF. If their position
> >>is that there is a license conflict between GPLv2-only elisp files and
> >>a GPLv3 (or later) installation of GNU Emacs, it is worth talking
> >>about -- in part because there would be wider-ranging implications.
> >
> > The FSF have stated that the two licenses are not compatible.
>
> That's a different question than what I asked.
Then I don't understand the question, sorry.
> > In the past, I had asked RMS if it was reasonable that elisp code could
> > be under any license if it simply used Emacs builtins, and would have to
> > be under the GPL if it pulled in GPL'ed libraries using a `load' or
> > `require'. He agreed that it made sense, because the libraries weren't
> > under the LGPL but under the GPL. Transpose that to the incompatible v2
> > or v3 and you get the same situation.
>
> You have not listed any GPLv2-only examples that pull in GPLv3-only
> libraries. Those would be libraries that do not exist, or which have
> versions that would break the GPLv2-only elisp code's function, in
> GPLv2-compatible versions of Emacs. If you know of any examples,
> please mention them.
It wasn't my question. We have GPL-v2 code that pulls-in libraries. If
I use that code under GPL-v3 Emacs then I have no easy choice of what
library to use. The one that comes with Emacs-v3 will be used. There
are no other libraries to use instead.
If you think that it's okay as long as the interface hasn't changed,
that's an opinion. It would be nice to have someone else confirm that.
> (This is one of the reasons that -legal posters so often say that the
> DFSG apply to software, not to licenses: there are an almost infinite
> number of hypothetical situations, and there is neither the need nor
> the time to evaluate most of them.)
>
> Otherwise, the only way I see any problem is if you think there is
> GPLv2-only elisp, valid to distribute with prior versions of GNU Emacs
> (and/or XEmacs), but that somehow became illegal to distribute when
> GNU Emacs was released under GPLv3.
That's not what I said. I said it would be against (the intent of) the
licenses to install them in such a way that they be used together
easily. This is more than mere aggregation.
> > Hopes this helps to clarify where I come from.
>
> The meaning of the law is very relevant -- GPLv2 makes explicit
> reference to legal terms of art (such as "derivative work"). I do not
> see any reason that GPLv2-licensed elisp has an inherent license
> conflict with a GPLv3-licensed Emacs. Rather, section 0 of GPLv2
> seems clear to me that this would be a permitted use of the code.
> Even when the elisp is distributed in byte-compiled form (which is not
> the case for standalone Debian packages), section 3's "mere
> aggregation" language seems to apply.
>
> It is polite and advisable to follow the author's wishes to the extent
> that doing so is practical, but right now I see no reason to think
> that any elisp author wishes his GPLv2-only elisp to not be used with
> a GPLv3-licensed Emacs.
I thought you sait that "The meaning of the law is very relevant". I
see no reason to guess at the intent of any elisp author with his
GPLv2-only code. I have already asked such an author to relicense and
he's not sure he like the GPL v3 and might not want to. I have no right
to make any assumptions concerning the author's intent.
See also:
-----
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 program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library.
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
If a programming language interpreter is released under the GPL, does
that mean programs written to be interpreted by it must be under
GPL-compatible licenses?
When the interpreter just interprets a language, the answer is
no. The interpreted program, to the interpreter, is just data; a
free software license like the GPL, based on copyright law, cannot
limit what data you use the interpreter on. You can run it on any
data (interpreted program), any way you like, and there are no
requirements about licensing that data to anyone.
However, when the interpreter is extended to provide "bindings" to
other facilities (often, but not necessarily, libraries), the
interpreted program is effectively linked to the facilities it uses
through these bindings. So if these facilities are released under
the GPL, the interpreted program that uses them must be released in
a GPL-compatible way. The JNI or Java Native Interface is an example
of such a binding mechanism; libraries that are accessed in this way
are linked dynamically with the Java programs that call them. These
libraries are also linked with the interpreter. If the interpreter
is linked statically with these libraries, or if it is designed to
link dynamically with these specific libraries, then it too needs to
be released in a GPL-compatible way.
Another similar and very common case is to provide libraries with
the interpreter which are themselves interpreted. For instance, Perl
comes with many Perl modules, and a Java implementation comes with
many Java classes. These libraries and the programs that call them
are always dynamically linked together.
A consequence is that if you choose to use GPL'd Perl modules or
Java classes in your program, you must release the program in a
GPL-compatible way, regardless of the license used in the Perl or
Java interpreter that the combined Perl or Java program will run on.
-----
Transpose the last paragraph to Emacs: if you choose to use GPL'd elisp
libraries in your elisp program, you must release the program in a
GPL-compatible way.
Peter
Reply to: