diff mbox series

package/libkrb5: Bumb to 1.17

Message ID 20190930113931.9654-1-nerv@dawncrow.de
State Accepted
Headers show
Series package/libkrb5: Bumb to 1.17 | expand

Commit Message

André Zwing Sept. 30, 2019, 11:39 a.m. UTC
Signed-off-by: André Hentschel <nerv@dawncrow.de>
---
 package/libkrb5/libkrb5.hash | 4 ++--
 package/libkrb5/libkrb5.mk   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

Comments

Thomas Petazzoni Sept. 30, 2019, 8:18 p.m. UTC | #1
Hello,

On Mon, 30 Sep 2019 13:39:31 +0200
André Hentschel <nerv@dawncrow.de> wrote:

> Signed-off-by: André Hentschel <nerv@dawncrow.de>

Typo in the commit title: Bumb -> Bump. Also, you should have explained
in the commit log why the hash of the NOTICE file has changed, and what
are the changes. Indeed, this is important to check what license
changes happened. In this case, nothing was really relevant. I've
applied after extending the commit log.

However, I think this package license information may not be totally
correct, independently of this version bump. Indeed, our libkrb5.mk
says the license is MIT, but the NOTICE file shows a bunch of parts
under BSD-2-Clause for example.

Arnout, Yann, what do you think about this? It's one of those packages
with lots of code re-used from different projects, all under
MIT/BSD-2-Clause style licenses. I'd be interested to hear your opinion
on the matter.

Best regards,

Thomas
Yann E. MORIN Sept. 30, 2019, 8:28 p.m. UTC | #2
Thomas, All,

On 2019-09-30 22:18 +0200, Thomas Petazzoni spake thusly:
> On Mon, 30 Sep 2019 13:39:31 +0200
> André Hentschel <nerv@dawncrow.de> wrote:
> > Signed-off-by: André Hentschel <nerv@dawncrow.de>
[--SNIP--]
> However, I think this package license information may not be totally
> correct, independently of this version bump. Indeed, our libkrb5.mk
> says the license is MIT, but the NOTICE file shows a bunch of parts
> under BSD-2-Clause for example.
> 
> Arnout, Yann, what do you think about this? It's one of those packages
> with lots of code re-used from different projects, all under
> MIT/BSD-2-Clause style licenses. I'd be interested to hear your opinion
> on the matter.

Looking at the haorball the NOTICE file is, I would be tempted to just
state:
    LIBKRB5_LICENSE = Kerberos license

and be done with it. Let the user sort the mess on their side...

Regards,
Yann E. MORIN.
Arnout Vandecappelle Sept. 30, 2019, 10:13 p.m. UTC | #3
On 30/09/2019 22:28, Yann E. MORIN wrote:
> Thomas, All,
> 
> On 2019-09-30 22:18 +0200, Thomas Petazzoni spake thusly:
>> On Mon, 30 Sep 2019 13:39:31 +0200
>> André Hentschel <nerv@dawncrow.de> wrote:
>>> Signed-off-by: André Hentschel <nerv@dawncrow.de>
> [--SNIP--]
>> However, I think this package license information may not be totally
>> correct, independently of this version bump. Indeed, our libkrb5.mk
>> says the license is MIT, but the NOTICE file shows a bunch of parts
>> under BSD-2-Clause for example.
>>
>> Arnout, Yann, what do you think about this? It's one of those packages
>> with lots of code re-used from different projects, all under
>> MIT/BSD-2-Clause style licenses. I'd be interested to hear your opinion
>> on the matter.
> 
> Looking at the haorball the NOTICE file is, I would be tempted to just
> state:
>     LIBKRB5_LICENSE = Kerberos license
> 
> and be done with it. Let the user sort the mess on their side...

 IMO it's not *that* difficult to be complete. Licensecheck reports the
following (after pruning a bunch of irrelevant or wrong hits):

LIBKRB5_LICENSE = MIT, NTP, MIT-CMU, BSD-2-Clause, BSD-3-Clause, BSD-4-Clause, ISC


 BTW, for some reason licensecheck seems to identify MIT as "Expat licence"...

 Regards,
 Arnout
