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 20/03/2019, David Lamparter <equinox@diac24.net> wrote:
> 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?
Can you remove the reference to libfrr without breaking the build?
If you couldn't have written the new code if libfrr did not existed in
the first place, that code is a derivative of libfrr.
Just like if I write a couple of new chapter for, say, "Harry Potter
and the Half-Blood Prince" it's a derivative work of it unless no
place, character or mechanics of it is present into my new chapter.
> We (FRR) believe it isn't. That's why we think we can still distribute
> babeld and ldpd under their permissive licenses.
And I think you are wrong for the reason mentioned above.
Obviously only a court might really state if you are right or not.
And IMHO, Paul could go down this path to get the termination of your
license recognised.
But frankly, I'd really prefer to see this matter settled friendly.
I think that having several collaborative forks of a code base that
experiment different paths is healthy for Free Software and should be
always encouraged.
So I hope FRR won't lose their ability to modify and distribute their own fork.
OTOH, Paul's complaints are well founded.
The GPL is reciprocal and requires derivative works to be licensed in
the same way.
Not doing so is a violation of it, and should either be fixed (as soon
as possible) or sanctioned, in the interest of the whole Free Software
community.
> 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:
>
> [...lot interesting stuff whose analysis would take us too offtopic...]
>
> 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.
Yes, it say so.
But this doesn't EXCLUDE that something that is written after and
heavily depends on the library whose header are original copyrightable
work is derivative work too.
And I'd argue that it doesn't explicitly say so, because it's obvious,
while the combined work being derivative despite the parts combined
being INDEPENDENT different works might not be that obvious.
> 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.
No.
LGPL say: your application IS a derivative or this library, but this
license let you modify and distribute such application under any
license, AS LONG AS you distribute any modification to this library
under LGPL.
Its purpose is to restrict the reach of the copyleft to the library
only, exactly because, by default, it would apply to the depending on
the library too.
>> 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.
Again, maybe a lawyer might correct me on this.
But I think that the GPL says that you have to distribute any derived
work as GPL.
It doesn't say that you have to distribute the derived work as GPL only.
Violating the GPL terms would terminate the license itself, but in
theory, if the copyright owner gave you a different license too and
you have a compatible codebase that is legally sound (unlikely, as it
should NOT use ANY GPL covered code your code depends upon, not even
the headers, but maybe possible if it provides completely different
interfaces), nothing prevent you to use such different license to
adapt and merge the derivative work to it.
It goes without saying you would lose any grant on the code covered by GPL.
But, to my knowledge, the resulting work would still be legally distributable.
Giacomo
Reply to: