-=| Daniel Kahn Gillmor, Tue, Jun 23, 2009 at 02:52:06PM -0400 |=- > They don't all share syntax or bindings in identical ways. For > example, > retrieving a prime that is part of a DSA key from Crypt::OpenSSL::DSA > yields a binary string, while retrieving a prime component from > Crypt::OpenSSL::RSA yields a Crypt::OpenSSL::Bignum object. > > We also have multiple ways of (for example) generating and representing > an OpenSSL RSA key (Net::SSLeay::RSA_generate_key() and > Crypt::OpenSSL::RSA->generate_key()). And if my attempt to package > libopenssl-perl is successful, we'll have two independent bindings of > OpenSSL's BigNum support (the admittedly poorly-documented OpenSSL::BN > and Crypt::OpenSSL::Bignum). I hope you can convince upstream authors on an unified interface. I am not aware of any such attempt made, but I haven't searched the mailing list archives. > Licensing > --------- > > Debian sees OpenSSL licensing as explicitly incompatible with the GPL. > /usr/share/doc/libnet-ssleay-perl/copyright invokes the OpenSSL > licensing terms, but other OpenSSL bindings do not (they seem to usually > invoke the GPL | Artistic perl-standard dual-licensing agreement). openssl is available under two licenses: OpenSSL license and the SSLeay license. > Since they all link to OpenSSL, presumably we consider them to be > bound > by the OpenSSL terms as well. Does this mean that the GPL | Artistic > license for the modules actually collapses to the Artistic license from > debian's point of view? It appears to me too. > If so, should this be clarified in the > copyright files? Ftp-masters apparently don't have problem recognizing this, but explitit note will make the fact more obvious, which is always good for tricky legalese stuff. > Finally, i note that the OpenSSL license contains the following stanza: > > * 5. Products derived from this software may not be called "OpenSSL" > * nor may "OpenSSL" appear in their names without prior written > * permission of the OpenSSL Project. > > It's not clear to me whether any of the Crypt::OpenSSL::* modules have > actually received such permision from the OpenSSL project. First, SSLeay license has no such requirement. And since OpenSSL is available under both OpenSSL and SSLeay licenses, the requirements of the OpenSSL may be avoided. Yes, this becomes rather tricky: Artistic|GPL + OpenSSL|SSLeay ==> Artistic + SSLeay Second, I don't see a definition of what "a derived work" is and whether dynamic linking falls into that category. If not, there is no problem. Thanks for your efforts and sorry for not bringing many answers. -- dam
Attachment:
signature.asc
Description: Digital signature