On 12/29/06, Stephen Frost wrote:
> In the case above, exim4 *can* provide an exception because it's the
> *GPL* of *exim4* which is being violated by the advertising clause in
> the *OpenSSL* license. Which exim4 upstream has *done*, and which can
> be seen in their license (linked to previously in this thread).
My question is whom is going to sue whom? And if so would they win? And if
they win, will they win a crippling amount?
Will the folks at exim sue? Not likely, they make free software that is
DESIGNED to work with OpenSSL.
"Exim can be built to support encrypted SMTP connections... Before you can do
this, you must install the OpenSSL library, which Exim uses for this purpose."
Will they win if they sue? Not likely, there are probably lots of long legal
terms (like latches, estoppal) that can be used in a defense. You can't go and
build software specifically designed to use something, and over the course of
years dupe people into using it only to go, ta-da, busted for "additional GPL
restrictions".
And even if you succeed in this, you're not going to win big bucks. Perhaps
you can simply prevent people from using your software. Given that using your
software in the form you distribute it requires openssl, and you've sued
people for using openssl with it, it's likely *no one* is going to use your
software. And if you continue to dupe people into using your software and then
suing them, you'd run some legal risks yourself.
I mean, the theory of this legal case that debian people build seems terrible
to me!
Any case with this many highly unlikely AND clauses and such horrible outcomes
for everyone seems unlikely to happen AND be won AND result in significant harm.
If you don't like the advertising clause of openssl that is fine, avoid using
software that uses it etc etc. But I think the debian hype of various forms of
legal jeopardy goes a bit far, and does smell a bit FUDish.
Fun to follow though. And if there is a nice implementation of GNUTLS that
succeeds on the technical merits, no objection there either.
- August
