Re: [systemd-devel] Systemd license vs. libcryptsetup license
On Thu, Jun 08, 2017 at 10:00:03PM +0300, Uoti Urpala wrote: > On Thu, 2017-06-08 at 17:14 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jun 08, 2017 at 06:03:37PM +0200, Julian Andres Klode wrote: > > > 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. > 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
On Thu, 2017-06-08 at 17:14 +, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jun 08, 2017 at 06:03:37PM +0200, Julian Andres Klode wrote: > > 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
On Thu, 2017-06-08 at 22:00 +0300, Uoti Urpala wrote: > 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
On Thu, Jun 08, 2017 at 06:03:37PM +0200, Julian Andres Klode wrote: > On Thu, Jun 08, 2017 at 01:47:56PM +, 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
> 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
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, 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. > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
> 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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
> 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
On Wed, Jun 07, 2017 at 05:26:21PM +0200, Krzysztof Jackiewicz wrote: > Thanks, for explanation. > > > - 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
On Wed, Jun 07, 2017 at 05:26:21PM +0200, Krzysztof Jackiewicz wrote: > Thanks, for explanation. > > > - 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
Thanks, for explanation. > - 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
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. Right. > > 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... > > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
> 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. > 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 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... AFAIK using the kernel (syscalls) is not considered a derivative work. Dynamic linking is (in terms of GPL). Krzy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
On Wed, 07.06.17 09:49, Krzysztof Jackiewicz (k.jackiew...@samsung.com) wrote: > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
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:zbys...@in.waw.pl] Sent: Tuesday, June 06, 2017 5:00 PM To: Krzysztof Jackiewicz Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Systemd license vs. libcryptsetup license On Tue, Jun 06, 2017 at 04:33:11PM +0200, Krzysztof Jackiewicz wrote: > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
On Tue, 06.06.17 16:33, Krzysztof Jackiewicz (k.jackiew...@samsung.com) wrote: > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd license vs. libcryptsetup license
On Tue, Jun 06, 2017 at 04:33:11PM +0200, Krzysztof Jackiewicz wrote: > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
