[systemd-devel] Systemd license vs. libcryptsetup license

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jun 08, 2017 at 06:03:37PM +0200, Julian Andres Klode wrote:
> On Thu, Jun 08, 2017 at 01:47:56PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Jun 08, 2017 at 09:40:17AM +0200, Krzysztof Jackiewicz wrote:
> > > > No, that makes no sense. It'd mean that putting two zip files that one provides
> > > > and the other uses a function with the same name next to one another would
> > > > make them somehow connected and derivatives of one another. The whole
> > > > point of dynamic linking is that you can provide independent implementations
> > > > of the API, and you can clearly substitute libcryptsetup with another
> > > > implementation, and both bodies of code are usable without one another.
> > > 
> > > Then how would you interpret the following statements:
> > > https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
> > > https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
> > > https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
> > 
> > I interpret them as FSF wanting to drum up the importance of GPL a bit
> > by purposefully not clarifying this area. The case of linking non-GPL
> > software with GPL libraries is quite common and important,
> 
> I'm not sure where you get that from. The usual interpretation is that
> linking to a GPLed library means the linked work must be GPL as well.
I don't think that's true. It only must have a compatible license.

(For example, pure proprietary code would not be allowed to link with
a GPL library because of the restrictions of the proprietary license,
the GPL side would be OK with that, as long as the resulting whole
is not distributed.)

> That's
> why the LGPL exists in the first place: It allows linking to from GPL-incompatible
> works (as long as the LGPLed component can be replaced, either by dynamic
> linking or by providing object files for relinking).
Yes, that's the original reason, but there can be different motivations.
After all, the strength of both GPL and LGPL is that they describe their
requirements in high level terms, without mentioning specific technical
details, which makes both licenses so versatile and long-lived.

> And of course, that's the whole reason for the GPL linking exception
> used by classpath which explicitly starts with:
> 
> "Linking this library statically or dynamically with other modules is
>  making a combined work based on this library. Thus, the terms and
>  conditions of the GNU General Public License cover the whole combination."
> 
> Before specifying the exception.

LGPL says "A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a work,
in isolation, is not a derivative work of the Library, [...]". 

(Whether something is a derivative work is question of human
creativity, and the license that is later attached only matters for
whether the creation can be legally distributed, and not for the fact
of being a derivate or not. This definition applies generally, and
matches how I understand the mere fact of using a few bits from a
public interface.)

> > > IMHO it's not so obvious and it may depend on a specific
> > > case. Perhaps in case of runtime dynamic linking when GPL library
> > > existence is not required for the application to run it will be
> > > treated as a mere aggregation. With all due respect I think that to
> > > solve it we'd need a lawyer indeed :)
> > 
> > Well, will all respect due to (a) lawyer, to solve it once and for
> > all, we'd probably need a body of binding court decisions in multiple
> > jurisdictions ;)
> > 
> > In the GPL there's very little about what derived means. Various
> > interpretations in the FSF FAQ are post-factum, and not part of the
> > license. I'm pretty sure that the interpretation that independent
> > works distributed as parts of a distro are still independent is in
> > agreement with both the spirit and the letter of the GPL.
> > In Galoob v. Nintendo, in appeal, it was ruled that the derivative
> > work "must incorporate a portion of the copyrighted work in some form",
> > which does not happen when you just put two rpms side by side.
> 
> In the Oracle vs Google appeal, it was determined that APIs are
> copyrightable (mostly), hence any use of a GPLed API would create a
> GPLed derivate work.

I don't think the decision in that case made much sense to most
programmers. But even if we accept Oracle v. Google as given,
there is a big difference between recreating the whole thing to
fulfill an API, and narrow use of a very small portion of an API.
I don't think Oracle v. Google has much bearing on the question
in this thread, and certainly you can't generalize it to *any*
use of an API.

Zbyszek