On Mon, Apr 22, 2002 at 10:44:57AM +1000, Brian May wrote: > So I take it that the advertising clause is the only problem with > the OpenSSL license? As far as I'm aware, yes. > And can I also assume that the copyright holders have been contacted > about this (probably billions of times), but don't want to change the > license, for some reason? The explanation I once saw from a member of the OpenSSL devel team (posted to a public list) is that some would like to revise the license, but they're not at liberty to do so -- they're still using code from Eric Young, who now works for a company that writes crypto software; and they seem to be certain enough in what Eric's answer would be (or what it ought to be if he wants to keep his job) that they haven't bothered asking him. > > The current interpretation of this accepted by Debian, which I've been > > unable to find fault with, is that if your operating system comes with > > OpenSSL, it's ok to link *third-party* GPLed works against it; but if > > you distribute a GPLed work together with the libraries it depends on, > > even as part of an OS distribution (such as Debian), then those > > libraries must all be licensed in a manner that's compatible with the > > GPL. > It is very vague. I wonder what the intention was. I don't think it's particularly vague. There are details that can be easily overlooked with a casual reading, but the language as written is not confusing or indeterminate. > However, I am a bit puzzled; does that mean: > - It is OK to distribute these programs if they are seperate from > Debian? It is OK to create GPL binaries linked against OpenSSL and compiled for Debian platforms, and distribute them outside of Debian. But the wording of the GPL indicates you could never distribute those binaries with Debian -- not even selling them on different CDs in a multi-CD set, I think. > - It is OK to distribute a close source package that uses GPL packages > from Debian? I'm not sure what you mean by that. How is the answer even relevant to Debian? > My feeling is that these limitations aren't on the source code, but > the binary code. If it was only the source code, then the binary code > wouldn't matter. > So you can link X (GPL) against Y (BSD), but if the binary of Y is > changed (maybe without prior notice) to link against, say openssl, then > suddenly the original linkage breaks the GPL. Even though the original > program (X) has not changed, and has not even been recompiled. Not exactly. If you link a GPLed program against a defined ABI that has both GPL-compatible and GPL-incompatible implementations, you have not violated the terms of the GPL; however, if you provide binaries, you must provide complete source code to *the exact binaries that you are distributing*, which under the GPL includes any libraries that are linked in. Thus, the violation comes specifically from distributing binaries of GPLed programs without distributing all the dependent libraries under the same terms. If you want to distribute the Heimdal libraries (Y) /without/ linking them against OpenSSL, and link GPL programs (X) against that, and distribute them together, then you're ok. You can even provide Heimdal libs that /are/ linked against OpenSSL, as an alternative; but if the packages you ship default to using the OpenSSL-enabled libraries, I would be wary that this would be seen as a violation by intent -- because effectively, you are intending to circumvent the license terms at that point, by trying to find a way to provide binaries without having to provide the complete source code under the terms of the GPL. > Come to think of it, can the GPL really say "It is Ok to distribute > package X, but not if the version of Y supplied is linked into openssl"? If you're asking if it can /legally/ say this, then the answer is yes. Copyright holders are allowed to put any restrictions they want to in their licenses, barring certain limits built into contract law in certain jurisdictions. > What if several compiled versions of Y have been made available, and > only one of these uses openssl? (lets assume that these different > versions can be used without recompiling, and that somehow the Depends > field allows this). [snip] > So under this interpretation, a user should be able to install only GPL > applications without their freedom being restricted by more restrictive > licenses. > However, if this was the case, shouldn't it still be OK simply to > provide two packages, one without the offending library, so the user has > the choice? See above. I believe this would be permissible, but that as a show of good faith your packages of GPLed programs should give preference to the GPL-compatible implementation of the ABI. You and I both know this is sub-optimal; if the OpenSSL-enabled version of the package didn't offer advantages, there'd be no reason to provide it. For this reason, I believe it's perfectly in keeping with the spirit of the GPL that distributors not be able to benefit from the use of such bait-and-switch techniques on libraries. > I think that the GPL is vague and prone to misintepretation. > For good example, see above issue ;-). No moreso than most legal documents, IMHO, and a good deal less so than many. ;) As a programmer/linguist, I find the GPL rather aesthetically pleasing. Maybe I wouldn't find it so pleasing if I were a lawyer. <shrug> :) > What would happen if a "Priority: required" package required OpenSSL? > Wouldn't this defeat the point of the restrictions set by the GPL? Since > any users would have to install openssl anyway? Neither the FSF nor Debian objects to the *use* of software licensed under the original BSD license. http://www.gnu.org/licenses/license-list.html#OriginalBSD Any end user who objects to using (as opposed to distributing or making changes to) programs just because their license includes the advertising clause is being overly pedantic, IMHO. I don't see much gain in being able to provide users with a system that consists exclusively of GPL-compatible software; the differences between GPL and BSD licenses are primarily of concern to developers and distributors, not users. Steve Langasek postmodern programmer
Attachment:
pgpHGMV4wi27R.pgp
Description: PGP signature