On 6/5/05, Steve Langasek <[EMAIL PROTECTED]> wrote: > I have no reason to believe that the GPL's claim depends on the status of > derivative works; it is a condition of distributing binaries under the GPL > that the source to the work "and any components it contains" must be made > available under the terms of the GPL. The fact that Alexandria does not > make *direct* use of OpenSSL is no defense, IMHO.
That's in the context of a "work based on the Program" (check out the first sentence of GPL section 2), which is a derivative work under copyright law, which doesn't "contain" things that are used by reference. I'm disinclined to reopen that debate on d-l, though; I've written up a reasonably coherent essay containing the arguments I gave, with case law, but it's rather long and I might decide I don't feel like publishing it for free anyway. :-) Contact me if you would like a copy for your private review. > I care; I don't like either the OpenSSL license or the OpenSSL code, and I > think it's in Debian's interest to distance itself from both to the greatest > extent possible. I don't particularly like the code either, and the license as commonly interpreted is indeed a little on the obnoxious side. But OpenSSL has the virtue of working most of the time, Debian's version more consistently than most. And I wouldn't like to see Debian swept up in the apparent FSF campaign to marginalize OpenSSL and its maintainers by threatening legal action against anyone who links GPL code (FSF copyrighted or not) to OpenSSL. (I have not personally been the target of any such threat, so this is definitely hearsay coming from me.) > Also not a defense; it's entirely valid for someone to release code under > the GPL that they know cannot be bundled in binary form by OS distributors. > Your argument would also imply that Microsoft is allowed to bundle any GPLed > software they want to with Windows without opening their libs, merely > because it's been written to use Windows-specific APIs. This is not a sane > assumption in the case of Microsoft, and it's not a sane assumption in our > case either. If this *is* the author's intent, it should be trivial to > secure a license clarification. Agreed completely. Cheers, - Michael
