Missing license information for repositories due to unrecognized license filename

[chinyeungli]

Projects under aboutcode-org are lacking license information in the 'About' section.
In addition, the github API responses do not provide license details (e.g., license: null)
For instance,
https://api.github.com/repos/aboutcode-org/purldb
https://api.github.com/repos/aboutcode-org/scancode-toolkit

This happens because GitHub does not recognize apache-2.0.LICENSE as a valid license file. It only looks for files named LICENSE, LICENSE.md etc. Since the project repositories don't have these files, GitHub is unable to detect the license.

[LuciferVid]

@chinyeungli I’ve submitted a PR that resolves this issue by renaming the license file to LICENSE so GitHub can properly detect it:

👉 #204

This should update the license info in both the "About" section and the GitHub API response.

Let me know if anything else needs to be adjusted!
Thanks!

[pombredanne]

@LuciferVid what about fixing GitHub license detection instead?

[LuciferVid]

@pombredanne hey! just to clarify, this pr is actually meant to fix github’s license detection.

the original repo uses a file named apache-2.0.LICENSE, which github doesn’t recognize, so it ends up showing no license in the about section and returns "license": null in the api.

i renamed it to just LICENSE, which github detects properly. after that change, it now shows apache-2.0 in the about section and also includes the license info in the api response.

attaching both screenshots for reference:

• original repo – no license detected (license: null in api, nothing in about section):

• my fork – license detected correctly:

let me know if anything else needs to be tweaked or if you'd want the same fix on other repos too.

thanks!

[chinyeungli]

@LuciferVid Thanks for the effort. I think what @pombredanne meant is that instead of renaming the current license file from apache-2.0.LICENSE to LICENSE, we should explore ways to request github to adjust its license detection behavior.

[LuciferVid]

@chinyeungli got it, makes sense. i thought it might be a simple fix from the repo side, but yeah if the naming is intentional across projects then reaching out to github’s side sounds fair.

happy to help with any other cleanup or fixes if needed — and thanks for the context!