* Martin Pitt (mp...@debian.org) [110213 17:51]: > Andreas Barth [2011-02-13 13:01 +0100]: > > If calling psql as > > LD_PRELOAD=/lib/libreadline.so.5 psql > > everything works as normal. As that is just usage, not linking, that > > isn't covered by the GPL > > I can't follow this reasoning. LD_PRELOAD invokes the linker (ld.so) > just in by and large the same way as a linked library through the ELF > header. I don't think that the origin of the link request (ELF header > or environment variable) matters in any way here.
Perhaps we should pass that by debian-legal, ftp-masters and/or our legal advisories. I'm not claiming that this is simple, or that my understanding is correct. Basically what we would do is the same as wine does: We have two different implementations of the same binary abi. And abis are not copyrightable, at least according to the FSF. In details, my understanding is as follows: The gpl regulates copying, distribution and modification of works. The gpl also enforces that any work that is part of the source of a work that is derived from an gpl-work and is distributed is gpl-compatible licensed (because the resulting source bundle itself needs to be gpl-compatible licensed). This especially means that any programm that we distribute and that is derived from an gpl-library is licensed as gpl-compatible, as well as any other libraries that work is derived from. "derived from" happens already if the packages uses .h-files from the gpl-library, runs the "link stage" again the so-files during compilation etc. Now, the important place to look at is "derived work". If there is no (relevant) gpl work in the source environment, how could the resulting binary by derived from gpl? If there is no distributed binary that is derived from gpl, the gpl has no say about the source at all. So, as we don't deliver binary packages that are derived from the libreadline-code (as libreadline isn't part of the source environment used during building packages), that's ok. (Please note that the important reason why we could do that is because there is some basically working non-gpl library package using the same ABI. We wouldn't be able to "just copy the .h-files around", because the .h-files would be derived from an gpl work, and therefore be within the gpl license itself. And it only works because the gpl believes that interfaces itself are not copyrightable. We need an cleanroom-implementation of the same ABI, and we have it in this case.) > Don't get me wrong, I really hate this libedit hack, but if people are > serious about it, then moving to LD_PRELOAD doesn't buy anything. Then > we can just as well ignore it [1] and switch back to the old > behaviour. I agree with you - unless we consider that LD_PRELOAD is actually "less evil", there is no reason for doing it (because technically that is definitly uglier). Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
