Bug#608442: using libreadline within psql?
It looks like you have a work around by building against libedit, but linking to against libreadline. I think this is a big improvement against everything being broken, but a really _HORRIBLE_ ingenious solution :) Could we not go back to building against libreadline and reopen the licencing bug as not yet resolved. The issue has now been raised across the community and I do not think any other distribution has dropped building against libreadline. There is now a work around that can be implemented quickly in case libreadline becomes a serious legal issue. However, it think from a maintenance point of view, building against a broken lib and linking to another on the fly is really confusing, and it would be good to verify if the licencing issue is real. -- Ronald Duncan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608442: using libreadline within psql?
Hi, 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 (see the pretext, stating that Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted [...]). Now, that could be automated in the psql-script, checking if the libreadline5-binary is there, and if so, using that (plus adding an recommends, but that's a different story). It should even be possible (but that's probably not for 8.4 anymore) to link during compiletime with libedit, but try during execution to load the most appropriate available library (LD_PRELOAD is a bit too ugly I think - but probably the best we could do for squeeze). Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608442: using libreadline within psql?
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. 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. Martin [1] FWIW, I'd fully support this. If someone from OpenSSL or libreadline will actually complain and threat us, we can still switch to libedit.. -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608442: using libreadline within psql?
* 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
Bug#608442: using libreadline within psql?
Hello Andreas, Andreas Barth [2011-02-13 19:18 +0100]: 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. So you think linking in the license sense just applies to the time when we build the package (and have the header files available), and not any more to the runtime stage when we execute the program? If that offers a legally acceptable workaround, I'm happy to apply it. :-) I'd still have a weird feeling about it, though, as the end result for the user is exactly the same.. 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. So I don't understand why merely building against an API already makes a program a derived work of that API; it's merely using that API, after all? Anyway, thanks a lot for your input and suggestions here! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608442: using libreadline within psql?
* Martin Pitt (mp...@debian.org) [110213 20:21]: Andreas Barth [2011-02-13 19:18 +0100]: 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. So you think linking in the license sense just applies to the time when we build the package (and have the header files available), and not any more to the runtime stage when we execute the program? If that Header files *might* contain more than just structures, e.g. #defines which might contain code. If a header file contains just structures and names, and no code / whatever else, then it just describes an api and for people who don't believe in interface copyrights (like the FSF) it isn't copyrightable. Also during link time, some data from the .so-file pointed at might be included in the resulting binary by the linker. So that makes the resulting binary derived from the .so. offers a legally acceptable workaround, I'm happy to apply it. :-) That's my understanding. As I said, I'm happy to pass that via d-legal or whoever else - I don't claim to necessarily be always right, but that's what I learned during the last few years. I'd still have a weird feeling about it, though, as the end result for the user is exactly the same.. I agree about the feeling. The legal world however has lots of strange parts. 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. So I don't understand why merely building against an API already makes a program a derived work of that API; it's merely using that API, after all? Basically, because a) the .h-files might contain code (though in some cases .h might be irrelevant for copyright, but one has to look at the file) b) data from the .so is included. It's hard to get away from derived if the .h/.so is installed in the build environment. If however the .h/.so isn't installed there, I don't see how the process of building could violate the license of an non-installed programm (well, if the license is DFSG-free - it's easy to write an license that says if you use this code once, we own your soul, but that's something else). Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608442: using libreadline within psql?
retitle 608442 use libreadline instead of libedit for psql reassign 608442 postgresql-common 113 forcemerge 608442 607907 607109 611918 thanks Thank you Andi for the more detailled explanation! So here's my plan of record: * I will continue to build the postgresql-X.Y packages against libedit, to have a build/linking process which satisfies the licenses. * postgresql-client-common ships a wrapper for psql anyway (for the multi-version/multi-cluster infrastructure). I'll update that to add libreadline to LD_PRELOAD, if available. * Add libreadline recommends to postgresql-client-common. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
