On Wed, May 21, 2003 at 01:01:06AM -0500, Branden Robinson wrote: > It seems wrong to me that we can take a free, but GPL-incompatible > application out of Debian main and hand it to two software distributors. > Each distributor grabs a different ABI-compatible implementation of a > shared library (upon which this app depends) out of Debian main. One of > those happens to be GPLed and the other does not (it's, say, under the > MIT/X11 license), but the distributors just flip a coin to decide which > one they ship. > Under your analysis, one of these guys is in deep shit with the > copyright holder of the GPLed implementation of the shared library, and > the other guy is not. > It's just a bellyfeel, but it's a strong one. What the Debian Project > distributes should not be subjecting people to this sort of risk. I > think one should be able to distribute arbitrary subsets of the Debian > OS in pretty much total ignorance of the licensing on the software > within. If they modify stuff, that's a different story. I think that's a reasonable requirement, and I don't think my analysis supports the conclusion that someone distributing a subset of Debian packages would be in violation of the GPL, *if* Debian itself is in compliance with the license. If someone distributes a subset of Debian's packages that includes a GPL library and a GPL-incompatible app, there are two principal possibilities: * Installing the application package automatically pulls in the library package, which means that whoever created the original packages (Debian) is also responsible for any GPL violations that result from such a combination. * Installing the application package does *not* automatically pull in the library package, or does so in a way that the application will not automatically load the library when you try to run the application. Manual intervention is required to combine the GPL and GPL-incompatible code, and the distributor (and Debian) cannot possibly be in violation of the license. The one corner case I can see would be an application kfrob-not-so-gpl which depends on libfrob-lgpl | libfrob-gpl. If someone installs kfrob-not-so-gpl from the Debian archive, it will pull in libfrob-lgpl unless the user declares otherwise. If a distributor ships only kfrob-not-so-gpl and libfrob-gpl, the result is different. I agree that this is bad, but I don't know of any packages this is a problem for in practice. Perhaps the best way to address this corner case would be to prohibit maintainers from doing this. > > > I hate to say this because I love my bright-line tests, but I think > > > intent matters here. Shipping "such code together with readline > > > itself", and nothing else, should be distinguishable from what Debian > > > does, which is ship "such code", "readline itself", a clone or two of > > > readline, and a whole boatload of other stuff that has nothing to do > > > with any of the above. > > I think references to the file name of the GPL'ed library in an > > application's ELF header constitute pretty damning evidence of the real > > intent. "Your honor, the plaintiff's license is non-binding because I > > could have used editline instead" doesn't sound like much of a defense > > to me. > If that's the case with readline vs. editline -- I can't be assed to > check, then you're right. But does your analysis change at all if > libeditline ships, say, its own /lib/libreadline.so.4? I mean, this is > exactly the point of ABI compatibility. Just look at the LessTif > project. I think it does change in such a case. Today, the libeditline0 and libreadline4 packages can be installed side-by-side, however, and applications built against each look for a different library name. -- Steve Langasek postmodern programmer
Attachment:
pgpqxupmGoxCM.pgp
Description: PGP signature