[systemd-devel] [networkd] Unable to set MTU with .link file
I am tearing my hair out trying to figure out why I an unable to set the MTU of an OVS port with a .link file. I am trying to create this: ++ ++ || || | eno1 | | eno2 | | (MTU = 8996) | | (MTU = 8996) | || || +---++ +---++ | | +---+---+ | +---++ || | bond0 | | (MTU = 8996) | || +---++ | +---++ || | ovs0 | | (MTU = 8996) | || +---++ | +---+---+ | | +---++ +---++ || || | vlan248| | vlan250| | (MTU = 8996) | | (MTU = 1500) | || || ++ ++ Everything works, except that vlan250 is inheriting the jumbo MTU from ovs0. I've created a link file to set the MTU to 1500: /etc/systemd/network/98-vlan250.link: [Match] OriginalName=vlan250 [Link] MTUBytes=1500 For some reason, this isn't working. I've set udev_log="debug" in /etc/udev/udev.conf and rebuilt my initramfs. I've also created a drop-in for systemd-networkd that sets SYSTEMD_LOG_LEVEL=debug. A full boot log with these settings can be found at: http://www.penurio.us/journal.txt Any ideas or debugging techniques very much appreciated. -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ 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 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] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.
On Thu, Jun 08 2017, J. Bruce Fields wrote: > On Thu, Jun 08, 2017 at 03:16:52PM +1000, NeilBrown wrote: >> So I think I've found a solution for systemd to handle "bg" nfs mounts >> correctly. I'll submit some pull requests for consideration. > > Out of curiosity, after that change is there still any reason you'd > recommend any new user actually use "bg" (as opposed to an automount)? Me? Recommend? Who would listen? Who would even hear? For the last few years I've been recommending that automount should be used for *all* NFS mounts at every opportunity. I think I've had two opportunities. But no, I would not recommend "bg". I would recommend automount and then when they reported problems, I would help fix them. I would be much happier recommending automount if it were easier. Setting up /etc/auto.direct with automountd is fairly easy, but you need to actually enable it but modifying auto.master or auto.master.d, which is slightly annoying. systemd does make it easier to do direct mounts, but it is ugly. You need to include "comment=systemd.automount" or "x-systemd.automount" in /etc/fstab instead of just "automount" or "ondemand". I understand exactly why they did that and I cannot fault the logic. But it still looks clumsy. With systemd, you cannot divorce the timeout that an application has to wait when accessing the mountpoint while the server is down, from the timeout imposed on the mount program. i.e., mount cannot keep trying in the background. - that could be useful if you want really-short timeouts... at least it seems to me that they should be separate. The timeout is configured differently if mounting from a device, or mounting from anything else such as NFS. The first uses x-systemd.device-timeout. The other needs x-systemd.mount-timeout. But I'm ranting... I should probably shut up and send patches. A generator for /etc/fstab.auto?? > > I appreciate the effort to keep existing systems working, I'm just > curious. Compatibility with existing practice is certainly the main driver. Thanks, NeilBrown signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [networkd] Unable to set MTU with .link file
I am tearing my hair out trying to figure out why I an unable to set the MTU of an OVS port with a .link file. I am trying to create this: ++ ++ || || | eno1 | | eno2 | | (MTU = 8996) | | (MTU = 8996) | || || +---++ +---++ | | +---+---+ | +---++ || | bond0 | | (MTU = 8996) | || +---++ | +---++ || | ovs0 | | (MTU = 8996) | || +---++ | +---+---+ | | +---++ +---++ || || | vlan248| | vlan250| | (MTU = 8996) | | (MTU = 1500) | || || ++ ++ Everything works, except that vlan250 is inheriting the jumbo MTU from ovs0. I've created a link file to set the MTU to 1500: /etc/systemd/network/98-vlan250.link: [Match] OriginalName=vlan250 [Link] MTUBytes=1500 For some reason, this isn't working. I've set udev_log="debug" in /etc/udev/udev.conf and rebuilt my initramfs. I've also created a drop-in for systemd-networkd that sets SYSTEMD_LOG_LEVEL=debug. A full boot log with these settings can be found at: http://www.penurio.us/journal.txt Any ideas or debugging techniques very much appreciated. -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.
On 06/07/2017 12:08 PM, J. Bruce Fields wrote: > On Wed, Jun 07, 2017 at 06:04:12AM -0400, Steve Dickson wrote: >> # ps ax | grep mount >> 980 ?Ss 0:00 /sbin/mount.nfs nfssrv:/home/tmp /mnt/tmp -o rw,bg > > Right, but I think we also need to see a "systemctl status > remote-fs.target", or something, to verify whether that's the forked > background process or just the foreground process that's still hanging > up some part of the boot process (even though it's gotten far enough > along that you can log in--unless logins aren't permitted till remote > fs's are mounted, I don't know.) It succeeds... # systemctl status remote-fs.target * remote-fs.target - Remote File Systems Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; enabled; vendor preset: enabled) Active: active since Tue 2017-06-06 12:36:51 EDT; 12min ago Docs: man:systemd.special(7) Jun 06 12:36:51 f26 systemd[1]: Reached target Remote File Systems. The reason being, as Neil pointed out, the mount.nfs gets the ECONNREFUSED right away because the server is down. So a child is quickly forked that continues to try the mount... Basically sneaking around systemd back... Which is hard to do... these day 8-) steved. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.
On 06/08/2017 01:16 AM, NeilBrown wrote: > On Wed, Jun 07 2017, Steve Dickson wrote: > >> On 06/07/2017 08:02 AM, Lennart Poettering wrote: >>> On Wed, 07.06.17 06:08, Steve Dickson (ste...@redhat.com) wrote: >>> On 06/06/2017 05:49 PM, NeilBrown wrote: > On Tue, Jun 06 2017, Steve Dickson wrote: > >> Hello, >> >> On 05/29/2017 06:19 PM, NeilBrown wrote: >>> >>> Systemd does not, and will not, support "bg" correctly. >>> It has other, better, ways to handle "background" mounting. >> The only problem with this is bg mounts still work at least >> up to 4.11 kernel... > > I don't think this is correct. > In the default configuration, "mount -t nfs -o bg " > runs for longer than 90 seconds, so systemd kill it. I must be missing something... it seems to be working for me # mount -vvv -o bg rhel7srv:/home/tmp /mnt/tmp mount.nfs: trying text-based options 'bg,vers=4.1,addr=172.31.1.60,clientaddr=172.31.1.58' mount.nfs: mount(2): Connection refused mount.nfs: trying text-based options 'bg,addr=172.31.1.60' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 172.31.1.60 prog 13 vers 3 prot TCP port 2049 mount.nfs: portmap query failed: RPC: Remote system error - Connection refused mount.nfs: backgrounding "rhel7srv:/home/tmp" mount.nfs: mount options: "rw,bg" >>> >>> We are talking about mounts done through /etc/fstab, i.e. the ones >>> systemd actually manages. >> I guess I was not clear... After adding a bg mount to fstab and >> reboot, mounting a server that is not up, there is a mount in >> background that looks like >> >> # ps ax | grep mount >> 1104 ?Ss 0:00 /sbin/mount.nfs nfssrv:/home/tmp /mnt/tmp -o rw,bg >> >> Looking at the remote-fs.target status: >> >> # systemctl status remote-fs.target >> * remote-fs.target - Remote File Systems >>Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; enabled; vendor >> preset: enabled) >>Active: active since Tue 2017-06-06 12:36:51 EDT; 12min ago >> Docs: man:systemd.special(7) >> >> Jun 06 12:36:51 f26.boston.devel.redhat.com systemd[1]: Reached target >> Remote File Systems. >> >> It appears to be successful > > Strange ... not for me. > > I have a recent compiled-from-source upstream systemd and a very recent > upstream kernel. > > I add a line to /etc/fstab > > 192.168.1.111:/nowhere /mnt nfs bg 0 0 > > and reboot (192.168.1.111 is on a different subnet to the VM I am > testing in, but no host responds to the address). > > There is a 1m30s wait while trying to mount /mnt, then boot completes > (I was wrong when I said that it didn't). > > ● mnt.mount - /mnt >Loaded: loaded (/etc/fstab; generated; vendor preset: enabled) >Active: failed (Result: timeout) since Thu 2017-06-08 11:13:52 AEST; 1min > 24s ago > Where: /mnt > What: 192.168.1.111:/nowhere > Docs: man:fstab(5) >man:systemd-fstab-generator(8) > Process: 333 ExecMount=/bin/mount 192.168.1.111:/nowhere /mnt -t nfs -o bg > (code=killed, signal=TERM) > > Jun 08 11:12:22 debian systemd[1]: Mounting /mnt... > Jun 08 11:13:52 debian systemd[1]: mnt.mount: Mounting timed out. Stopping. > Jun 08 11:13:52 debian systemd[1]: mnt.mount: Mount process exited, > code=killed status=15 > Jun 08 11:13:52 debian systemd[1]: Failed to mount /mnt. > Jun 08 11:13:52 debian systemd[1]: mnt.mount: Unit entered failed state. > > > The /bin/mount process has been killed (SIGTERM) after the 90 second > timeout > > ● remote-fs.target - Remote File Systems >Loaded: loaded (/lib/systemd/system/remote-fs.target; enabled; vendor > preset: enabled) > Drop-In: /run/systemd/generator/remote-fs.target.d >└─50-insserv.conf.conf >Active: inactive (dead) > Docs: man:systemd.special(7) > > Jun 08 11:13:52 debian systemd[1]: Dependency failed for Remote File Systems. > Jun 08 11:13:52 debian systemd[1]: remote-fs.target: Job > remote-fs.target/start failed with result 'dependency'. > > > remote-fs.target has not been reached. I'm seeing this now... the server has to be up to cause this hang. > > Because remote-fs.target is WantedBy multi-user.target, but need > RequiredBy it, boot completes. > But if anything did Require remote-fs.target, it would fail if "bg" > mounts were not mounted within 90 seconds. > > > Looking back over your log messages: > mount.nfs: portmap query failed: RPC: Remote system error - Connection refused mount.nfs: backgrounding "rhel7srv:/home/tmp" > > it appears that the fg mount attempt failed quickly (ECONNREFUSED), so it > background the process immediately. Systemd sees that as success > (despite the fact that the filesystem isn't actually mounted) and > doesn't clean up the background processes (which is arguably a bug). No... Systemd is doing the right thing in this case... Letting bg mounts work... > > If you try t
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
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. 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. ___ 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