GitHub license detection

[varunkumar]

Thanks for the service. I have created a custom CNAME for myself (@varunkumar) and used it for a few years. I have learnt recently that GitHub has a license detection feature and provides information for well-known licenses. However, the license detection fails to read *.mit-licenses.org licenses.

What are your thoughts on using the license link while making it easy for GitHub detection to work?

[remy]

I've only skimmed through the linked article, but can't see (quickly) how this would work.

What's your thoughts on this, or how to approach this?

[varunkumar]

GitHub should read through the links and detect licenses. Raised an issue with the licensee repo.

[remy]

They could possibly use the .well-known convention to find the licence in addition to what they already do, but I'm not entirely sure that really solves the core problem.

[nsoft]

As someone who often needs to verify licensing on things I'm using or suggesting I absolutely hate links. Links are disconnected from the version control of the project. If the license is not checked in, then when a project changes licensing and the content at the link destination changes (including upgrading to new versions of existing licenses for which the text of the link probably won't change), the documentation of what the prior code was released under is lost. Licenses should be checked in so that they are connected to the released version. Even if the destination of the link is version controlled that still places a burden of collating revision dates across two version controlled repositories.

Imagine some license troll links an MIT license for a small useful project, twenty large companies use it and then the link is updated to GPL... Now there is a legal battle over proving that the destination wasn't GPL (or proprietary, or whatever) all along...

A checked in license is simple. The license in the repo at the time of publication is the license forevermore, and even if the repo is taken down, clones of it will show the dated version history.

Note also that https://rem.mit-license.org/ is currently displaying Copyright date of 2023, which is incorrect for this repository since clearly some of the code was existing several years ago. The copyright notice is supposed to indicate the year first published. I am not a lawyer, but here's a reference:

https://www.copyrightlaws.com/copyright-symbol-notice-year/

So I would strongly encourage GitHub to not to support this at all. IMHO Linking licenses is terrible for the users of open source software.

[remy]

@nsoft there's a lot to unpack there, mostly that you don't like people using links to licenses 👍

Just to give you another perspective, I include my MIT license URL inside the code files (not every time, sometimes I forget), but I do that instead of including the full license text in the partic source file.

Also, something to consider, when a person is looking through a projects revision history to find when there's a license that suits them (as you suggest, some dev changes from MIT to GPL you might want to go back to the MIT version), if that dev just referenced a link in a readme, I'd use the exact same process, except I know the change is in the readme file - which then gets the commit branch point.

Still, I'm not saying don't do you, just explaining how I've approached the problem myself.

I don't see github detecting licence from a link, and moreover, there's another thread somewhere (in this repo) which suggests the license file must be distributed with source code.

On the copyright year, from the article that was linked, it's suggested but not required (emphasis mine):

For constantly evolving websites and blogs that contain works published over several years, the notice may include a range of years (e.g., 2011–2023)

Still, thanks for adding your input, but I don't see github being remotely interested in this as a feature, so I wouldn't worry 😉