Re: Netatalk and OpenSSL licencing
On Tue, Aug 10, 2004 at 09:56:08AM +0200, Freek Dijkstra wrote:
> OK. I understand your argument, but I do not agree with it, and in fact
> would argue that this
parse error
> Since your opinion forms the majority, that is the end of that.
Well, the correct answers to legal issues are not, generally speaking,
determined by majority.
> For the record, this is my opinion:
> If indeed, if I am ONLY distributing netatalk binary, linked to OpenSSL, but
> no including OpenSSL. Then I have a program able to talk to OpenSSL is
> present. However, it can just as well work without it (as long as I don't
> use the features it requires OpenSSL for). So because of that, I'd say that
> this makes netatalk a standalone work.
I don't buy that you can circumvent the GPL simply by taking GPL code, pushing
it into a loadable module, making your proprietary code use it, and making
them two separate downloads: "I can't distribute these together; in order to
get around the GPL, you'll have to download and install these separately."
> If this nonetheless *due to the GPL* (as opposed to due the OpenSSL licence)
> "contaminates" the *WHOLE* OpenSSL package by forcing it to redistribute as
> GPL (note: be aware that I do not actually distribute any actual executable
> OpenSSL code! I may not distribute OpenSSL with it, or distribute it as
> source). Well, this would be a violation of rule #9 of the Debian Free
> Software Guidelines:
>
> 9. License Must Not Contaminate Other Software
> The license must not place restrictions on other software that is
> distributed along with the licensed software. For example, the
> license must not insist that all other programs distributed on the
> same medium must be free software.
The GPL is placing restrictions on software that it's combined with; the
restriction is unrelated to what it is "distributed along with". None of
this changes if OpenSSL is distributed on a CD, and the user downloads the
application.
> According to #3 of the OpenSSL licence, you must include the attribute to
> the OpenSSL Group. However, you do not to place whole or part of netatalk
> under the OpenSSL licence, because it does not talk about derivate works. Or
> to be precise: it does not explicitly define 'derivate works' as extremely
> broad, as the GPL does (but other licences like the LGPL do not). Simular to
The OpenSSL license's concept of a derivative work isn't the issue; it's the
GPL's conditions being violated. Regardless of anything the OpenSSL license
says or doesn't say, the GPL considers the binaries a derivative work. (Whether
or not that's a legally valid thing to do, the OpenSSL license's definitions
don't enter into it.)
The GPL says "any work derived from this must be available under these terms".
A binary linking against OpenSSL is not available under those terms, because a
portion (OpenSSL itself) has a requirement that if (for example) you reuse any
of the code, you must include a blurb in your ads, etc.
That is, I must be able to take any part of the final binary being used, grab
its source, and use it under the terms of the GPL. If I can't do so, something
is violating the GPL.
> I will have a look in incorporating GnuTLS, even though I personally belief
> that this whole thing (duplicating an effort, just because of a single line
> of attribution) is a serious indication that restrictions are overrated in
> our society. I knew that, but I'm currently disappointed that this also
> applies to open software. To me it is not in the spirit of "free" as
> mentioned in the Debian Social Contract. Oh well, I'll survive.
I don't think the advertising requirement is as minor as you make it out
to be. It seems that if you take out a banner ad for your software, and
say "Try DijkstraFtp, with SSL support!"--you've mentioned a use of an
OpenSSL feature, and now you have to make it an animated GIF so you have
space to say "This product includes software developed by the OpenSSL
Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)".
Even if that didn't trigger it, saying "(powered by OpenSSL!)" would.
Further, you have to have that URL--even if it's no longer valid (for
example, the website no longer accepts non-SSL connections and the only
valid URL for it is https).
#5 can become very silly, too; combine enough snippets and you can have
a work that has a requirement: 'Products derived from this software may
not be called "OpenSSL", "Apache", "Tigris", "PHP", or "Sudo".' (For an
example of why this class of restriction is annoying, you'd have trouble
reusing Apache code in "ApacheTrainer", software for training Apache helicopter
pilots.)
I'm not arguing that the license isn't free; just that the GPL isn't the
only license placing annoying restrictions here.
> Regards,
> Freek Dijkstra
> (being very disappointed in the GPL now)
Lots of people become disappointed in the GPL once they personally become
the one wasting time reimplementing stuff due to incompatibilities that
the GPL deliberately causes. I no longer use the GPL for my own work,
preferring the MIT license--do what you want, don't waste your time reinventing
the wheel.
I'm not going to change my opinion of what the GPL means because I don't like
it, though. :) Further, even if this didn't hold up in court, it would
still be bad practice to ignore the wishes of copyright holders; I hope there
aren't any packages in Debian with the rationale "the license says we can't
do this, but that's unenforcable, so we'll just ignore the author's wishes".
--
Glenn Maynard
Reply to: