[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <878rqr2ab9.ffs@tglx>
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
Powered by blists - more mailing lists