Yann E. MORIN Oct. 1, 2019, 3:33 p.m. UTC | #4
Arnout, All,

On 2019-10-01 00:13 +0200, Arnout Vandecappelle spake thusly:
> On 30/09/2019 22:28, Yann E. MORIN wrote:
> > Thomas, All,
> > 
> > On 2019-09-30 22:18 +0200, Thomas Petazzoni spake thusly:
> >> On Mon, 30 Sep 2019 13:39:31 +0200
> >> André Hentschel <nerv@dawncrow.de> wrote:
> >>> Signed-off-by: André Hentschel <nerv@dawncrow.de>
> > [--SNIP--]
> >> However, I think this package license information may not be totally
> >> correct, independently of this version bump. Indeed, our libkrb5.mk
> >> says the license is MIT, but the NOTICE file shows a bunch of parts
> >> under BSD-2-Clause for example.
> >>
> >> Arnout, Yann, what do you think about this? It's one of those packages
> >> with lots of code re-used from different projects, all under
> >> MIT/BSD-2-Clause style licenses. I'd be interested to hear your opinion
> >> on the matter.
> > 
> > Looking at the haorball the NOTICE file is, I would be tempted to just
> > state:
> >     LIBKRB5_LICENSE = Kerberos license
> > 
> > and be done with it. Let the user sort the mess on their side...
> 
>  IMO it's not *that* difficult to be complete. Licensecheck reports the
> following (after pruning a bunch of irrelevant or wrong hits):

But how exactly did you conclude those bits are irrelevant or wrong?
That's an issue I think, that we inject our own interpretation of the
licenses list and conclude of a resulting state.

I don't think that is correct, because some other people may or may not
have a different interpretation of irrelevance or wrongness.

> LIBKRB5_LICENSE = MIT, NTP, MIT-CMU, BSD-2-Clause, BSD-3-Clause, BSD-4-Clause, ISC
> 
>  BTW, for some reason licensecheck seems to identify MIT as "Expat licence"...

Which is all the more a reason not to trust its output.

As such, I'd just let the user do their own interpretation of this.

