From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Brian Cain <quic_bcain@quicinc.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH 2/3] scripts: validate SPDX license choices
Date: Mon, 7 Oct 2024 17:49:14 +0100 [thread overview]
Message-ID: <ZwQRCi-orF8FXXsU@redhat.com> (raw)
In-Reply-To: <0ac9546e-2b0d-46f1-8c5c-fc75529aa682@quicinc.com>
On Mon, Oct 07, 2024 at 11:19:15AM -0500, Brian Cain wrote:
>
> On 10/7/2024 10:45 AM, Daniel P. Berrangé wrote:
> > We expect all new code to be contributed with the "GPL-2.0-or-later"
> > license tag. Divergance is permitted if the new file is derived from
> > pre-existing code under a different license, whether from elsewhere
> > in QEMU codebase, or outside.
> >
> > Issue a warning if the declared license is not "GPL-2.0-or-later",
> > and an error if the license is not one of the handful of the
> > expected licenses to prevent unintended proliferation.
> >
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> > scripts/checkpatch.pl | 66 +++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 66 insertions(+)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index cc266abdcd..cd1ed90f4c 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -1353,6 +1353,67 @@ sub checkfilename {
> > }
> > }
> > +sub checkspdx {
> > + my ($file, $expr) = @_;
> > +
> > + # Imported Linux headers probably have SPDX tags, but if they
> > + # don't we're not requiring contributors to fix this
> > + if ($file =~ m,include/standard-headers, ||
> > + $file =~ m,linux-headers,) {
> > + return;
> > + }
> > +
> > + my $origexpr = $expr;
> > +
> > + # Flatten sub-expressions
> > + $expr =~ s/\(|\)/ /g;
> > + $expr =~ s/OR|AND/ /g;
> > +
> > + # Merge WITH exceptions to the license
> > + $expr =~ s/\s+WITH\s+/-WITH-/g;
> > +
> > + # Cull more leading/trailing whitespace
> > + $expr =~ s/^\s*//g;
> > + $expr =~ s/\s*$//g;
> > +
> > + my @bits = split / +/, $expr;
> > +
> > + my $prefer = "GPL-2.0-or-later";
> > + my @valid = qw(
> > + LGPL-2.0-or-later
> > + LGPL-2.1-or-later
> > + GPL-2.0-only
> > + LGPL-2.0-only
> > + LGPL-2.0-only
> > + BSD-2-Clause
> > + BSD-3-Clause
> > + MIT
> > + );
> > +
> > + my $nonpreferred = 0;
> > + my @unknown = ();
> > + foreach my $bit (@bits) {
> > + if ($bit eq $prefer) {
> > + next;
> > + }
> > + if (grep /^$bit$/, @valid) {
> > + $nonpreferred = 1;
> > + } else {
> > + push @unknown, $bit;
> > + }
> > + }
> > + if (@unknown) {
> > + ERROR("Saw unacceptable licenses '" . join(',', @unknown) .
> > + "', valid choices for QEMU are:\n" . join("\n", $prefer, @valid));
> > + }
> > +
> > + if ($nonpreferred) {
> > + WARN("Saw acceptable license '$origexpr' but note '$prefer' is preferred " .
> > + "for new files unless the code is derived from a source with an" .
> > + "existed declared license that must be followed.");
>
> Is it not preferred to contribute code under the BSD-3-clause? Based on
> other items in the project, I was expecting we could make contributions for
> hexagon w/BSD. But those are exceptional cases and not to be followed in
> the general case?
I'm not saying people can't contribute under BSD, but if that is required,
a explanation of why is desired.
IMHO we don't want contributors choosing an non-GPL-2.0-or-later license
merely out of personal (or corporate) preferences.
We want GPL-2.0-or-later to be used for everything, unless there is a
compelling reason to diverge. The need to remain compliant with existing
code that has been incorporated is the most common & obvious reason for
this.
Other reasons likely exist - which could be explained in the commit
message, to aid reviewers who are likely to see the checkpatch warnings
about the unusal license choices.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2024-10-07 16:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 15:45 [PATCH 0/3] scripts: mandate use of SPDX-License-Identifier tags in new files Daniel P. Berrangé
2024-10-07 15:45 ` [PATCH 1/3] scripts: mandate that new files have SPDX-License-Identifier Daniel P. Berrangé
2024-10-07 16:12 ` Brian Cain
2024-10-07 20:13 ` Philippe Mathieu-Daudé
2024-10-07 15:45 ` [PATCH 2/3] scripts: validate SPDX license choices Daniel P. Berrangé
2024-10-07 16:19 ` Brian Cain
2024-10-07 16:49 ` Daniel P. Berrangé [this message]
2024-10-07 15:45 ` [PATCH 3/3] scripts: forbid use of arbitrary SPDX tags besides license identifiers Daniel P. Berrangé
2024-10-07 20:17 ` Philippe Mathieu-Daudé
2024-10-07 15:56 ` [PATCH 0/3] scripts: mandate use of SPDX-License-Identifier tags in new files Peter Maydell
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=ZwQRCi-orF8FXXsU@redhat.com \
--to=berrange@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quic_bcain@quicinc.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 NNTP newsgroup(s).