linux-kernel - Re: [patch 0/9] scripts/spdxcheck: Better statistics and exclude handling

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] [day] [month] [year] [list]

Date:   Mon, 23 May 2022 23:44:42 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     J Lovejoy <opensource@...ayne.com>, Max Mehl <max.mehl@...e.org>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@....de>, linux-spdx@...r.kernel.org
Subject: Re: [patch 0/9] scripts/spdxcheck: Better statistics and exclude
 handling

On Mon, May 23 2022 at 10:11, J. Lovejoy wrote:
> On 5/17/22 3:43 PM, Thomas Gleixner wrote:
> I think the discussion here is hitting upon the "inconvenience" of the 
> lack of black/white rules in the law (as to what is copyrightable) 
> versus the convenience of downstream recipients of code who want to be 
> sure they have proper rights (which mixes in the guidance/rules of 
> Reuse, tooling, etc.).

Correct.

> I think some rules in terms of files that are clearly not copyrightable 
> can be implemented in various tooling (hopefully, with the guidance of a 
> lawyer steeped in copyright law), and I agree that putting a license (by 
> way of an SPDX identifier or any other way for that matter) on such 
> files is neither a good use of time nor a good idea (from the 
> perspective of being inaccurate as to the need for a license and thus 
> sending the wrong impression). That being said, there will not be a way 
> to make clear cut rules for everything, without involving a judge. 
> Sorry! That's just how the law works (and we actually often don't want 
> black/white lines in the law, actually).
>
> I can see a policy of, "when it's not clear (as to copyrightability), 
> then add a license", though.

No argument here, but trivial things like an include which file includes
another include file are pretty clear IMO and we really should make our
mind up on those. Even a header file which contains a single function
declaration is questionable at best, but yes it's hard to put a hard
line on those.

Thanks,

        tglx