Wrong license detected: `GPL-3.0-only`

[NatoBoram]

trafficstars

Duplicates

• [X] I have searched the existing issues

Current behavior 😯

License: GPL-3.0-only

Expected behavior 🤔

License: GPL-3.0-or-later

Steps to reproduce 🕹

1. npm init
2. Set license to GPL-3.0-or-later
3. onefetch

[o2sh]

Seems related to https://github.com/jpeddicord/askalono/issues/45

In this case we may want to display the aliases using store.aliases(license.name) 🤔

[NatoBoram]

Hm, that doesn't feel right. "Aliases" seem like a property of a specific license rather than being a property of the repository. If we want to display the repository's properties, then we should only see the specific license used in the repository. Otherwise, we still have to open up the repo and manually search for this information.

[spenserblack]

It will complicate the code, but we could possibly try to get a license value from the package manifest (package.json, Cargo.toml, and setup.cfg have this value off the top of my head), and fall back to askalono only if no manifests were found. However, that raises the question of what to do with multiple manifests that may have license values.

Other than that, looking at -or-later vs -only, the standard license header between the two do differ. I wonder if that can be used to determine which SPDX identifier should be used? The GPLv3 license itself does suggest adding the header to the start of each source file. Interestingly, both -or-later and -only suggest this in the "How to Apply These Terms to Your New Programs" section:

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

(note the "or any later version")

This implies to me that -or-later should be the default if it can't be decided which to use, since the license's own suggested header falls under the "or later" category.

---

The above ideas would probably be complex enough that they should be their own libraries IMO.

[spenserblack]

With https://github.com/o2sh/onefetch/pull/851, this is close to being resolved. Perhaps just prioritizing the manifest's license over the license detected by askalono would be all that's needed.

I think it's reasonable to prioritize values that the user has explicitly defined over detected values. As a very loose parallel, github/linguist prioritizes an explicit definition (.gitattributes, shebangs) before trying to analyze and guess the value.

[o2sh]

Makes sense, I pushed your suggestion @spenserblack e2af4ec However, this will only apply to repositories with a cargo or npm manifest.

[spenserblack]

However, this will only apply to repositories with a cargo or npm manifest.

Since @NatoBoram's example was with npm, I guess the immediate issue is resolved :laughing: Besides adding support for more manifest files, I'm not sure what else we should do. Only thing I can think of is to search file contents (maybe a git grep?) and trying to find a standard license header to disambiguate the licenses. But that may be overkill.

[o2sh]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[NatoBoram]

Confirmed fixed in onefetch 2.16.0

I guess that people using other frameworks can raise their own issue so it's easier to keep track of progress