LGPL vs. OCB license

Werner Koch wk at gnupg.org
Fri Dec 15 19:40:59 CET 2017


On Fri, 15 Dec 2017 18:09, jan.kiszka at siemens.com said:

> This one excludes non-commercial use, hmm... too bad (with corporate hat
> on).

Not in my reading.  It excludes the use for military purposes.

> Legal departments are quick with "simple" obligations like "remove that
> file", and then you do the aforementioned package surgery which is what
> I want to reduce to zero for various good reasons, in standard distros
> packages or ideally already in upstream.

Right, for quite some time RedHat removed ECC frokm Libgcrypt.

> I'm not deep into the crypto design at all, but is there a way to
> exclude to usage of this implementation during runtime?

I can't see that OCB is used in Libgcrypt internally.  Thus by not using
it you should be fine.  In theory we could add a runtime switch to
disable it (using /etc/gcrypt/something) but whether this will be
sufficient is a different question.  I really can't decide that and in
particialr not for a US-only patent.

> libgcrypt will surely pop up in many license analysis tools as distros
> move to a version that now contains the OCB implementation with that
> patent reference. Having good technical answers how to deal with them is

OpenSSL also included OCB unconditionally.  Thus Libgcrypt should be the
smallest problem.

> what I searching for. The legal assessment will remain to the experts,
> but they need input from the engineering side as well.

Sure.  I doubt that debian-legal or this mailing list are the best place
for it.  However, feel free to discuss it here.


Shalom-Salam,

   Werner


p.s
I'll get you in contact with a guy whou should know more about it.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20171215/aa65d2f7/attachment.sig>


More information about the Gcrypt-devel mailing list