On Thu, Mar 07, 2002 at 04:39:55AM +1100, Timshel Knoll wrote: > I haven't seen an ITP for this around, so if no one else is working on > it or wants it more than me, I intend packaging libtrash. > My only hesitation is the legal status of this - libtrash uses a > LD_PRELOAD trick to intercept calls to unlink () (and other calls such > as rename(), fopen() et al), and would normally be inserted into > /etc/ld.so.preload. How does this sit legally if other programs (many of > which will not be GPL licensed, some of which will be non-free) will be > using the library through the LD_PRELOAD trick? Does this create a > license conflict with the GPL? I assume that if the license was LGPL, > there would be no problem with this ... am I correct to believe this? At first blush, I'd say there is no possibility of violating the GPL as long as a given tool doesn't rely, count on, or mandate linkage with a GPL'ed library, and it is not distributed in a way that does so. Admittedly, I haven't thought through this in detail, so I could be wrong, but it seems to me it would be impossible to enforce the GPL against people who, on their own systems, replace traditionally GPL'ed interfaces with proprietary ones. In other words, I could write "Branden's libc" with secret source code and permit unlimited redistribution of its binaries. Assuming my libc doesn't have any external dependencies on GPL'ed software, nobody is violating any license if he installs my libc to his own system and uses an LD_PRELOAD trick or even replaces his system's default libc with mine. There *is* a big problem if somebody takes GPL'ed applications and statically links it with my proprietary libc (if he's not the copyright holder); that's just plain forbidden by the license on the app. There is also a problem if my libc implements specialized, unique functions and someone writes an app (or another library) that uses them, and then GPL's their app. The copyright holder of that app would have to grant permission to link against my proprietary libc, because the app only has any hope of being usable if someone uses my proprietary libc in conjunction with it. Alternatively, someone can write a GPL'ed clone of my functions. This latter situation is identical in every important detail to the licensing problems that used to exist with Qt. There were three possible solutions to that problem: 1) Qt could be relicensed in a GPL-compatible way; 2) The copyright holders of all GPL'ed Qt-using apps could grant permission for their code to be used with Qt; 3) A GPL'ed clone of Qt could be developed. Eventually, TrollTech AS adopted the first solution (Qt Free Edition is dual-licensed under the QPL and the GPL). In the meantime, some people adopted approach 2, like libapt-pkg, and an abortive attempt at 3 was made (the Harmony project). For a more thorough analysis, you should probably ask debian-legal. -- G. Branden Robinson | The noble soul has reverence for Debian GNU/Linux | itself. branden@debian.org | -- Friedrich Nietzsche http://people.debian.org/~branden/ |
Attachment:
pgpsAcdPZ2Dpf.pgp
Description: PGP signature