Hi all,
I wanted to draw your attention to something going on over at SPDX
that you may all have input/opinions on:
There is a proposed update to the SPDX license inclusion guidelines that
would enable linux-firmare licenses to possibly have an SPDX license id.
See all the details and links here:
https://lists.spdx.org/g/Spdx-legal/message/3778
Notably - if you want to weigh in, please join and comment on the
spdx-legal mailing list and/or attend the Sept 10th SPDX-legal call at
noon US eastern time.
Also, if you have an SPDX license list submission, please make sure to
clarify if it is from/a license included in Fedora, as that helps us
prioritize those requests.
Thanks!
Jilayne
I just got hit by another project that is over-eager to add the "All
rights reserved" snippet on a FOSS license.
I have opened an issue with upstream [1], but I guess we do not actually
have a documented guidance or reference to point upstream to?
The big thing that spurred me into opening the issues is that that
snippet is included in the BSD-3-Clause license text itself, which seems
very at odds with the text of the license. What is even more concerning
is that when I put it into an spdx license check [2] it says it is a
"perfect match" for BSD-3-Clause
[1]: https://github.com/hfp/libxs/issues/24
[2]: https://tools.spdx.org/app/check_license/
On Mon, May 18, 2026 at 9:40 PM Pamela Chestek via legal
<legal(a)lists.fedoraproject.org> wrote:
>
>
>
> On Mon, May 18, 2026 at 4:30 PM Jilayne Lovejoy via legal <legal(a)lists.fedoraproject.org> wrote:
>>
>>
>> The SPDX id for 0BSD never changed, so that is incorrect.
>>
> To go way into the weeds on this and you no one asked!, but it was OSI that changed its nomenclature. It was originally approved as "Free Public License 1.0.0" but was changed to match SPDX.
Rob Landley created Zero Clause BSD (a derivative of the ISC license,
not one of the BSD licenses) under that name and got SPDX to assign
the identifier `0BSD`. He did not seek OSI approval. A few years
later, a less well known person named Christian Bundy independently
created the same license and called it Free Public License 1.0.0, he
submitted it for OSI approval, and it was approved by OSI under that
name (with an appropriate cross-reference to the SPDX identifier
`0BSD`). Rob complained quite strongly about this, and ultimately
Christian decided he didn't care if the name of the license was
changed by OSI. OSI did not change the name to match SPDX, but rather
to stop Rob from continuing to complain about it.
In retrospect, I think Rob was right though, as the license is indeed
pretty etched in public FOSS consciousness now as `0BSD`, and it is
unlikely that "FPL-1.0.0" would have caught on as an alternative name.
Richard
On Mon, May 18, 2026 at 4:30 PM Jilayne Lovejoy via legal <
legal(a)lists.fedoraproject.org> wrote:
>
> The SPDX id for 0BSD never changed, so that is incorrect.
>
> To go way into the weeds on this and you no one asked!, but it was OSI
that changed its nomenclature <https://opensource.org/license/0bsd>. It was
originally approved as "Free Public License 1.0.0" but was changed to match
SPDX.
Pam Chestek
realize this is an old thread, but...
On 3/11/26 8:15 AM, Neal Gompa via legal wrote:
> On Wed, Mar 11, 2026 at 10:10 AM Philippe Ombredanne
> <pombredanne(a)aboutcode.org> wrote:
>> Hi Neal!
>>
>> On Wed, Mar 11, 2026 at 2:28 PM Neal Gompa<ngompa13(a)gmail.com> wrote:
>>> On Wed, Mar 11, 2026 at 9:23 AM Philippe Ombredanne via legal
>>> <legal(a)lists.fedoraproject.org> wrote:
>>>> Hi Antonio:
>>>>
>>>> On Wed, Mar 11, 2026 at 12:02 PM sagitter--- via legal
>>>> <legal(a)lists.fedoraproject.org> wrote:
>>>>> Checking the license of next psblas3 release, `licensecheck` tool recognizes this license file [1] as CMU
>>>>> Upstream confirmed that psblas3 is distributed under a BSD-3-Clause instead [2].
>>>>>
>>>>> Why does it look like `licensecheck` is confused with this license?
>>>>>
>>>>> [1]https://github.com/sfilippone/psblas3/blob/development/LICENSE
>>>>> [2]https://github.com/sfilippone/psblas3/issues/37
>>>> This is a bug in licensecheck, whichever you consider:
>>>>
>>>> - the Perl licensecheck [3] from Debian is limited in that is use a
>>>> small list of ~ 1000 hand crafted limited regex patterns. This is
>>>> actively maintained from what I can see.
>>>> - the Go licensecheck [4] from Google had a limited set of limited
>>>> regex patterns, and is unmaintained for 4 years.
>>>>
>>>> You should use ScanCode toolkit [7] or ScanCode.io [8] for
>>>> comprehensive license detection, and it will get you a proper
>>>> BSD-3-Clause for that file. ScanCode deals with ~40K samples that are
>>>> not hand crafted and performs eventually a full detailed match. This
>>>> is supposed to be a better, maintained tool.
>>>>
>>>> Note also that there is more to it than meet the eyes if you run a
>>>> full scan. psblas3 LICENSE is a BSD-3-Clause alright, but the bulk of
>>>> the code in [5] has GPL notices, and there is a top license in [6]
>>>> that says this is a BSD-2-Clause, so things are not clear. I posted
>>>> upstream for that [9]
>>>>
>>>> Miroslav:
>>>> I recall that ScanCode is the main tool used for Fedora, is this correct?
>>>>
>>>> PS: I maintain ScanCode ;)
>>>>
>>> The primary tool is Debian's licensecheck. Everything else is
>>> secondarily used currently.
>> IMHO Debian's licensecheck detection approach is limited and the tool
>> is not actively maintained.
>>
>>> Does ScanCode offer a way to emit license information with full
>>> license names instead of the identifiers? I would rather consumers of
>>> human-read reports have full license names like licensecheck
>>> instead of identifiers, since names are stable and identifiers are not.
>> We report names and identifiers [1]. As well as the exact matched
>> texts, tagging also the non matched parts if any, using a full diff.
>> We also guarantee that identifiers are stable, e.g. never deleted, but
>> can be deprecated.
>> Are you bringing this up because of the GPL2+ problem of 2017 with rms
>> insisting to change A/L/GPL identifiers at SPDX ?
>>
> It's one example. But it's not the only time an identifier has
> changed. 0BSD is another example as such. It's just much better to
> report to humans the actual name of the license instead of assuming
> people know what the identifiers are.
SPDX-legal has always made a commitment to deprecate (and then change)
license ids as infrequently as possible.
The biggest changes were associated many years ago due to a change in
the spec and license list to accommodate license expressions. Which
everyone in the community was supportive of.
The SPDX id for 0BSD never changed, so that is incorrect.
The changes to the FSF licenses in 2017 is/was an outlier situation, and
less than ideal in a number of ways.
Many, many, many licenses do not have names or titles of any kind, so
using an "actual name" is not realistic b/c one so frequently doesn't
exist. :)
> At some level, I also want people to know what they're looking at. The
> soup of identifiers makes it easier for people to ignore what they
> *are* and the implications of them.
>
> I would vastly prefer *no* shortnames or machine-oriented identifiers
> are used at all in the human-focused license reports.
>
>
>
>
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Mar 11, 2026 at 10:54 AM Miroslav Suchý via legal
<legal(a)lists.fedoraproject.org> wrote:
>
> Dne 11. 03. 26 v 2:21 odp. Philippe Ombredanne via legal napsal(a):
> > I recall that ScanCode is the main tool used for Fedora, is this correct?
>
> This is main recomendation for doing the license audit. However, the rpmlint and rpminspect still uses licensecheck.
>
> We will have to do something about it once we finish migration to SPDX IDs. We were looking as deployment of FOSSology
> in fedora-infra, but we need more hands.
>
Well, there was also Cavil too...
--
真実はいつも一つ！/ Always, there's only one truth!
Dne 11. 03. 26 v 2:21 odp. Philippe Ombredanne via legal napsal(a):
> I recall that ScanCode is the main tool used for Fedora, is this correct?
This is main recomendation for doing the license audit. However, the rpmlint and rpminspect still uses licensecheck.
We will have to do something about it once we finish migration to SPDX IDs. We were looking as deployment of FOSSology
in fedora-infra, but we need more hands.
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
On Wed, Mar 11, 2026 at 10:10 AM Philippe Ombredanne
<pombredanne(a)aboutcode.org> wrote:
>
> Hi Neal!
>
> On Wed, Mar 11, 2026 at 2:28 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Wed, Mar 11, 2026 at 9:23 AM Philippe Ombredanne via legal
> > <legal(a)lists.fedoraproject.org> wrote:
> > >
> > > Hi Antonio:
> > >
> > > On Wed, Mar 11, 2026 at 12:02 PM sagitter--- via legal
> > > <legal(a)lists.fedoraproject.org> wrote:
> > > > Checking the license of next psblas3 release, `licensecheck` tool recognizes this license file [1] as CMU
> > > > Upstream confirmed that psblas3 is distributed under a BSD-3-Clause instead [2].
> > > >
> > > > Why does it look like `licensecheck` is confused with this license?
> > > >
> > > > [1] https://github.com/sfilippone/psblas3/blob/development/LICENSE
> > > > [2] https://github.com/sfilippone/psblas3/issues/37
> > >
> > > This is a bug in licensecheck, whichever you consider:
> > >
> > > - the Perl licensecheck [3] from Debian is limited in that is use a
> > > small list of ~ 1000 hand crafted limited regex patterns. This is
> > > actively maintained from what I can see.
> > > - the Go licensecheck [4] from Google had a limited set of limited
> > > regex patterns, and is unmaintained for 4 years.
> > >
> > > You should use ScanCode toolkit [7] or ScanCode.io [8] for
> > > comprehensive license detection, and it will get you a proper
> > > BSD-3-Clause for that file. ScanCode deals with ~40K samples that are
> > > not hand crafted and performs eventually a full detailed match. This
> > > is supposed to be a better, maintained tool.
> > >
> > > Note also that there is more to it than meet the eyes if you run a
> > > full scan. psblas3 LICENSE is a BSD-3-Clause alright, but the bulk of
> > > the code in [5] has GPL notices, and there is a top license in [6]
> > > that says this is a BSD-2-Clause, so things are not clear. I posted
> > > upstream for that [9]
> > >
> > > Miroslav:
> > > I recall that ScanCode is the main tool used for Fedora, is this correct?
> > >
> > > PS: I maintain ScanCode ;)
> > >
> >
> > The primary tool is Debian's licensecheck. Everything else is
> > secondarily used currently.
>
> IMHO Debian's licensecheck detection approach is limited and the tool
> is not actively maintained.
>
> > Does ScanCode offer a way to emit license information with full
> > license names instead of the identifiers? I would rather consumers of
> > human-read reports have full license names like licensecheck
> > instead of identifiers, since names are stable and identifiers are not.
>
> We report names and identifiers [1]. As well as the exact matched
> texts, tagging also the non matched parts if any, using a full diff.
> We also guarantee that identifiers are stable, e.g. never deleted, but
> can be deprecated.
> Are you bringing this up because of the GPL2+ problem of 2017 with rms
> insisting to change A/L/GPL identifiers at SPDX ?
>
It's one example. But it's not the only time an identifier has
changed. 0BSD is another example as such. It's just much better to
report to humans the actual name of the license instead of assuming
people know what the identifiers are.
At some level, I also want people to know what they're looking at. The
soup of identifiers makes it easier for people to ignore what they
*are* and the implications of them.
I would vastly prefer *no* shortnames or machine-oriented identifiers
are used at all in the human-focused license reports.
--
真実はいつも一つ！/ Always, there's only one truth!
Hi Neal!
On Wed, Mar 11, 2026 at 2:28 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Wed, Mar 11, 2026 at 9:23 AM Philippe Ombredanne via legal
> <legal(a)lists.fedoraproject.org> wrote:
> >
> > Hi Antonio:
> >
> > On Wed, Mar 11, 2026 at 12:02 PM sagitter--- via legal
> > <legal(a)lists.fedoraproject.org> wrote:
> > > Checking the license of next psblas3 release, `licensecheck` tool recognizes this license file [1] as CMU
> > > Upstream confirmed that psblas3 is distributed under a BSD-3-Clause instead [2].
> > >
> > > Why does it look like `licensecheck` is confused with this license?
> > >
> > > [1] https://github.com/sfilippone/psblas3/blob/development/LICENSE
> > > [2] https://github.com/sfilippone/psblas3/issues/37
> >
> > This is a bug in licensecheck, whichever you consider:
> >
> > - the Perl licensecheck [3] from Debian is limited in that is use a
> > small list of ~ 1000 hand crafted limited regex patterns. This is
> > actively maintained from what I can see.
> > - the Go licensecheck [4] from Google had a limited set of limited
> > regex patterns, and is unmaintained for 4 years.
> >
> > You should use ScanCode toolkit [7] or ScanCode.io [8] for
> > comprehensive license detection, and it will get you a proper
> > BSD-3-Clause for that file. ScanCode deals with ~40K samples that are
> > not hand crafted and performs eventually a full detailed match. This
> > is supposed to be a better, maintained tool.
> >
> > Note also that there is more to it than meet the eyes if you run a
> > full scan. psblas3 LICENSE is a BSD-3-Clause alright, but the bulk of
> > the code in [5] has GPL notices, and there is a top license in [6]
> > that says this is a BSD-2-Clause, so things are not clear. I posted
> > upstream for that [9]
> >
> > Miroslav:
> > I recall that ScanCode is the main tool used for Fedora, is this correct?
> >
> > PS: I maintain ScanCode ;)
> >
>
> The primary tool is Debian's licensecheck. Everything else is
> secondarily used currently.
IMHO Debian's licensecheck detection approach is limited and the tool
is not actively maintained.
> Does ScanCode offer a way to emit license information with full
> license names instead of the identifiers? I would rather consumers of
> human-read reports have full license names like licensecheck
> instead of identifiers, since names are stable and identifiers are not.
We report names and identifiers [1]. As well as the exact matched
texts, tagging also the non matched parts if any, using a full diff.
We also guarantee that identifiers are stable, e.g. never deleted, but
can be deprecated.
Are you bringing this up because of the GPL2+ problem of 2017 with rms
insisting to change A/L/GPL identifiers at SPDX ?
[1] https://scancode-licensedb.aboutcode.org/
--
Cheers
Philippe Ombredanne
AboutCode.org
Package URL (PURL), ScanCode, DejaCode, PurlDB and VulnerableCode
Book a call at https://cal.com/pombreda
Dne 11. 03. 26 v 12:01 odp. sagitter--- via devel napsal(a):
> Hi all.
>
> Checking the license of next psblas3 release, `licensecheck` tool recognizes this license file [1] as CMU
> Upstream confirmed that psblas3 is distributed under a BSD-3-Clause instead [2].
>
> Why does it look like `licensecheck` is confused with this license?
Short answer: Yes, the license is BSD-3-Clause. The `licensecheck` is confused because it is old code.
Long answer:
The best way to identify license is to use https://github.com/spdx/spdx-license-diff It is browser plugin and allows you
to visualize the diff against the top matches. It is one (maybe the only one) tool that actualy implement License
Matching Guidelines. [1]
The SPDX license list is only reliable source that uses markup to define variation and optional parts in defintions.
This is biggest strength of SPDX License List.
But old tools - and licensecheck is among them - uses heuristics and regular expressions.. You can se the example how
they do it here [2]. It is up to you (maintainers) to ask developers of these old tools to start SPDX License List and
implement their matching guidelines.
For me, the best tool to scanning code is scancode-toolkit. It is described here [3] with other known tools.
[1] https://spdx.github.io/spdx-spec/v3.0.1/annexes/license-matching-guidelines…
[2] https://salsa.debian.org/build-common-team/p5-string-license/-/blob/main/li…
[3] https://docs.fedoraproject.org/en-US/legal/license-audit-tools/#_scancode_t…
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
