[systemd-devel] Systemd license vs. libcryptsetup license

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Wed Jun 7 14:48:35 UTC 2017

On Wed, Jun 07, 2017 at 11:47:58AM +0200, Krzysztof Jackiewicz wrote:
> > Not sure what "release product under GPL" is supposed to mean.
> The combined work would have to be licensed under GPL according to:
> https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
> https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
> I think that it means that the code has to be relicensed to GPL (which LGPL
> 2.1 allows). I'm not sure about it either. That's why I'm asking.

You are right that the combined work is licensed under the GPL.
But no, that has no effect on the source code itself, and there's no
reason for the source code to have to be relicensed.

> > libcryptsetup dep is optional anyway, and only used by the
> systemd-cryptsetup
> > helper, not PID 1 itself.
> I'm asking about license issues with this specific option enabled. Also, I
> don't think it matters which binary it is as long as it's included in a
> final product. 


> > Unless you link your own more restrictive code into systemd-cryptsetup the
> > dep that is libcryptsetup should not affect you in any way. At least not
> more
> > than the Linux kernel's own GPL license does. I mean, systemd doesn't
> support
> > any other kernels anyway...
> AFAIK using the kernel (syscalls) is not considered a derivative work.
> Dynamic linking is (in terms of GPL).

Right, but dynamic linking happens on the target machine. And the LGPL
and GPL license only place conditions on distributions, so before any
distribution happens, you can do whatever with the code. Let's instead look
at some points along the spectrum of possible distribution mechanisms:

- statically linked libcryptsetup + systemd, and the resulting binaries
  distributed in a tarball → clearly derived from both, can only be distributed
  under GPL
- libcryptsetup + systemd linked into an image in memory, i.e. the result
  of dynamic linking, saved for distribution as a VM snapshot or emacs-style
  memory image → the same as above
- just systemd.rpm → only systemd license applies, i.e. it's OK to distribute
  under terms of LGPL. (Though that's basically unusable, until
  you provide multiple libraries and executables from elsewhere, the rest of
  the filesystem, etc.)
- a collection of rpms, like a linux distro, including systemd.rpm,
  libcryptsetup.rpm, and thousands of other loosely coupled rpms
  → that's a mere aggregation, each of the thousands of components carries
  it's own license, each has to be satisfied separately
- you compile systemd and libcryptsetup into a bunch of dlls to run
  on windows and distribute the result in a nifty .exe installer
  → that's somewhere between the first case and fourth, but the installer
  as a whole can only be distributed under the GPL, since it contains
  GPL-only code.

So it depends on what you're trying to do with the systemd code, but
except for the contrived cases, you're free to use LGPL as stated.


More information about the systemd-devel mailing list