Re: Replacement for GMP: Update
Einar,
Summary: I finally settled on modifying OpenSSL, since that would be the easiest to work with under GHC's hood (plain C code, not C++). I have to:
Does this cause license problems?
I think OpenSSL license had the advertising clause which means problems if Haskell programs want to link against GPLed libraries too.
The relevant portion of the OpenSSL license (reproduced in all source code and documentation) is: * The licence and distribution terms for any publically available version or * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.] (NOTE: this section is actually from the original SSLeay (1995-1998) license, but applies because OpenSSL is distributed under a dual license.) Otherwise the OpenSSL license is a BSD-style license that gives the authors credit (BSD2 and BSD3 do not require names in all the source code and documentation, only the distribution). The copying restriction means that I cannot simply take the BN library out of the OpenSSL distribution and put that code under the GHC license; it does not mean that I cannot distribute the OpenSSL code (still under the OpenSSL license) along with GHC code. For developers (commercial or open source), the OpenSSL license only mentions redistribution of the OpenSSL code in binary form (paragraph 2). In this context "binary form" means the complete program binary, not partial binary as with statically linking to a library, so developers of GHC programs would *not* have to include the whole OpenSSL&SSLeay license in their source code. Paragraph 6 of the OpenSSL (1998-2005) license states that: * 6. Redistributions of any form whatsoever must retain the following * acknowledgment: * "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit (http://www.openssl.org/)". All developers would have to do is include the acknowledgment stated above. On the other hand, the OpenSSL FAQ at <http://www.openssl.org/support/ faq.html#LEGAL2> mentions that some "GPL" programs do not allow binary combination (static linking) or interoperation (dynamic linking) with OpenSSL. Honestly I have not seen any "GPL" licenses like this. The GNU GPL version 2, at <http://www.gnu.org/licenses/ gpl.html>, does not mention OpenSSL, nor does version 1, nor does the GNU LGPL, at http://www.gnu.org/licenses/lgpl.html. In any case, I think it would be more of a restriction to someone *using* the OpenSSL program, not a developer. Best regards, Peter P.S. On a related note, OpenSSL's BN library does not contain any patented algorithms.
On 10.08 11:16, Peter Tanski wrote:
Paragraph 6 of the OpenSSL (1998-2005) license states that:
* 6. Redistributions of any form whatsoever must retain the following * acknowledgment: * "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit (http://www.openssl.org/)".
All developers would have to do is include the acknowledgment stated above.
I think this is not bad for specific applications, but forcing this upon all code compiled by GHC would be bad. I think the compiler should not link applications by default to things that force license related things. I think this is one reason GMP is being replaced. ps. personally I don't think the advertising clause is bad, but I think it is bad to force it on other users. - Einar Karttunen
Einar,
* "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit (http://www.openssl.org/)".
All developers would have to do is include the acknowledgment stated above.
I think this is not bad for specific applications, but forcing this upon all code compiled by GHC would be bad. I think the compiler should not link applications by default to things that force license related things.
I think this is one reason GMP is being replaced.
ps. personally I don't think the advertising clause is bad, but I think it is bad to force it on other users.
You may be right. The licensing problem with GHC, as I understood it, is summed up at <http://hackage.haskell.org/trac/ghc/wiki/ ReplacingGMPNotes>. LGPL is very restrictive. As I have been working on separating BN out of the main OpenSSL distribution, renaming symbols and generally reforming it into a custom, stand-alone library for GHC I could take it one step further and implement it from scratch as a GHC library. Implementing the BN library from scratch may take some time but I will give it a shot and see if I can't get better benchmarks. The downside is that I would have more incentive to remove some Cryptography-based cruft, such as BN_nnmod, BN_mod_add, BN_mod_sub and the BN-random routines, as these are unnecessary for Prelude and GHC. Best regards, Peter
Einar Karttunen wrote:
On 10.08 11:16, Peter Tanski wrote:
Paragraph 6 of the OpenSSL (1998-2005) license states that:
* 6. Redistributions of any form whatsoever must retain the following * acknowledgment: * "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit (http://www.openssl.org/)".
All developers would have to do is include the acknowledgment stated above.
I think this is not bad for specific applications, but forcing this upon all code compiled by GHC would be bad. I think the compiler should not link applications by default to things that force license related things.
Most packages (including the base package) already force you to do license-related things when you distribute binaries: - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. The OpenSSL license is no worse in this respect. Cheers, Simon
* Peter Tanski:
On the other hand, the OpenSSL FAQ at <http://www.openssl.org/support/ faq.html#LEGAL2> mentions that some "GPL" programs do not allow binary combination (static linking) or interoperation (dynamic linking) with OpenSSL. Honestly I have not seen any "GPL" licenses like this. The GNU GPL version 2, at <http://www.gnu.org/licenses/ gpl.html>, does not mention OpenSSL, nor does version 1, nor does the GNU LGPL, at http://www.gnu.org/licenses/lgpl.html.
This is the offending part: * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * "This product includes cryptographic software written by * Eric Young (eay@cryptsoft.com)" * The word 'cryptographic' can be left out if the rouines from the library * being used are not cryptographic related :-). It's generally believed that this is a further restriction in the sense of section 6 of the GPL (version 2).
In any case, I think it would be more of a restriction to someone *using* the OpenSSL program, not a developer.
It's a problem for a developer who wants to use a GPLed library written by someone else, too.
Florian,
This is the offending part:
* 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * "This product includes cryptographic software written by * Eric Young (eay@cryptsoft.com)" * The word 'cryptographic' can be left out if the rouines from the library * being used are not cryptographic related :-).
It's generally believed that this is a further restriction in the sense of section 6 of the GPL (version 2).
In any case, I think it would be more of a restriction to someone *using* the OpenSSL program, not a developer.
It's a problem for a developer who wants to use a GPLed library written by someone else, too.
Quite right; my mistake: under the OpenSSL license a developer cannot mention features of the software in advertising materials, so the license grant of the GPL-OpenSSL program to the developer is void. The reason I mentioned "users" only was that in the particular problem we have here GHC does not use any other GPL programs (I think I am correct--readline is the unix version, not the GPL version, correct?) so until the developer compiles a Haskell program with GHC (with OpenSSL) *and* that program uses a GPL program, the Haskell developer is still able transfer a valid license to users. The way the OpenSSL FAQ stated the problem, the implication was that there was specific mention of OpenSSL in a GPL license. The advertising requirement in the OpenSSL license would certainly constitute a "further restriction" under GPLv2 section 6; the strange implication is that the "no further restriction" clause is so broad the same clause (verbatim) in section 10 of the LGPL means the GPL license is incompatible with the terms of the LGPL! It's all very touchy. Best regards, Peter
* Peter Tanski:
Quite right; my mistake: under the OpenSSL license a developer cannot mention features of the software in advertising materials, so the license grant of the GPL-OpenSSL program to the developer is void. The reason I mentioned "users" only was that in the particular problem we have here GHC does not use any other GPL programs (I think I am correct--readline is the unix version, not the GPL version, correct?)
On most systems, readline is GPLed. There is a non-copyleft reimplementation somewhere, but I don't think it's widely used.
The advertising requirement in the OpenSSL license would certainly constitute a "further restriction" under GPLv2 section 6; the strange implication is that the "no further restriction" clause is so broad
It has to be very broad, otherwise developers could bypass the copyleft concept.
the same clause (verbatim) in section 10 of the LGPL means the GPL license is incompatible with the terms of the LGPL!
The LGPL permits relicensing of covered works under the GPL. Without that provision, it would indeed be incompatible with the GPL.
Florian:
On most systems, readline is GPLed. There is a non-copyleft reimplementation somewhere, but I don't think it's widely used.
The non-copyleft implementation is an upgrade from BSD's lineedit, called libedit http://www.thrysoee.dk/editline/. Apple's OS X includes it as a version of libreadline by a adding "/usr/lib/ libreadline.dylib" as a symbolic link to libedit.dylib. (I had forgotten about this because I have a version of Darwin Ports's libreadline I had installed so I could build GHC on OS 10.4: libedit does not fully implement libreadline's API so GHC requires libreadline). That GHC includes libreadline is not a problem for developers compiling programs using GHC because libreadline is used for GHC's interactive bytecode interpreter, GHCi, which is part of the compiler system but is not linked into the RTS of compiled programs. (This might be a problem with GHC's BSD license; I don't know.) Clearly the best solution would be to write to the FSF. The whole purpose of licensing GHC as BSD3 is to promote the broad use of Haskell as a programming language and developer involvement in the support, maintenance and research of Haskell and the GHC compiler. Those goals realistically require commercial developer support, otherwise small company or individual developers who lack the market recognition to sell software as a service could not write applications in Haskell and compile them with GHC. There are a few companies that do profitably sell Haskell as a service, notably Galois Connections, Aetion Technologies, Bluespec, Erlang Training and Consulting and OM Consulting.
the "no further restriction" clause is so broad
It has to be very broad, otherwise developers could bypass the copyleft concept.
True.
the same clause (verbatim) in section 10 of the LGPL means the GPL license is incompatible with the terms of the LGPL!
The LGPL permits relicensing of covered works under the GPL. Without that provision, it would indeed be incompatible with the GPL.
Are you referring to section 3 of the LGPL? The drafters should have referenced section 10 there to avoid confusion: section 3 and section 10 are clearly conflicting provisions with the only indicator of precedence being the order (section 3 comes before 10). I should note that this would not be a problem for licenses assigned directly by the FSF since they could refer to other documentation that would clarify the discrepancy. It might be a problem for an individual programmer who simply adopted the LGPL license and then had to enforce it. Best regards, Peter
Florian Weimer wrote:
This is the offending part:
* 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * "This product includes cryptographic software written by * Eric Young (eay@cryptsoft.com)" * The word 'cryptographic' can be left out if the rouines from the library * being used are not cryptographic related :-).
I would find this a real problem. Not because I wouldn't gladly acknowledge contributions in the text of the license to be distributed with the binary, or in the Help->About dialog box in the program, but because I wouldn't want to have to list contributions in "all advertising materials" eg an advertisement for one's program in a magazine etc - it would just make the product look amateurish as well as giving undue importance to just one of the many people whose work it was making use of. Also, what if your company made a T-shirt with a character from a computer game you're developing using Haskell - such legal smallprint would totally spoil the effect... ;-) Therefore I'd recommend that licenses for code used by GHC runtime should be either BSD or public domain. If the FFI was used for bignum then (talking about Windows OS for the moment) the bignum implementation could just be supplied as a C DLL, perhaps even several different C DLL's for people to choose which one they wanted to distribute with their program based on speed vs licencing issues. Eg if GMP was in a DLL then it would be sufficient to just supply gmp.dll + the gmp LGPL as two files along with the app binary and licensing issues would disappear afaiu. Another advantage of this direction would be that any slowness in the FFI would have to be ironed out, leading to a faster FFI which would be good for other things too eg matrix libs, graphics libs etc. Finally, separating bignum out of GHC runtime would make GHC runtime leaner therefore (hopefully)easier to maintain. Of course this depends on whether or not an FFI implementation of bignum would be fast enough compared to directly coding it in the runtime. (If you choose the DLL method I'd recommend incorporating the GHC version number into the name of the DLL to avoid DLL conflicts eg ghc-6.4.2 would use gmp-6.4.2.dll etc) Anyway good luck with whatever way you choose, Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com
Brian,
Therefore I'd recommend that licenses for code used by GHC runtime should be either BSD or public domain.
I agree. I was working on a rewrite of OpenSSL's BN from scratch-- maybe a rewrite of GMP would be better--but that is a huge undertaking for no other reason than these are big, complex projects. I will have to test Crypto++ and Botan to see if they are comparable in a Haskell context (both are written in C++; Crypto++ is essentially public domain while Botan has a BSD2 license--reproduce copyright in distributions of binary and source code). I will have to write least-common-multiple, bitwise operators and conversions to and from floating point representations.
If the FFI was used for bignum then (talking about Windows OS for the moment) the bignum implementation could just be supplied as a C DLL, perhaps even several different C DLL's for people to choose which one they wanted to distribute with their program based on speed vs licencing issues. Eg if GMP was in a DLL then it would be sufficient to just supply gmp.dll + the gmp LGPL as two files along with the app binary and licensing issues would disappear afaiu. Another advantage of this direction would be that any slowness in the FFI would have to be ironed out, leading to a faster FFI which would be good for other things too eg matrix libs, graphics libs etc. Finally, separating bignum out of GHC runtime would make GHC runtime leaner therefore (hopefully)easier to maintain.
I am testing two versions of GMP against the current internal version: one using FFI and another with the ForeignPtrs written in C--. If either is comparable to the internal version that is definitely a preferable solution for flexibility. I have to be very picky, though: Simon Marlow, Simon Peyton-Jones and the rest of the GHC Team are primarily interested in performance and the integrity of the RTS (no one would be happy if the RTS broke for bad FFI calls). Thanks for the encouragement. Best regards, Peter Tanski
On Fri, 2006-08-11 at 21:08 +0100, Brian Hulley wrote:
Florian Weimer wrote:
This is the offending part:
* 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * "This product includes cryptographic software written by * Eric Young (eay@cryptsoft.com)" * The word 'cryptographic' can be left out if the rouines from the library * being used are not cryptographic related :-).
Also, what if your company made a T-shirt with a character from a computer game you're developing using Haskell - such legal smallprint would totally spoil the effect... ;-)
Does that T-shirt mention the OpenSSL library? -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
participants (6)
-
Brian Hulley -
Einar Karttunen -
Florian Weimer -
Peter Tanski -
Simon Marlow -
skaller