On Thu, Feb 10, 2000 at 12:53:02PM -0500, Raul Miller wrote: > > > Either the program uses readline or it doesn't. If it does use readline, > > > and it's distributed with readline, then, strictly-speaking, it contains > > > readline. > > > I disagree.. If it was not built using one piece of readline (ie, none of > > readline's headers) it does not contain readline until it is run. > > The GPL doesn't say that a program has to be built using headers. You're right, it doesn't. I just don't see how the GPL has the right to affect use of the software (as opposed to development) given that use of software is beyond the GPL's scope. The GPL has no power to apply to non-GPL'd works which are not derivative in source or binary form from GPL'd works. We have already established this as true else the GPL would have failed the DFSG. In order for you to apply the GPL's terms to this hypothetical program you must first establish that a derivative work is being distributed. In the case of a GPL'd KDE app that's easy. In the case of an app linked against GPL'd headers, that's easy again. An app which is not GPL'd and does not fall into either of the above categories is a bit more difficult---I don't see the derivision. > Your claim would mean that if, for example, I use a hex editor on a program to > alter the libraries it uses, that I would be able to build programs that > are built on GPLed code but which aren't bound by the GPL. I may not fully grasp the connection here, so let me extend this example to be sure I do actually understand your point: Instead of very late binding as mentioned previously, you would use late binding (ie, dynamic linking) by #include'ing say <myreadline/readline.h> or whatever files and have -lmyreadline in the makefile's LDFLAGS... This would produce a program linked against libmyreadline.so which happens to share GNU readline's ABI. Then to make it instead use GNU readline you would modify it such that ld.so would load the equivalent libreadline.so, much as I modified the pre-source release glquake binary to use libGL.so.1 in place of libMesaGL.so.2.6.. You are saying that this would not sit well with the GPL on GNU readline and be considered infringement. You might be right---I could not even begin to guess at how this would be handled. It's IMO right on the borderline and without a legal decision (it wouldn't have to be case law necessarily as this discussion is academic more than it is legal being that we're not lawyers) I'd say it's too close to call. If you've got a reference to a decision I'd love to read it though. In the case of very late binding, it seems to be a little bit past that line IMO.. I think it would have to be decided by a judge on a case by case basis until there was some case law which firmly considered very late binding to be the same as dynamic binding (which clearly is the same as static binding because of the GPL'd API and the ABI symbols read from the shared object library.. I am curious how you think the BSDish readline would stack up in these examples. The BSDish readline replacement uses the name libreadline. It also places its headers in where GNU readline would. Essentially, they are two different libraries which do share a common interface in terms of API, ABI, and soname. I believe it can even be built as a wrapper for the BSD equivalent of readline to provide almost full feature compatibility. This is a case where there are two alternatives for a library. One is GPL'd and is usually found on Linux systems, the other is not and _can_ be found on Linux systems but probably wouldn't be. It may or may not be found on other systems. > > The GPL can't control usage, only distribution. > > True. Which is why I pointed out that it matters how the program is > being distributed. Agreed. > > I am of the opinion that static vs dynamic linking is irrelivant > > because in Qt's case the inclusion of Qt happens before linking. > > I'm of the opinion that it doesn't matter because working copies of > the program are being distributed, and those working copies contain > both QPL and GPL licensed code. Even in a late binding situation the ABI symbols and headers are linked in. If you replace the headers you still have the symbols. If you replace the shared lib, well you have a more complex situation. libGL for example, if the API and ABI are the same for all Linux GL implementations, the fact that some of them may be under the GPL or other licenses cannot force binaries built against the generic API/ABI to be GPL'd. That'd just be seriously overreaching. > The GPL doesn't care how the program is built -- that's not something > that matters to the GPL. Agreed. However the GPL has no say (whether it would care or not) if there is no derived work being distributed. It seems that very late binding would screw that up because there is never a derivision, not even headers or symbols. -- Joseph Carter <knghtbrd@debian.org> Debian Linux developer http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43 http://www.debian.org 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 <doogie> Debian - All the power, without the silly hat.
Attachment:
pgpRWSTu6boEQ.pgp
Description: PGP signature