3 ms·

The proprietary app in this example, has no idea whether they are dynamic linking with a version of libss that has the dlopen functionality (which is the case i

by tytso 12y ago

The proprietary app in this example, has no idea whether they are dynamic linking with a version of libss that has the dlopen functionality (which is the case in the version of libss distributed with e2fsprogs), but there is also the version of libss distributed with Solaris SEAM and the MIT Kerberos v5 distribution which does not dlopen readline. This is the problem of whether the GPL infects across dynamic linking. Yes, it is possible for GPL and proprietary code to be in the same process address space, without any knowledge of the owner of the proprietary address space. It was the user who decided to use a particular version of libss, not Solaris.

stonemetal 12y ago
* It was the user who decided to use a particular version of libss, not Solaris.* That is exactly why I don't think there is a violation. Sun didn't ship code that linked(dynamically or otherwise) to GPL code. The end user did something to make that happen. It would be a violation by the end user if they shipped their combined product.
- tytso 12y ago
  Sun shipped could which _could_ link dynamically to GPL code. The problem with this "GPL infects across dynamic linking" argument is that you are therefore trying to make the claim that whether or not kadmin is infected by GPL code is dependent on whether there exists another library which is not licensed under the GPL. This gets perilously close to claiming copyright infringement, with the added wrinkle that the simplest way for someone to take code that was previously claimed to be GPL infringing is to create and ship a new library which is ABI compatible. So something could be a GPL violation, and then when a new library ships, et voila!, it's not no longer a violation. And something could orignally clearly not be a GPL violation, but when a new library ships which has a dependency (implied or explicit or even conditional in the case of an optional dlopen) on GPL code, now that proprietary binary can now run with GPL'ed code in its address space.

by tytso 12y ago

stonemetal 12y ago

* It was the user who decided to use a particular version of libss, not Solaris.* That is exactly why I don't think there is a violation. Sun didn't ship code that linked(dynamically or otherwise) to GPL code. The end user did something to make that happen. It would be a violation by the end user if they shipped their combined product.

tytso 12y ago
Sun shipped could which _could_ link dynamically to GPL code. The problem with this "GPL infects across dynamic linking" argument is that you are therefore trying to make the claim that whether or not kadmin is infected by GPL code is dependent on whether there exists another library which is not licensed under the GPL. This gets perilously close to claiming copyright infringement, with the added wrinkle that the simplest way for someone to take code that was previously claimed to be GPL infringing is to create and ship a new library which is ABI compatible. So something could be a GPL violation, and then when a new library ships, et voila!, it's not no longer a violation. And something could orignally clearly not be a GPL violation, but when a new library ships which has a dependency (implied or explicit or even conditional in the case of an optional dlopen) on GPL code, now that proprietary binary can now run with GPL'ed code in its address space.