Discussion:
Systemd license vs. libcryptsetup license
Add Reply
Krzysztof Jackiewicz
2017-06-06 14:33:11 UTC
Reply
Permalink
Raw Message
Hi,

I noticed that when systemd is configured with libcryptsetup option enabled
it will link to libcryptsetup which is distributed under GPL 2.0. It seems
like a license conflict to me. Can anyone explain it?

Thanks in advance.

Krzy
Zbigniew Jędrzejewski-Szmek
2017-06-06 15:00:28 UTC
Reply
Permalink
Raw Message
Post by Krzysztof Jackiewicz
Hi,
I noticed that when systemd is configured with libcryptsetup option enabled
it will link to libcryptsetup which is distributed under GPL 2.0. It seems
like a license conflict to me. Can anyone explain it?
A license conflict appears when two pieces of software are combined and
the licenses have incompatible terms, so they cannot be both satisfied
at the same time. Systemd is LGPL which is compatible with GPL and pretty
much anything else. Also, we don't distribute the combined product, which
is the only thing LGPL and GPL put any conditions on.

Zbyszek
Krzysztof Jackiewicz
2017-06-07 07:49:44 UTC
Reply
Permalink
Raw Message
I guess the "conflict" was not the best word to describe it.

If I want to release a product with systemd the libryptsetup option will
force me to release it under GPL. Is that correct?

Thanks,

Krzy

-----Original Message-----
From: Zbigniew Jędrzejewski-Szmek [mailto:***@in.waw.pl]
Sent: Tuesday, June 06, 2017 5:00 PM
To: Krzysztof Jackiewicz
Cc: systemd-***@lists.freedesktop.org
Subject: Re: [systemd-devel] Systemd license vs. libcryptsetup license
Post by Krzysztof Jackiewicz
Hi,
I noticed that when systemd is configured with libcryptsetup option
enabled it will link to libcryptsetup which is distributed under GPL
2.0. It seems like a license conflict to me. Can anyone explain it?
A license conflict appears when two pieces of software are combined and the
licenses have incompatible terms, so they cannot be both satisfied at the
same time. Systemd is LGPL which is compatible with GPL and pretty much
anything else. Also, we don't distribute the combined product, which is the
only thing LGPL and GPL put any conditions on.

Zbyszek
Lennart Poettering
2017-06-07 08:09:11 UTC
Reply
Permalink
Raw Message
Post by Krzysztof Jackiewicz
I guess the "conflict" was not the best word to describe it.
If I want to release a product with systemd the libryptsetup option will
force me to release it under GPL. Is that correct?
Not sure what "release product under GPL" is supposed to mean. Note
that the libcryptsetup dep is optional anyway, and only used by the
systemd-cryptsetup helper, not PID 1 itself.

Unless you link your own more restrictive code into systemd-cryptsetup
the GPL 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...

IANAL, so better ask a lawyer if you want definitive answers. But
whether something is GPL or not only matters whether your program
links to to it or not, and systemd only does so in one of its
processes (and not in PID 1), but even if it did link in PID 1 to
libcryptsetup it wouldn't matter, as long as you don't insert your own
non-free stuff into PID 1 too...

Lennart
--
Lennart Poettering, Red Hat
Krzysztof Jackiewicz
2017-06-07 09:47:58 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
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.
Post by Lennart Poettering
libcryptsetup dep is optional anyway, and only used by the
systemd-cryptsetup
Post by Lennart Poettering
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.
Post by Lennart Poettering
Unless you link your own more restrictive code into systemd-cryptsetup the
GPL
Post by Lennart Poettering
dep that is libcryptsetup should not affect you in any way. At least not
more
Post by Lennart Poettering
than the Linux kernel's own GPL license does. I mean, systemd doesn't
support
Post by Lennart Poettering
any other kernels anyway...
AFAIK using the kernel (syscalls) is not considered a derivative work.
Dynamic linking is (in terms of GPL).

