[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#534338: OpenSSL bindings for Perl -- licensing questions

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.  


Attachment: signature.asc
Description: Digital signature

Reply to: