On Thu, Dec 16, 2021 at 1:15 PM Mauro Carvalho Chehab
<mchehab@xxxxxxxxxx> wrote:
>
> Em Thu, 16 Dec 2021 13:05:10 +0100
> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> escreveu:
>
> > On Thu, Dec 16, 2021 at 12:23:11PM +0100, Mauro Carvalho Chehab wrote:
> > > Em Thu, 16 Dec 2021 11:31:32 +0100
> > > Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> escreveu:
> > >
> > > > Commit 8d395ce6f04b ("media: dvb-core: Convert to SPDX identifier") and
> > > > commit e67219b0496b ("media: b2c2: flexcop: Convert to SPDX identifier")
> > > > introduce the SPDX-License expression LGPL-2.1-or-later for some files.
> > > >
> > > > The command ./scripts/spdxcheck.py warns:
> > > >
> > > > drivers/media/dvb-core/dmxdev.c: 1:28 Invalid License ID: LGPL-2.1-or-later
> > > > drivers/media/dvb-core/dvb_demux.c: 1:28 Invalid License ID: LGPL-2.1-or-later
> > > > drivers/media/dvb-core/dvbdev.c: 1:28 Invalid License ID: LGPL-2.1-or-later
> > > > drivers/media/common/b2c2/flexcop.c: 1:28 Invalid License ID: LGPL-2.1-or-later
> > > >
> > > > The preferred SPDX expression for LGPL-2.1 or any later version is with
> > > > the more generic "+"-extension for "any later version", so: LGPL-2.1+
> > > >
> > > > This makes spdxcheck happy again.
> > >
> > > It doesn't sound right to apply such patch.
> > >
> > > See, the latest SPDX version uses LGPL-2.1-or-later:
> > >
> > > https://spdx.org/licenses/LGPL-2.1-or-later.html
> > >
> > > And it deprecated LGPL-2.1+:
> > >
> > > https://spdx.org/licenses/LGPL-2.1+.html
> > >
> > > So, those files are perfectly fine with regards to SPDX, and are
> > > adherent to its latest specs. We do need the latest specs on media,
> > > as our documentation is under GFDL-1.1-no-invariants-or-later, which
> > > only exists on newer SPDX versions.
> > >
> > > So, the right thing to do here seems to fix spdxcheck.py, letting it
> > > either allow both variants (as we probably don't want to replace it
> > > everywhere) or to emit a warning if the deprecated ones are used.
> >
> > No, we are not going to add a "warning" for older SPDX versions like
> > that, otherwise the majority of the kernel will start spitting out
> > warnings.
> >
> > Let's worry about actually fixing all of the files that do NOT have SPDX
> > tags before even considering to move to a newer version of the spec. We
> > started this work before the FSF made the crazy change to their tags,
> > let's not worry about any deprecated issues at the moment.
>
> Yeah, agreed.
>
Sorry, I first read the section Deprecated License Identifiers on
https://spdx.org/licenses/, where it stated:
Release 2.0 of the SPDX Specification introduced License Expressions
that supports the ability to identify common variations of
SPDX-identified licenses without the need to define each potential
variation as a distinct license on the SPDX License List. This new
syntax supports the ability to declare an SPDX-identified license
exception using the "WITH" operator (e.g. GPL-2.0-or-later WITH
Autoconf-exception-2.0), as well as the ability to use a simple "+"
operator after a license short identifier to indicate "or later
version". SPDX has defined a list of license exceptions to use after
the "WITH" operator. As a result, a number of licenses formerly
included on the SPDX License List have been deprecated, and correct
usage employs the License Expression syntax as of v2.0.
So, I assumed the "+" operator is the right thing...
But, if I would have just read the next sentence; I would have noticed
that SPDX did a flip backwards on GNU licenses:
Release 3.0 replaced previous Identifiers for GNU licenses with more
explicit Identifiers to reflect the "this version only" or "any later
version" option specific to those licenses. As such, the previously
used Identifiers for those licenses are deprecated as of v3.0.
Now, I did some more digging into this whole SPDX spec evolution...
And in the section Allowing later versions of a license on
https://spdx.dev/ids/, it explains that this later version aspect is
different for GNU and non-GNU Licenses... with a rationale from the
GNU blog... I got it now.
So, sorry for the noise. This patch can be ignored.
Lukas
