| Summary: | dev-libs/libgcrypt: Missing license for OCB >=1.7.0 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kristian Fiskerstrand (RETIRED) <k_f> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | base-system, crypto+disabled, licenses, troy28217 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://lists.gnupg.org/pipermail/gcrypt-devel/2017-December/004338.html | ||
| See Also: |
https://bugs.debian.org/879984 https://bugs.gentoo.org/show_bug.cgi?id=698326 https://bugs.gentoo.org/show_bug.cgi?id=875542 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Kristian Fiskerstrand (RETIRED)
2017-12-15 17:17:48 UTC
Adding license team as CC for good measure. Updating URL to reflect upstream discussion (debian bug is in see also) 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. (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. (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). (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. (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) From https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ (February 2021) Rogaway wrote: I can confirm that I have abandoned all OCB patents and placed into the public domain all OCB-related IP of mine. While I have been telling people this for quite some time, I don't think I ever made a proper announcement to the CFRG or on the OCB webpage. Consider that done. I think this makes this bug obsolete. (In reply to Kristian Fiskerstrand (RETIRED) from comment #7) > (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 https://skibidi-toilet.io 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) I certify that I have given up on all of my OCB patents and released all of my OCB-related intellectual property into the public domain. Even though I've been telling people this for a while (In reply to Michael Patton from comment #9) > I certify that I have given up on all of my OCB patents and released all of > my OCB-related intellectual property into the public domain. > Even though I've been telling people this for a while Can you please elaborate on your rôle with libgcrypt and OCB patents? I don't see anything related to it in https://patents.justia.com/inventor/michael-patton. (In reply to Ulrich Müller from comment #10) > (In reply to Michael Patton from comment #9) > > I certify that I have given up on all of my OCB patents and released all of > > my OCB-related intellectual property into the public domain. > > Even though I've been telling people this for a while > > Can you please elaborate on your rôle with libgcrypt and OCB patents? I > don't see anything related to it in > https://patents.justia.com/inventor/michael-patton. I believe what he was writing was just citing what Philipp Rogaway said about OCB and patents: https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ (In reply to Hanno Böck from comment #11) > I believe what he was writing was just citing what Philipp Rogaway said > about OCB and patents: > https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ Rephrasing it instead of quoting it literally? That would be strange. Turns out that it's a spam bot, see the link spam in the quoted message in comment #9 (in the line starting with "AFAICS"). (In reply to Michael Patton from comment #9) > (In reply to Kristian Fiskerstrand (RETIRED) from comment #7) > > (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 https://snaptiktake.com 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) > I certify that I have given up on all of my OCB patents and released all of > my OCB-related intellectual property into the public domain. > Even though I've been telling people this for a while Agreed, bindist is not necessary in this case. |