[systemd-devel] Systemd license vs. libcryptsetup license

[Julian Andres Klode]

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. 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).

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.

> 
> > 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.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
                  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.