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?
[1] https://github.com/sfilippone/psblas3/blob/development/LICENSE [2] https://github.com/sfilippone/psblas3/issues/37
--- Antonio Trande Fedora Project, User:Sagitter Website: antoniotrande.blog mailto: sagitter@fedoraproject.org GPG key: 0x6ea362cc4c1aeac10b3a5c5402b0e70b4933065a GPG keys server: https://pgp.mit.edu/
On 2026/03/11 12:01, sagitter--- via legal wrote:
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?
You can use a tool like https://tools.spdx.org/app/check_license/ to check the exact license text. Can you also provide the output or context of which file did the licensecheck report to have the CMU license?
I could not actually find the CMU license in https://spdx.org/licenses/, so I am also not sure which one it is referring to :/
- Can you also provide the output or context of which file did the licensecheck report to have the CMU license?
Just use `licensecheck` inside the unzipped source code or download the file directly
$ wget https://raw.githubusercontent.com/sfilippone/psblas3/refs/heads/development/... && licensecheck ./LICENSE Saving 'LICENSE' HTTP response 200 [https://raw.githubusercontent.com/sfilippone/psblas3/refs/heads/development/...] LICENSE 100% [==================================================== 866 --.-KB/s [Files: 1 Bytes: 866 [1.83KB/s] Redirects: 0 Todo: 0 Errors: 0 ] ./LICENSE: CMU License
--- Antonio Trande Fedora Project, User:Sagitter Website: antoniotrande.blog mailto: sagitter@fedoraproject.org GPG key: 0x6ea362cc4c1aeac10b3a5c5402b0e70b4933065a GPG keys server: https://pgp.mit.edu/
mercoledì 11 marzo 2026 11:08, Cristian Le via legal legal@lists.fedoraproject.org ha scritto:
On 2026/03/11 12:01, sagitter--- via legal wrote:
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?
You can use a tool like https://tools.spdx.org/app/check_license/ to check the exact license text. Can you also provide the output or context of which file did the licensecheck report to have the CMU license?
I could not actually find the CMU license in https://spdx.org/licenses/, so I am also not sure which one it is referring to :/
On 2026/03/11 12:28, sagitter--- via legal wrote:
- Can you also provide the output or context of which file did the licensecheck report to have the CMU license?
Just use `licensecheck` inside the unzipped source code or download the file directly
$ wget https://raw.githubusercontent.com/sfilippone/psblas3/refs/heads/development/... && licensecheck ./LICENSE Saving 'LICENSE' HTTP response 200 [https://raw.githubusercontent.com/sfilippone/psblas3/refs/heads/development/...] LICENSE 100% [==================================================== 866 --.-KB/s [Files: 1 Bytes: 866 [1.83KB/s] Redirects: 0 Todo: 0 Errors: 0 ] ./LICENSE: CMU License
Thanks it seems the word "prior" in the "... promote products derived from this software without specific prior written permission." of the license text was left out. Adding it back makes it detect as BSD-3-Clause. The license text does not mark that that word can be omitted [1]
On Wed, Mar 11, 2026 at 7:02 AM sagitter--- via devel devel@lists.fedoraproject.org wrote:
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?
[1] https://github.com/sfilippone/psblas3/blob/development/LICENSE [2] https://github.com/sfilippone/psblas3/issues/37
No idea. Probably worth asking the licensecheck upstream developer...
Jonas, this seems weird, any idea what's going on?
Hi Antonio:
On Wed, Mar 11, 2026 at 12:02 PM sagitter--- via legal legal@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 ;)
[3] https://salsa.debian.org/build-common-team/licensecheck [4] https://github.com/google/licensecheck/ [5] https://github.com/sfilippone/psblas3/tree/development/cuda/spgpu [6] https://github.com/sfilippone/psblas3/blob/development/cuda/License-spgpu.md [7] https://github.com/aboutcode-org/scancode-toolkit/ [8] https://github.com/aboutcode-org/scancode.io [9] https://github.com/sfilippone/psblas3/issues/37#issuecomment-4039152251 -- Cordially Philippe Ombredanne AboutCode.org Package URL (PURL), ScanCode, DejaCode, PurlDB and VulnerableCode Book a call at https://cal.com/pombreda
On Wed, Mar 11, 2026 at 9:23 AM Philippe Ombredanne via legal legal@lists.fedoraproject.org wrote:
Hi Antonio:
On Wed, Mar 11, 2026 at 12:02 PM sagitter--- via legal legal@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.
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.
-- 真実はいつも一つ！/ Always, there's only one truth!
Hi Neal!
On Wed, Mar 11, 2026 at 2:28 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Mar 11, 2026 at 9:23 AM Philippe Ombredanne via legal legal@lists.fedoraproject.org wrote:
Hi Antonio:
On Wed, Mar 11, 2026 at 12:02 PM sagitter--- via legal legal@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
On Wed, Mar 11, 2026 at 10:10 AM Philippe Ombredanne pombredanne@aboutcode.org wrote:
Hi Neal!
On Wed, Mar 11, 2026 at 2:28 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Mar 11, 2026 at 9:23 AM Philippe Ombredanne via legal legal@lists.fedoraproject.org wrote:
Hi Antonio:
On Wed, Mar 11, 2026 at 12:02 PM sagitter--- via legal legal@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!
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@aboutcode.org wrote:
Hi Neal!
On Wed, Mar 11, 2026 at 2:28 PM Neal Gompangompa13@gmail.com wrote:
On Wed, Mar 11, 2026 at 9:23 AM Philippe Ombredanne via legal legal@lists.fedoraproject.org wrote:
Hi Antonio:
On Wed, Mar 11, 2026 at 12:02 PM sagitter--- via legal legal@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 Mon, May 18, 2026 at 4:30 PM Jilayne Lovejoy via legal < legal@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
On Mon, May 18, 2026 at 9:40 PM Pamela Chestek via legal legal@lists.fedoraproject.org wrote:
On Mon, May 18, 2026 at 4:30 PM Jilayne Lovejoy via legal legal@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
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.
On Wed, Mar 11, 2026 at 10:54 AM Miroslav Suchý via legal legal@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...
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/lib...
[3] https://docs.fedoraproject.org/en-US/legal/license-audit-tools/#_scancode_to...
-
Cristian Le -
Jilayne Lovejoy -
Miroslav Suchý -
Neal Gompa -
Pamela Chestek -
Philippe Ombredanne -
Richard Fontana -
sagitter＠fedoraproject.org