On Wed, Jun 27, 2012 at 12:52:28PM -0400, Guy Hulbert wrote: > On Wed, 2012-27-06 at 12:49 -0400, Daniel Kahn Gillmor wrote: > > On 06/27/2012 12:38 PM, Guy Hulbert wrote: > > > It's unenforcable if the modules in question do not incorporate any > > > OpenSSL code and are just an interface to the library. I think this is > > > probably the case. > > > > Eh? How is a binding to a library not a project that is "derived from" > > that library? I don't follow your explanation that the clause is > > unenforcable. What makes it unenforcable? > > Because if I write the code, I own it. So in the case of a perl module > I can call it anything I want unless there is a trademark involved (and, > i believe trademarking words is a perversion). > In this case *some* of the code was written by the authors of the perl code, but much of the source code comes directly from openssl. The perl module author is taking a lot of code from openssl, adding some of their own, them compiling that together into a new work. This is clearly a derrivative work. Look, for example at the source code to libcrypt-openssl-rsa-perl. In RSA.xs, these lines appear: #include <openssl/bio.h> #include <openssl/bn.h> #include <openssl/err.h> #include <openssl/md5.h> #include <openssl/objects.h> #include <openssl/pem.h> #include <openssl/rand.h> #include <openssl/ripemd.h> #include <openssl/rsa.h> #include <openssl/sha.h> #include <openssl/ssl.h> Those are instructions to the compiler to directly include source code from the openssl project. stew
Attachment:
signature.asc
Description: Digital signature