linux-kernel - Re: Licensing of include/linux/hash.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190123085000.fp7lhtjxcyzw3m4x@dumbo>
Date:   Wed, 23 Jan 2019 09:50:00 +0100
From:   Domenico Andreoli <domenico.andreoli@...ux.com>
To:     Ben Finney <bignose@...ian.org>
Cc:     Nadia Yvette Chambers <nyc@...omorphy.com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        919356@...s.debian.org, debian-legal@...ts.debian.org,
        linux-kernel@...r.kernel.org
Subject: Re: Licensing of include/linux/hash.h

Ben Finney <bignose@...ian.org> writes:
> Domenico Andreoli <cavok@...ian.org> writes:
> 
> >   the situation of dwarves-dfsg improved a lot over the weekend
> 
> That's good to hear. What is the event you're referring to? Can you give
> a URL to something that describes this change?

Upstream (in CC) reacted to my request of clarification and patches
have been applied upstream and on Salsa. See bug 919356 [0] (please
keep in CC).

> > the only knot left is now the license of hash.h
> >
> > This file is also present in the kernel [0] with an updated copyright
> > but still without license.
> 
> The file you show (in the Linux code base) seems likely to have an
> equivalent implementation under a different license, from some other
> code base.

This will require research and work unlikely to be done before Buster
release. Are we going to drop this package for now?

> > I received a private email from somebody in the kernel community who
> > already tried to contact Nadia in the past but did not get any reply.
> 
> Thank you also for contacting the Linux developers forum to ask
> <URL:https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1900588.html>.

(also in CC now)

> > I think that pushing it to non-free is formally the right thing but I
> > actually feel it's not the right thing.
> 
> To know that work (that file) is free software, we need a clear grant of
> some specific license, for that work.
> 
> If the work is not free, it would be incorrect to have the work in Debian.

Is it possible that for the kernel it is instead correct because it is,
as whole, covered by its COPYING?

> Alternatives, for complying with the Debian Free Software Guidelines with
> this package, include:
> 
> * Find a credible grant of license under some GPL-compatible free
>   license to that exact file. Document that explicit grant in the Debian
>   package. This demonstrates the work is DFSG-free.
> 
> * Convince ‘dwarves-dfsg’ upstream to replace that file with a different
>   implementation (I don't know whether such an implementation exists)
>   under a license compatible with the same version of GNU GPL. Document
>   that explicit grant in the Debian package. This demonstrates the
>   modified work is DFSG-free.

Arnaldo, what priority would you give to this task?

> 
> * Replace that file in Debian only, with a different implementation as
>   above. Document that explicit grant in the Debian package. This
>   demonstrates the modified Debian package is DFSG-free.
> 
> * Move the work to the ‘non-free’ area.
> 
> * Remove the work altogether.
> 
> Those are in descending order of (my recommended) preference.

Thanks,
Domenico

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919356

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)