Documentation/process/license-rules.rst | 2 ++ scripts/checkpatch.pl | 9 +++++++++ 2 files changed, 11 insertions(+)
Sources already have SPDX-FileCopyrightText (~40 instances) and more
appear on the mailing list, so document that it is allowed. On the
other hand SPDX defines several other tags like SPDX-FileType, so add
checkpatch rule to narrow desired tags only to two of them - license and
copyright. That way no new tags would sneak in to the kernel unnoticed.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Other way would be to remove SPDX-FileCopyrightText from existing files
and disallow this, but one way or another we should be explicit about
it. Otherwise people will be sending more of these and each maintainer
would need to make their own call.
---
Documentation/process/license-rules.rst | 2 ++
scripts/checkpatch.pl | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
index 59a7832df7d0..8d7c0214f283 100644
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -66,6 +66,8 @@ License identifier syntax
'#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
identifier goes into the second line.
+ Identifier line can be followed by another one with SPDX-FileCopyrightText.
+
|
2. Style:
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 362a8d1cd327..98261ee97e2b 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3844,6 +3844,15 @@ sub process {
"Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
}
+# check for unused SPDX file tags
+ if ($rawline =~ /\bSPDX-.*:/ &&
+ $rawline !~ /\bSPDX-License-Identifier:/ &&
+ $rawline !~ /\bSPDX-FileCopyrightText:/) {
+ WARN("SPDX_LICENSE_TAG",
+ "Unsupported SPDX tag\n" . $herecurr);
+ }
+
+
# line length limit (with some exclusions)
#
# There are a few types of lines that may extend beyond $max_line_length:
--
2.51.0
On Wed, Jan 07, 2026 at 06:12:47PM +0100, Krzysztof Kozlowski wrote:
> Sources already have SPDX-FileCopyrightText (~40 instances) and more
> appear on the mailing list, so document that it is allowed. On the
> other hand SPDX defines several other tags like SPDX-FileType, so add
> checkpatch rule to narrow desired tags only to two of them - license and
> copyright. That way no new tags would sneak in to the kernel unnoticed.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Other way would be to remove SPDX-FileCopyrightText from existing files
> and disallow this, but one way or another we should be explicit about
> it. Otherwise people will be sending more of these and each maintainer
> would need to make their own call.
> ---
> Documentation/process/license-rules.rst | 2 ++
> scripts/checkpatch.pl | 9 +++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
> index 59a7832df7d0..8d7c0214f283 100644
> --- a/Documentation/process/license-rules.rst
> +++ b/Documentation/process/license-rules.rst
> @@ -66,6 +66,8 @@ License identifier syntax
> '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
> identifier goes into the second line.
As you are adding a copyright identifier, this sentence should probably
be:
For those scripts, the SPDX license identifier goes into the
second line.
> + Identifier line can be followed by another one with SPDX-FileCopyrightText.
How about:
"The license identifier line can then be followed by a
SPDX-FileCopyrightText line if desired."
> +
> |
>
> 2. Style:
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 362a8d1cd327..98261ee97e2b 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3844,6 +3844,15 @@ sub process {
> "Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
> }
>
> +# check for unused SPDX file tags
# check for unsupported SPDX file tags
thanks,
greg k-h
On Wed, Jan 07, 2026 at 07:52:31PM +0100, Greg KH wrote:
> On Wed, Jan 07, 2026 at 06:12:47PM +0100, Krzysztof Kozlowski wrote:
> > Sources already have SPDX-FileCopyrightText (~40 instances) and more
> > appear on the mailing list, so document that it is allowed. On the
> > other hand SPDX defines several other tags like SPDX-FileType, so add
> > checkpatch rule to narrow desired tags only to two of them - license and
> > copyright. That way no new tags would sneak in to the kernel unnoticed.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >
> > ---
> >
> > Other way would be to remove SPDX-FileCopyrightText from existing files
> > and disallow this, but one way or another we should be explicit about
> > it. Otherwise people will be sending more of these and each maintainer
> > would need to make their own call.
> > ---
> > Documentation/process/license-rules.rst | 2 ++
> > scripts/checkpatch.pl | 9 +++++++++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
> > index 59a7832df7d0..8d7c0214f283 100644
> > --- a/Documentation/process/license-rules.rst
> > +++ b/Documentation/process/license-rules.rst
> > @@ -66,6 +66,8 @@ License identifier syntax
> > '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
> > identifier goes into the second line.
>
> As you are adding a copyright identifier, this sentence should probably
> be:
> For those scripts, the SPDX license identifier goes into the
> second line.
>
> > + Identifier line can be followed by another one with SPDX-FileCopyrightText.
>
> How about:
>
> "The license identifier line can then be followed by a
> SPDX-FileCopyrightText line if desired."
I'd write "by one of multiple" instead of "by a" as multiple copyright
owners for the same file is common in the kernel.
> > +
> > |
> >
> > 2. Style:
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 362a8d1cd327..98261ee97e2b 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -3844,6 +3844,15 @@ sub process {
> > "Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
> > }
> >
> > +# check for unused SPDX file tags
>
> # check for unsupported SPDX file tags
--
Regards,
Laurent Pinchart
On Wed, 2026-01-07 at 18:12 +0100, Krzysztof Kozlowski wrote: > Sources already have SPDX-FileCopyrightText (~40 instances) and more > appear on the mailing list, so document that it is allowed. On the > other hand SPDX defines several other tags like SPDX-FileType, so add > checkpatch rule to narrow desired tags only to two of them - license and > copyright. That way no new tags would sneak in to the kernel unnoticed. I find no value in this tag. I think it should be discouraged. How is it different or more useful than a typical Copyright or © symbol ?
On Wed, Jan 07, 2026 at 10:40:11AM -0800, Joe Perches wrote: > On Wed, 2026-01-07 at 18:12 +0100, Krzysztof Kozlowski wrote: > > Sources already have SPDX-FileCopyrightText (~40 instances) and more > > appear on the mailing list, so document that it is allowed. On the > > other hand SPDX defines several other tags like SPDX-FileType, so add > > checkpatch rule to narrow desired tags only to two of them - license and > > copyright. That way no new tags would sneak in to the kernel unnoticed. > > I find no value in this tag. I think it should be discouraged. > > How is it different or more useful than a typical Copyright or © symbol ? It's easier to parse automatically and put into other places (like a software bill of materials). I don't like it all that much either, as really, it doesn't mean much (go talk to a lawyer for details), but it's already in our tree so we might as well document it... thanks, greg k-h
On Wed, 2026-01-07 at 20:35 +0100, Greg Kroah-Hartman wrote: > On Wed, Jan 07, 2026 at 10:40:11AM -0800, Joe Perches wrote: > > On Wed, 2026-01-07 at 18:12 +0100, Krzysztof Kozlowski wrote: > > > Sources already have SPDX-FileCopyrightText (~40 instances) and more > > > appear on the mailing list, so document that it is allowed. On the > > > other hand SPDX defines several other tags like SPDX-FileType, so add > > > checkpatch rule to narrow desired tags only to two of them - license and > > > copyright. That way no new tags would sneak in to the kernel unnoticed. > > > > I find no value in this tag. I think it should be discouraged. > > > > How is it different or more useful than a typical Copyright or © symbol ? > > It's easier to parse automatically and put into other places (like a > software bill of materials). > > I don't like it all that much either, as really, it doesn't mean much > (go talk to a lawyer for details), but it's already in our tree so we > might as well document it... Document it doesn't mean encourage it.
On 07/01/2026 20:38, Joe Perches wrote: > On Wed, 2026-01-07 at 20:35 +0100, Greg Kroah-Hartman wrote: >> On Wed, Jan 07, 2026 at 10:40:11AM -0800, Joe Perches wrote: >>> On Wed, 2026-01-07 at 18:12 +0100, Krzysztof Kozlowski wrote: >>>> Sources already have SPDX-FileCopyrightText (~40 instances) and more >>>> appear on the mailing list, so document that it is allowed. On the >>>> other hand SPDX defines several other tags like SPDX-FileType, so add >>>> checkpatch rule to narrow desired tags only to two of them - license and >>>> copyright. That way no new tags would sneak in to the kernel unnoticed. >>> >>> I find no value in this tag. I think it should be discouraged. >>> >>> How is it different or more useful than a typical Copyright or © symbol ? >> >> It's easier to parse automatically and put into other places (like a >> software bill of materials). >> >> I don't like it all that much either, as really, it doesn't mean much >> (go talk to a lawyer for details), but it's already in our tree so we >> might as well document it... > > Document it doesn't mean encourage it. Just like I explained in the changelog --- part, we should either accept it or mark it as incorrect in the checkpatch. I am fine with both (I don't have actual preference), but what I do not want is to have it in limbo/open stage, where everyone has to guess if it is desired/allowed. Lack of documented policy enforced by checkpatch means every maintainer upon seeing it will do the same as me - git grep and try to understand whether this is approved or not. Pretty waste of everyone's time. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.