public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Max Mehl <max.mehl@fsfe.org>
To: LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
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: Tue, 17 May 2022 10:25:30 +0200	[thread overview]
Message-ID: <1652775347.3cr9dmk5qv.2220@fsfe.org> (raw)
In-Reply-To: <87wnelpam3.ffs@tglx>

~ Thomas Gleixner [2022-05-16 20:59 +0200]:
> On Mon, May 16 2022 at 20:52, Thomas Gleixner wrote:
>>> Unfortunately, excluding files (i.e. not adding machine-readable
>>> license/copyright information to it) would also block reaching full
>>> compliance with the REUSE best practices. Have you considered making
>>> them available under GPL-2.0-only or a license similar to public domain
>>> [^2]?
>>
>> The LICENSE directory is already handled by spdxcheck as the license
>> information is read from there. And no, we cannot add a GPL-2.0-only
>> identifier to all of the files under the LICENSE directory for obvious
>> reasons.

Absolutely. REUSE obviously also ignores this directory, as well as
e.g. zero-length files, symlinks, submodules, or .git directory.

> There is also an argument to be made whether we really need to have SPDX
> identifiers on trivial files:
> 
> #include <someheader.h>
> <EOF>
> 
> Such files are not copyrightable by any means. So what's the value of
> doubling the line count to add an SPDX identifier? Just to make nice
> statistics?

We agree that such files are not copyrightable. But where is the
threshold? Lines of code? Creativity? Number of used functions? And how
to embed this threshold in tooling? So instead of fuzzy exclusion of
such files in tools like spdxcheck or REUSE, it makes sense to treat
them as every other file with the cost of adding two comment lines.

This clear-cut rule eases maintaining and growing the effort you and
others did because developers would know exactly what to add to a new
file (license + copyright) without requiring looking up the thresholds
or a manual review by maintainers who can interpret them.

Best,
Max

-- 
Max Mehl - Programme Manager -- Free Software Foundation Europe
Contact and information: https://fsfe.org/about/mehl -- @mxmehl
The FSFE is a charity that empowers users to control technology

  reply	other threads:[~2022-05-17  8:25 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 [this message]
2022-05-17 21:43         ` Thomas Gleixner
2022-05-23 16:11           ` J Lovejoy
2022-05-23 21:44             ` Thomas Gleixner

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=1652775347.3cr9dmk5qv.2220@fsfe.org \
    --to=max.mehl@fsfe.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spdx@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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