From: Thomas Gleixner <tglx@linutronix.de>
To: J Lovejoy <opensource@jilayne.com>, Max Mehl <max.mehl@fsfe.org>,
LKML <linux-kernel@vger.kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Christoph Hellwig <hch@lst.de>,
linux-spdx@vger.kernel.org
Subject: Re: [patch 0/9] scripts/spdxcheck: Better statistics and exclude handling
Date: Mon, 23 May 2022 23:44:42 +0200 [thread overview]
Message-ID: <878rqr2ab9.ffs@tglx> (raw)
In-Reply-To: <97d8beb2-db33-1e50-eadb-6ac8d650f044@jilayne.com>
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
prev parent reply other threads:[~2022-05-23 21:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 10:27 [patch 0/9] scripts/spdxcheck: Better statistics and exclude handling Thomas Gleixner
2022-05-16 10:27 ` [patch 1/9] scripts/spdxcheck: Add percentage to statistics Thomas Gleixner
2022-05-16 10:27 ` [patch 2/9] scripts/spdxcheck: Add directory statistics Thomas Gleixner
2022-05-16 10:27 ` [patch 3/9] scripts/spdxcheck: Add [sub]directory statistics Thomas Gleixner
2022-05-16 10:27 ` [patch 4/9] scripts/spdxcheck: Add option to display files without SPDX Thomas Gleixner
2022-05-16 10:27 ` [patch 5/9] scripts/spdxcheck: Put excluded files and directories into a separate file Thomas Gleixner
2022-05-16 10:27 ` [patch 6/9] scripts/spdxcheck: Exclude config directories Thomas Gleixner
2022-05-16 10:27 ` [patch 7/9] scripts/spdxcheck: Exclude MAINTAINERS/CREDITS Thomas Gleixner
2022-05-16 10:27 ` [patch 8/9] scripts/spdxcheck: Exclude dot files Thomas Gleixner
2022-05-16 14:22 ` Miguel Ojeda
2022-05-16 18:43 ` Thomas Gleixner
2022-05-18 13:36 ` Greg Kroah-Hartman
2022-05-16 10:27 ` [patch 9/9] scripts/spdxcheck: Exclude top-level README Thomas Gleixner
2022-05-16 13:14 ` [patch 0/9] scripts/spdxcheck: Better statistics and exclude handling Max Mehl
2022-05-16 18:52 ` Thomas Gleixner
2022-05-16 18:59 ` Thomas Gleixner
2022-05-17 8:25 ` Max Mehl
2022-05-17 21:43 ` Thomas Gleixner
2022-05-23 16:11 ` J Lovejoy
2022-05-23 21:44 ` Thomas Gleixner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rqr2ab9.ffs@tglx \
--to=tglx@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spdx@vger.kernel.org \
--cc=max.mehl@fsfe.org \
--cc=opensource@jilayne.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).