BTW, that prompted me to resurect a small patch of mine I've had stashed
for eons here (I'll do a proper submission later:)

    diff --git a/support/legal-info/README.header b/support/legal-info/README.header
    index d3bdf71bcf..ef8aff0c1a 100644
    --- a/support/legal-info/README.header
    +++ b/support/legal-info/README.header
    @@ -29,3 +29,7 @@ This material is composed of the following items.
      * The license text of the packages; they have been saved in the
      * licenses/
        subdirectory.
     
    +Note that the Buildroot developers provide no guarantee as to whether the
    +information contained in the material thus collected, is correct or
    +exhaustive, or both. It is your responsibility, as part of your compliance
    +process, to verify the correctness and exhaustivity of that information.

Regards,
Yann E. MORIN.
Arnout Vandecappelle Oct. 1, 2019, 3:41 p.m. UTC | #5
On 01/10/2019 17:33, Yann E. MORIN wrote:
> Arnout, All,
> 
> On 2019-10-01 00:13 +0200, Arnout Vandecappelle spake thusly:
>> On 30/09/2019 22:28, Yann E. MORIN wrote:
>>> Thomas, All,
>>>
>>> On 2019-09-30 22:18 +0200, Thomas Petazzoni spake thusly:
>>>> On Mon, 30 Sep 2019 13:39:31 +0200
>>>> André Hentschel <nerv@dawncrow.de> wrote:
>>>>> Signed-off-by: André Hentschel <nerv@dawncrow.de>
>>> [--SNIP--]
>>>> However, I think this package license information may not be totally
>>>> correct, independently of this version bump. Indeed, our libkrb5.mk
>>>> says the license is MIT, but the NOTICE file shows a bunch of parts
>>>> under BSD-2-Clause for example.
>>>>
>>>> Arnout, Yann, what do you think about this? It's one of those packages
>>>> with lots of code re-used from different projects, all under
>>>> MIT/BSD-2-Clause style licenses. I'd be interested to hear your opinion
>>>> on the matter.
>>>
>>> Looking at the haorball the NOTICE file is, I would be tempted to just
>>> state:
>>>     LIBKRB5_LICENSE = Kerberos license
>>>
>>> and be done with it. Let the user sort the mess on their side...
>>
>>  IMO it's not *that* difficult to be complete. Licensecheck reports the
>> following (after pruning a bunch of irrelevant or wrong hits):
> 
> But how exactly did you conclude those bits are irrelevant or wrong?
> That's an issue I think, that we inject our own interpretation of the
> licenses list and conclude of a resulting state.

 Because it's what we do for all other packages? All autotools packages have a
GPL config.guess script, but we never mention it. For many packages we don't
include documentation because it doesn't get built/installed. Etc.

 If we don't want to do that, we should remove _LICENSE entirely.

 Regards,
 Arnout

> 
> I don't think that is correct, because some other people may or may not
> have a different interpretation of irrelevance or wrongness.
> 
>> LIBKRB5_LICENSE = MIT, NTP, MIT-CMU, BSD-2-Clause, BSD-3-Clause, BSD-4-Clause, ISC
>>
>>  BTW, for some reason licensecheck seems to identify MIT as "Expat licence"...
> 
> Which is all the more a reason not to trust its output.
> 
> As such, I'd just let the user do their own interpretation of this.
> 
> BTW, that prompted me to resurect a small patch of mine I've had stashed
> for eons here (I'll do a proper submission later:)
> 
>     diff --git a/support/legal-info/README.header b/support/legal-info/README.header
>     index d3bdf71bcf..ef8aff0c1a 100644
>     --- a/support/legal-info/README.header
>     +++ b/support/legal-info/README.header
>     @@ -29,3 +29,7 @@ This material is composed of the following items.
>       * The license text of the packages; they have been saved in the
>       * licenses/
>         subdirectory.
>      
>     +Note that the Buildroot developers provide no guarantee as to whether the
>     +information contained in the material thus collected, is correct or
>     +exhaustive, or both. It is your responsibility, as part of your compliance
>     +process, to verify the correctness and exhaustivity of that information.
> 
> Regards,
> Yann E. MORIN.
>
Thomas Petazzoni Oct. 1, 2019, 3:44 p.m. UTC | #6
On Tue, 1 Oct 2019 17:41:36 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:

> > But how exactly did you conclude those bits are irrelevant or wrong?
> > That's an issue I think, that we inject our own interpretation of the
> > licenses list and conclude of a resulting state.  
> 
>  Because it's what we do for all other packages? All autotools packages have a
> GPL config.guess script, but we never mention it. For many packages we don't
> include documentation because it doesn't get built/installed. Etc.
> 
>  If we don't want to do that, we should remove _LICENSE entirely.

Yes, I agree we should do something reasonable. Striving for perfection
in this area is basically impossible.

Thomas
Yann E. MORIN Oct. 1, 2019, 5:45 p.m. UTC | #7
Arnout, All,

On 2019-10-01 17:41 +0200, Arnout Vandecappelle spake thusly:
> On 01/10/2019 17:33, Yann E. MORIN wrote:
> > On 2019-10-01 00:13 +0200, Arnout Vandecappelle spake thusly:
> >> On 30/09/2019 22:28, Yann E. MORIN wrote:
> >>>     LIBKRB5_LICENSE = Kerberos license
> >>> and be done with it. Let the user sort the mess on their side...
> >>  IMO it's not *that* difficult to be complete. Licensecheck reports the
> >> following (after pruning a bunch of irrelevant or wrong hits):
> > But how exactly did you conclude those bits are irrelevant or wrong?
> > That's an issue I think, that we inject our own interpretation of the
> > licenses list and conclude of a resulting state.
>  Because it's what we do for all other packages? All autotools packages have a
> GPL config.guess script, but we never mention it. For many packages we don't
> include documentation because it doesn't get built/installed. Etc.
> 
>  If we don't want to do that, we should remove _LICENSE entirely.

Sorry, but we should not be making any claim that _LICENSE variables are in
any way correct or exhaustive. In my opinion, they are set to the best of
our knowledge, but they are not any legal advice.

I do recognise that it should be safe to remove information from the build
files, from the docs, and the likes. It should also be safe to just list
the licenses explicitly listed in the package's own legal info (here,
the file named 'NOTICE', sometimes 'COPYING', or the likes), or in
individual source files.

People that want to make use of the output of 'legal-info' should
carefully review that information, and in case of any ambiguity, consult
with their own legal advisor.

Now, back to this libkrb5 license mess..

As a basis for this analysis (which is not legal advice), let's start
from the README file, which prominently states:

    Copyright (C) 1985-2019 by the Massachusetts Institute of Technology
    and its contributors.  All rights reserved.

    Please see the file named NOTICE for additional notices.

And thus, the NOTICE file contains a long list of various licenses. Some
are easily recognisable, other much less so.

For example, the first identified license looks like a BSD-2-Clause,
with copyright holders the Massachusetts Institute of Technology.

However, it is difficult to identify whether the following blurb is part
of the license text or not:

    Downloading of this software may constitute an export of cryptographic
    software from the United States of America that is subject to the
    United States Export Administration Regulations (EAR), 15 CFR 730-774.
    Additional laws or regulations may apply.  It is the responsibility of
    the person or entity contemplating export to comply with all
    applicable export laws and regulations, including obtaining any
    required license from the U.S. government.

    The U.S. government prohibits export of encryption source code to
    certain countries and individuals, including, but not limited to, the
    countries of Cuba, Iran, North Korea, Sudan, Syria, and residents and
    nationals of those countries.

So, if you happen to live in one of those countries, it would look like
you in fact need an additional license grant from the US government, that
the BSD-2-Clause listed above does not provide.

Now, a bit further down that file, we can see:

    Portions contributed by Matt Crawford "crawdad@fnal.gov" were work
    performed at Fermi National Accelerator Laboratory, which is
    operated by Universities Research Association, Inc., under contract
    DE-AC02-76CHO3000 with the U.S. Department of Energy.

This was part of a contract with the US government (DOE), so I suppose
that the contributions by Matt Crawford are thus in the Public Domain.

And then, what about the copyright claims for src/lib/crypto/builtin/aes,
which do not look like a license I could recognise (although it looks
like a simplified BSD-3-Clause, but I'm not so sure)?

And on and on...

So this is a typical case where the situation is hairy enough that we
should not try to interpret it, IMVHO, and let the user consult with
their legal counsel.

Regards,
Yann E. MORIN.
diff mbox series

Patch

diff --git a/package/libkrb5/libkrb5.hash b/package/libkrb5/libkrb5.hash
index 733c6c9d6f..aa7c3a3778 100644
--- a/package/libkrb5/libkrb5.hash
+++ b/package/libkrb5/libkrb5.hash
@@ -1,5 +1,5 @@ 
 # Locally calculated after checking pgp signature
-sha256	9f721e1fe593c219174740c71de514c7228a97d23eb7be7597b2ae14e487f027	krb5-1.16.2.tar.gz
+sha256	5a6e2284a53de5702d3dc2be3b9339c963f9b5397d3fbbc53beb249380a781f5	krb5-1.17.tar.gz
 
 # Hash for license file:
-sha256	58534f00ed877fd32936fcab094f49d399aeef7716393204d8028c4b89050c82	NOTICE
+sha256	5149ea464bde245388d313309539e142156d371788ae57bbd4feb223757f6da1	NOTICE
diff --git a/package/libkrb5/libkrb5.mk b/package/libkrb5/libkrb5.mk
index 56345416aa..7c199129a3 100644
--- a/package/libkrb5/libkrb5.mk
+++ b/package/libkrb5/libkrb5.mk
@@ -4,8 +4,8 @@ 
 #
 ################################################################################
 
-LIBKRB5_VERSION_MAJOR = 1.16
-LIBKRB5_VERSION = $(LIBKRB5_VERSION_MAJOR).2
+LIBKRB5_VERSION_MAJOR = 1.17
+LIBKRB5_VERSION = $(LIBKRB5_VERSION_MAJOR)
 LIBKRB5_SITE = https://web.mit.edu/kerberos/dist/krb5/$(LIBKRB5_VERSION_MAJOR)
 LIBKRB5_SOURCE = krb5-$(LIBKRB5_VERSION).tar.gz
 LIBKRB5_SUBDIR = src