Re: openssl vs. GPL question
On 6/5/05, Steve Langasek <firstname.lastname@example.org> 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
> 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.