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

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



On Wed, 2012-27-06 at 13:42 -0400, Mike O'Connor wrote:
> 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? 

The stuff on CPAN is source.  So it's not linked to anything.  It may
have instructions to link to something but OpenSSL has no legal
authority to stop that.

> > 
> > 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.

Define "derivative".  Until it's compiled, it's not.

> 
> 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.  

Tha *compiler*.  So it might be a problem for Debian except that Debian
is NOT using the string "OpenSSL".  It is using the lower-case version.
So there's no violation ... though IANAL.

IMO, if Debian is to do anything, it should first contact the "OpenSSL
Project" to see if there's a problem.  Harassing CPAN authors seems
premature to me.

> 
> stew
-- 
--gh



Reply to: