On Sun, 17 Apr 2005, Junichi Uekawa wrote:
> This is the first  time for me to send you a patch; be gentle.
> the following patch allows for use of gcrypt.

Well, libgcrypt seems to be pretty rare out there - I certainly don't have 
it installed on my machine.

> libssl seems to have a restrictive licensing wrt GPL applications.

It does? I really don't read it that way. 

The openssl license is BSD+mention, but it only kicks in if you 
_redistribute_ it (and you're not allowed to market things as being 
openssl based without giving them credit, but that's another thing).

So yes, the openssl license is incompatible with the GPL in the sense that 
you cannot actually _mix_ the openssl source-code with the GPL 
source-code. But that's true of a lot of libraries, the normal system C 
library being just one common example.

The GPL makes explicit mention of the system libraries (which openssl
definitely is by now), so it's ok by the GPL . And I don't see how you'd
claim that the openssl license doesn't allow it. So it all looks ok by me.

That said, if somebody wants to abstract this out, and have a simple "sign 
with sha1" interface that can be used with both openssl and libgcrypt (or 
any other crypt license), then hey, go wild. Or merge the SHA1 code from 
the kernel, even, and make the project entirely self-sufficient.

But requiring libgcrypt seems silly. Especially as the libgcrypt 
interfaces are horribly ugly, much more so than the openssl ones - so even 
if you use libgcrypt, you don't actually want to use it directly, you want 
to have much nicer wrappers around it.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to