Krzy
Zbigniew Jędrzejewski-Szmek
2017-06-07 14:48:35 UTC
Reply
Permalink
Raw Message
Post by Krzysztof Jackiewicz
Post by Lennart Poettering
Not sure what "release product under GPL" is supposed to mean.
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.
Post by Krzysztof Jackiewicz
Post by Lennart Poettering
libcryptsetup dep is optional anyway, and only used by the
systemd-cryptsetup
Post by Lennart Poettering
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.
Right.
Post by Krzysztof Jackiewicz
Post by Lennart Poettering
Unless you link your own more restrictive code into systemd-cryptsetup the
GPL
Post by Lennart Poettering
dep that is libcryptsetup should not affect you in any way. At least not
more
Post by Lennart Poettering
than the Linux kernel's own GPL license does. I mean, systemd doesn't
support
Post by Lennart Poettering
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.

Zbyszek
Krzysztof Jackiewicz
2017-06-07 15:26:21 UTC
Reply
Permalink
Raw Message
Thanks, for explanation.
Post by Zbigniew Jędrzejewski-Szmek
- 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
It is mere aggregation as long as binary from systemd.rpm does not link to a library from libcryptsetup.rpm. If it does then it's a combination or a derivative work in terms of GPL and as such the systemd.rpm should include a GPL license (and of course comply with other GPL terms and conditions). Is that correct?

Krzy
Greg KH
2017-06-07 16:08:49 UTC
Reply
Permalink
Raw Message
Post by Krzysztof Jackiewicz
Thanks, for explanation.
Post by Zbigniew Jędrzejewski-Szmek
- 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
It is mere aggregation as long as binary from systemd.rpm does not
link to a library from libcryptsetup.rpm. If it does then it's a
combination or a derivative work in terms of GPL and as such the
systemd.rpm should include a GPL license (and of course comply with
other GPL terms and conditions). Is that correct?
You need to consult a lawyer to get a definitive answer for this, please
don't ask developers for legal advice :)

good luck!

greg k-h
Krzysztof Jackiewicz
2017-06-08 07:44:06 UTC
Reply
Permalink
Raw Message
You need to consult a lawyer to get a definitive answer for this, please don't
ask developers for legal advice :)
Yeah, it seems so :) Initially I thought that the answer is more obvious.
Zbigniew Jędrzejewski-Szmek
2017-06-07 16:30:39 UTC
Reply
Permalink
Raw Message
Post by Krzysztof Jackiewicz
Thanks, for explanation.
Post by Zbigniew Jędrzejewski-Szmek
- 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
It is mere aggregation as long as binary from systemd.rpm does not link to a library from libcryptsetup.rpm. If it does then it's a combination or a derivative work in terms of GPL and as such the systemd.rpm should include a GPL license (and of course comply with other GPL terms and conditions). Is that correct?
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.

Zbyszek
Krzysztof Jackiewicz
2017-06-08 07:40:17 UTC
Reply
Permalink
Raw Message
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

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

Krzy
Zbigniew Jędrzejewski-Szmek
2017-06-08 13:47:56 UTC
Reply
Permalink
Raw Message
Post by Krzysztof Jackiewicz
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.
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, and if they
wanted to add an entry to the FAQ, they certainly would. They talk a lot
about "plugins", but that's a significantly different case, because a
plugin is very closely tied to the program that loads it.
Post by Krzysztof Jackiewicz
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.

Zbyszek
Krzysztof Jackiewicz
2017-06-08 15:15:55 UTC
Reply
Permalink
Raw Message
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, and if they wanted to add an
entry
to the FAQ, they certainly would. They talk a lot about "plugins", but
that's a
significantly different case, because a plugin is very closely tied to the
program
that loads it.
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.
That's an interesting point of view. I have no further questions :)

Thanks,

Krzy
Julian Andres Klode
2017-06-08 16:14:12 UTC
Reply
Permalink
Raw Message
Post by Zbigniew Jędrzejewski-Szmek
Post by Krzysztof Jackiewicz
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.
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.
Post by Zbigniew Jędrzejewski-Szmek
Post by Krzysztof Jackiewicz
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.
Zbigniew Jędrzejewski-Szmek
2017-06-08 17:14:15 UTC
Reply
Permalink
Raw Message
Post by Julian Andres Klode
Post by Zbigniew Jędrzejewski-Szmek
Post by Krzysztof Jackiewicz
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.
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.)
Post by Julian Andres Klode
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.
Post by Julian Andres Klode
And of course, that's the whole reason for the GPL linking exception
"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.)
Post by Julian Andres Klode
Post by Zbigniew Jędrzejewski-Szmek
Post by Krzysztof Jackiewicz
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
Uoti Urpala
2017-06-08 19:00:03 UTC
Reply
Permalink
Raw Message
Post by Zbigniew Jędrzejewski-Szmek
Post by Julian Andres Klode
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.
I think that is the default FSF position. There are at least some cases
where it's likely not automatic (for example, if there's a widespread
API/ABI that is provided by both GPLed and differently-licensed
libraries, an executable that works with both seems to have at least a
reasonable claim to not being a derivative work). However, assuming
that using a library may make the executable a derivative work seems to
be the only safe default assumption.

If the only thing you know is that some code uses the library, that may
mean things like nontrivial inline functions being included in the
compiled code, or copy relocations copying arbitrary amounts of data
into an executable. It seems pretty clear that this can be considered a
derived work. So I don't think you can ever claim that GPL wouldn't
cover the linked work without at least some analysis of the specific
library in question and how it's used in the program.
Uoti Urpala
2017-06-08 19:05:48 UTC
Reply
Permalink
Raw Message
Post by Uoti Urpala
compiled code, or copy relocations copying arbitrary amounts of data
into an executable. It seems pretty clear that this can be considered a
Rereading that, copy relocations are actually not that good an example
since the copying normally happens at runtime. So better consider just
inline functions.
Zbigniew Jędrzejewski-Szmek
2017-06-08 23:17:25 UTC
Reply
Permalink
Raw Message
Post by Uoti Urpala
Post by Zbigniew Jędrzejewski-Szmek
Post by Julian Andres Klode
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.
I think that is the default FSF position. There are at least some cases
where it's likely not automatic (for example, if there's a widespread
API/ABI that is provided by both GPLed and differently-licensed
libraries, an executable that works with both seems to have at least a
reasonable claim to not being a derivative work). However, assuming
that using a library may make the executable a derivative work seems to
be the only safe default assumption.
Yes, FSF seems to be saying that, but I don't think this makes sense.
The copyright is about protecting the creative part of a given work,
and just using the API does not incorporate or copy the creative
process used to create the library.
Post by Uoti Urpala
If the only thing you know is that some code uses the library, that may
mean things like nontrivial inline functions being included in the
compiled code, or copy relocations copying arbitrary amounts of data
into an executable. It seems pretty clear that this can be considered a
derived work. So I don't think you can ever claim that GPL wouldn't
cover the linked work without at least some analysis of the specific
library in question and how it's used in the program.
(I'm ignoring copy relocations which happen at runtime.)
You are right that a program compiled against a "header library" would
be most likely be a derivative work. But still, this is a special
case. I'm not claiming that GPL wouldn't apply ever, but that it
doesn't in the common case of a program calling a few functions from a
separately distributed library.

Zbyszek

P.S. I think there's a lot of politicking on the FSF website, which
undermines their credibility:
"GNU/Linux is used by millions, though many call it “Linux” by mistake."
"We recommend installable versions of GNU (more precisely, GNU/Linux distributions)"
Seriously.

Lennart Poettering
2017-06-07 07:46:30 UTC
Reply
Permalink
Raw Message
Post by Krzysztof Jackiewicz
Hi,
I noticed that when systemd is configured with libcryptsetup option enabled
it will link to libcryptsetup which is distributed under GPL 2.0. It seems
like a license conflict to me. Can anyone explain it?
systemd is licensed under LGPL2.1+ in its entirety (well, there are
some specific exceptions for very specific files for historic reasons
or because they originate elsewhere) so that we can liberally move
things around within our own tree. During runtime we might link to
more restrictively licensed libraries wich will effectively downgrade
the relevant bits of our code to that more restrictive license too
(which LGPL permits). Or in other words: GPL and LGPL are of course
compatible, and that's what we mix in some of our processes and is
hence fine. Of course, if we end up mixing two libraries in the same
process with conflicting licenses we need to be careful, but GPL+LGPL
are not that.

Lennart
--
Lennart Poettering, Red Hat
Loading...