Gunnar Wolf wrote: > Stefan de Konink dijo [Sat, Nov 29, 2008 at 10:34:18PM +0100]: >>> This is completely expectable, as Cherokee now depends on OpenSSL for >>> criptography. Now, in human-speak, what is the problem with this? >>> Basically, that the OpenSSL and the GPL licenses are not mutually >>> compatible [1] (basically, the OpenSSL license includes an advertising >>> clause, similar to the four-clause BSD license), and GPLed projects >>> using OpenSSL must add an exception to their licensing terms. >> So a lot of @#$&( was pasted about not being compatible, why is not >> pasted *what* is not compatible? > > Please take a look at the links I gave, it is spelt out quite > easily. What happens is well-known - The GPL does not allow "any > aditional conditions" to be imposed over a GPLed project, but OpenSSL > requires all projects to include a notice that they are linking > against OpenSSL. This is often done just by the fact of linking, as > OpenSSL includes that notice (if I am not mistaken). But it _is_ an > extra restriction, which makes both licenses (although both free) > mutually incompatible.
I read them; and it seems not even OpenSSH is writing every startup: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)" So basically if the readme stated we use OpenSSL that would be enough to allow linking to OpenSSL headers right? "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." Clearly is talking about distribution of sourcecode. Not about executables or linking. It merely gives away the right to modify code that uses OpenSSL. >>> Just... As an extra word: I know many people view Debian as the >>> licensing zealots. In some sense, we are... But anyway, this is >>> something not only said by us. The link I sent comes from a Gnome >>> developer; I found other links detailing this situation at Wikipedia >>> [2], wget [3], and even OpenSSL itself [4]. >> If it was my own software I would totally not care if it was not in >> Debian anymore, and only available for persons that wanted my >> software. So eventually because of the non-sense involved would >> switch from Debian anyway ;) > > The good thing here is that there are some people less eager to get > angry ;-) Álvaro has already told me he will get this exception in as > soon as possible. And, yes, not being able to be included in Debian is > always a possibility, although it _does_ give a good exposure to the > project. But if I understand it right, Debian is *now* not shipping Cherokee because of this non-sence? So why is Debian angry in the first place? I guess, like ffmpeg, Debian could also have disabled crypto. Now that would have given an interesting situation. >>> This is a minor change, but please treat it with high priority - It >>> basically means Cherokee, as it is now, is not legally distributable >>> when compiled with SSL support. >> So the above statement applies already :) Maybe a read PR thing >> would be: to put on /. Cherokee doesn't care about Debian's >> copyright policy, and switches to the fastest open source >> implementation of SSL. And put some nice benchmarks of the latest >> release with it. > > Cherokee would not be the first project in this situation. And over > the years, many projects have included the relevant lines. It is not > Debian's copyright policy - it is Debian's stubornness not to do > anything illegal :) > > Of course Debian includes and uses OpenSSL. And yes, I agree with you, > there is no point in linking against libgnutls if this implementation > is as free as GNU's (even with this small, but easily fixable, > problem). Please comment at my first issue. I don't see OpenSSH doing this, it is included in Debian, what makes *that* it more legal than Cherokee? Stefan _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
