Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 641160 - dev-libs/libgcrypt: Missing license for OCB >=1.7.0
Summary: dev-libs/libgcrypt: Missing license for OCB >=1.7.0
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Kristian Fiskerstrand
URL: https://lists.gnupg.org/pipermail/gcr...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-15 17:17 UTC by Kristian Fiskerstrand
Modified: 2017-12-16 16:58 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kristian Fiskerstrand gentoo-dev Security 2017-12-15 17:17:48 UTC
libgcrypt since 1.7.0 includes cipher/cipher-ocb.c that has patent implications; copying from debian bug:

###
libgcrypt implements OCB, which is patented[0].  The author, Phil
Rogaway, provides three licenses.

* The first license applies to wholly open-source implementations that
  do not contain any closed-source components.
* The second license applies to non-military software implementations.
* The third license applies only to OpenSSL.

Only the first license applies here, since libgcrypt is not derived from
OpenSSL and the second license violates the DFSG.

Because libgcrypt is LGPL and may legally be linked to proprietary code,
it must contain a copy of the first patent license, as the patent
license imposes further restrictions on the way it can legally be used
and distributed.  As a consequence, these terms must be listed in the
copyright file.

Because Debian must avail itself of the first patent license, it is
therefore obligatory that libgcrypt20 not link against any proprietary
code directly or indirectly, and this should be prominently disclosed as
it restricts the text of the LGPL.

If it is not possible for practical purposes that libgcrypt not link to
proprietary software (say, because libgcrypt20 is linked into Xorg and
people might want to use a proprietary graphics driver), then OCB
support will need to be removed.

[0] http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm

###
Comment 1 Kristian Fiskerstrand gentoo-dev Security 2017-12-15 17:18:23 UTC
Adding license team as CC for good measure.
Comment 2 Kristian Fiskerstrand gentoo-dev Security 2017-12-15 17:21:54 UTC
Updating URL to reflect upstream discussion (debian bug is in see also)
Comment 3 Ulrich Müller gentoo-dev 2017-12-16 13:03:58 UTC
IMHO this doesn't constitute a problem for us as a source based distro. Also it shouldn't limit distribution of a binary dev-libs/libgcrypt (it is free software, therefore covered by their License 1).

I don't even see the need for a bindist restriction of non-free packages dynamically linked against libgcrypt:
- Copyright: libgcrypt is licensed under the LGPL, so there is no problem. 
- Patent: These packages (if dynamically linked) don't themselves include any patent-encumbered code, so I don't see how patent law could possibly prevent their distribution. The patent will only kick in when the program is actually run.

See also: https://bugs.gentoo.org/531540#c16

Disclaimer: IANAL, TINLA.
Comment 4 Kristian Fiskerstrand gentoo-dev Security 2017-12-16 13:13:55 UTC
(In reply to Ulrich Müller from comment #3)
> IMHO this doesn't constitute a problem for us as a source based distro. Also
> it shouldn't limit distribution of a binary dev-libs/libgcrypt (it is free
> software, therefore covered by their License 1).

Right, most likely we just need to add the OCB license to the package as an additional (non-free) license. I'm working with upstream to get a compile flag for the specific implementation so that we can make it a use flag matter only (default off)

libgcrypt is LGPL, and as such can be linked to by non-open source projects, so license 2 would cover the case more broadly, but that restricts military use so is still a non-free license.

> 
> I don't even see the need for a bindist restriction of non-free packages
> dynamically linked against libgcrypt:
> - Copyright: libgcrypt is licensed under the LGPL, so there is no problem. 
> - Patent: These packages (if dynamically linked) don't themselves include
> any patent-encumbered code, so I don't see how patent law could possibly
> prevent their distribution. The patent will only kick in when the program is
> actually run.

Agreed, bindist is not necessary in this case.
Comment 5 Ulrich Müller gentoo-dev 2017-12-16 16:24:18 UTC
(In reply to Kristian Fiskerstrand from comment #4)
> Right, most likely we just need to add the OCB license to the package as an
> additional (non-free) license.

This looks very wrong to me, because it would make libgcrypt non-free. 

AFAICS, http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf doesn't take away any of the Four Freedoms, so it would qualify for the MISC-FREE license group.

> I'm working with upstream to get a compile flag for the specific
> implementation so that we can make it a use flag matter only (default off)

> libgcrypt is LGPL, and as such can be linked to by non-open source projects,
> so license 2 would cover the case more broadly, but that restricts military
> use so is still a non-free license.

See above. IMHO, License 1 is sufficient here as it doesn't change the status of libgcrypt as free software (otherwise it couldn't be distributed under the LGPL, in the first place).
Comment 6 Ulrich Müller gentoo-dev 2017-12-16 16:31:34 UTC
(In reply to Ulrich Müller from comment #5)
> AFAICS, http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf doesn't take
> away any of the Four Freedoms, so it would qualify for the MISC-FREE license
> group.

To clarify, License 1 doesn't *grant* any of the four freedoms, so by itself it isn't a free software license. However, with something like LICENSE="LGPL-2.1+ ocb-license-1" a package will remain free software. Our ACCEPT_LICENSE logic doesn't have a mechanism for this case, but we could add a note to the ocb license that it is to be used only in combination with a free license.
Comment 7 Kristian Fiskerstrand gentoo-dev Security 2017-12-16 16:58:12 UTC
(In reply to Ulrich Müller from comment #6)

> 
> This looks very wrong to me, because it would make libgcrypt non-free. 

libgcrypt as it is, with the OCB implementation might very well be non-free as it doesn't follow the first freedom of "freedom to run the program for any purpose". Now, for license 1 this seems to be solved, (In reply to Ulrich Müller from comment #6)
> (In reply to Ulrich Müller from comment #5)
> > AFAICS, http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf doesn't take
> > away any of the Four Freedoms, so it would qualify for the MISC-FREE license
> > group.
> 
> To clarify, License 1 doesn't *grant* any of the four freedoms, so by itself
> it isn't a free software license. However, with something like
> LICENSE="LGPL-2.1+ ocb-license-1" a package will remain free software. Our
> ACCEPT_LICENSE logic doesn't have a mechanism for this case, but we could
> add a note to the ocb license that it is to be used only in combination with
> a free license.

It would effectively change the license of libgcrypt from LGPL to GPL though, as it could only be used by open source software. So any binary use of libgcrypt would be prohibited, aren't we just kicking the can in that case? license 2 is much broader, allowing this use as well, as long as it isn't for military use (but that can contaminate use somewhat further)