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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.