Auto-detect unknown licenses

[narfbg]

The "license" property in the composer schema is restrictive in that it only allows SPDX-listed identifiers. And while that encourages usage of popular open-source licenses, it does have downsides ...

In my case, I managed to convince management at my workplace to publish some libraries as open-source, but we do use a custom (still permissive) license, and I have no way of pointing to it from packagist.
Listing it as "proprietary" would be incorrect (and is really vague for maintainers who do this). There's no option to do something like phpDoc's @license thing where you can specify both a label and a link to the license.

I'd like to propose searching for a "LICENSE", "LICENSE.txt" or "LICENSE.md" file on GitHub, GitLab (and probably other similar services) repositories in case there's no "license" property in composer.json. I see no downsides to this.

[Seldaek]

I guess we would need another thing to proprietary, maybe custom or so that indicates it is non-standard but not closed. I am not sure I understand what you are suggesting we do with the LICENSE file.

[narfbg]

Well, my idea was to have a way to link non-standard licenses.

It could happen via special syntax, which I'd argue would be beneficial for "proprietary" too:

"license": [
    "custom <url>",
    "proprietary <url>"
]

... or:

"license": {
    "custom": "<url>",
    "proprietary": "<url>"
}

But since GitHub already encourages putting LICENSE.md files in repositories, I thought it may be better to search for that and link to it from the packagist page.
Better IMO, because that way a license can be auto-detected for packages that haven't specified it in composer.json, though surely that does require more work.

[stof]

Auto-detecting the license for github repo would be possible by using the github API, as they expose their own license detection. But the issue is that composer allows to have a different license per version (allowing for instance to change license at some point) while the github API only gives access to the license in the default branch. So this would not work well.

And I don't think we want to implement license guessing in composer itself.

[Seldaek]

Yeah I like the first idea of allowing an optional URL following the custom/proprietary. The best though would be to use a standardized license because most devs aren't lawyers and if we can't rely on standards to know what licenses mean, it's kinda impossible to follow terms IMO.

[narfbg]

Indeed, using the standardized/popular licenses should still be encouraged.

I only wish for the non-standard ones to be at least reachable for users who want to read them, while currently only an "Unknown" label is shown.
I don't really mind if the label <url> (or similar) syntax is the way to go. In fact, I blindly tried that in the first place. :)