Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)
On Wed, Mar 20, 2019 at 09:17:32AM +0100, Giacomo Tesio wrote:
> The code distributed under a non-copyleft license depends heavily on
> copylefted one, so much that it's not possible to run (or even
> compile) it without the pre-existing copylefted one (that includes C
> headers that are not described by any standard).
That is really the crux of the question here. The code does contain
/references/ to libfrr functions and data structures. But it doesn't
contain any code that was copied/moved/directly derived from GPL
functionality. Is it still considered derivative?
We (FRR) believe it isn't. That's why we think we can still distribute
babeld and ldpd under their permissive licenses.
While this is, legally, an open question (no court has ruled on it to my
knowledge), there are at least several observations that support our
viewpoint:
- as Florian brought up in his mail dated 19.3. 18:55, there is actually
a commercial variant of Zebra, sold as "ZebOS" by IPInfusion. As
weird as it may sound, a lot of the library facilities (especially the
CLI) are still mostly compatible. babeld could likely be made to work
with ZebOS with only a small effort. Isn't that a clear indication of
it not being derivative?
- the ongoing Oracle vs. Google lawsuit is looking at whether APIs can
even be copyrighted to begin with. If they couldn't, this would end
the entire discussion right there, but unfortunately courts said the
API itself can be copyrighted. They're now discussing fair use on
that (and Google has re-requested the USSC to look at it.) That said,
the OvG case is about Google copying the API itself, not making use of
it.
- the LGPL also makes some statements about this, specifically:
"When a program is linked with a library, whether statically or
using a shared library, the combination of the two is legally
speaking a combined work, a derivative of the original library. The
ordinary General Public License therefore permits such linking only
if the entire combination fits its criteria of freedom. The Lesser
General Public License permits more lax criteria for linking other
code with the library."
(this is from LGPL v2.1, which is easier to read since LGPL v3.0
cross-references GPL v3.0 for a lot of its "meat")
To me, it clearly seems that the authors of the license were working
with the assumption that the source code, using headers from a library
and containing function names from it, wouldn't be derivative of the
library. It explicitly says that the /combined work/ is derivative.
This also makes sense from another perspective: the LGPL does require
the library itself to remain under the terms of the LGPL. This is
worded like this:
""The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or
translated straightforwardly into another language. (Hereinafter,
translation is included without limitation in the term
"modification".)""
So if an application using a library were a derived work of the
library - the LGPL wouldn't even make sense to exist. Its terms would
apply to the application... and if the application falls under the
LGPL, that makes the license pointless. The LGPL text really
implies/assumes that a library can be used without being derivative of
it.
[...]
> That's why I said they could (at most, but I guess Bradley can correct
> me) double license the modifications, say as GPL and BSD or MIT.
This doesn't really work. A dual license is an "or" construct, meaning
a consumer of the code can choose one of the licenses (and even drop the
other license completely.) If the code cannot be under the MIT license,
it cannot be under a dual GPL/MIT license either.
Cheers,
-David
Reply to: