License now displayed on repository overview
github.com
github.com
The license of the currently selected branch?
In all cases with more "complex licensing," you need to see the project's own license file. GitHub's little UI icon isn't legally-binding in any way. It's just a simple UI addition that works in the vast majority of cases.
In a Google search for "git branch different license," I don't see anyone else discussing licensing their projects this way. I'm not saying it isn't valid, it just seems really rare.
Your proposed solution wouldn't necessarily work for the (much more common, in my experience) situation where some branches, like deployment branches, omit the license all together. In those situations, those branches are typically under the same license as the main project. (As always, though, the final word should be in the project's license file.)
The old license is still applicable to the old code. If you're changing the license for future development and not pushing it to the main branch for some reason, it looks like you've got a new main branch.
1. That makes no sense, the "main branch" has a semantic for the project whether it's the current development HEAD or the current STABLE or whatever other concept you appli to it.
2. That doesn't fix the issue, which is that different branches can have different licenses (and with respect to search do have different contents).
> The old license is still applicable to the old code.
Yes, and if you change the "main branch" you end up with the same fuck up, namely that older releases/branches are now marked with the new license, which is not any more correct than the reverse.
That is, the license is metadata of a specific revision of a project (and technically subtrees can even have different licenses), not of the project as a whole, the project can be relicensed at any time.
If one wants to checkout a non-main branch, ostensibly they can view the LICENSE file in that branch on their own.
It doesn't make any sense to show the license of the main branch when I just switched to a different one, no. If they want to take the lazy route, just stop showing licenses on anything but the main branch.
And incidentally they could use that new feature to remove the search bar when not on the main branch since that's not going to search the current branch, but it won't provide any warning or indication that you're not searching what you thought you were.
> The code that GitHub displays when you hit the project page is from the main branch.
You are aware that github has a branch switcher right there on the "project page" right?
It would be nice if this was more programmatic. If licenses had an identifying string they carried so they could be clearly and consistently identified, and machine parseable metadata. If we make it easy to build automation around license files, we make it easy to do the right thing -- maybe even easier than doing the wrong thing.
I think about something like Webpack. If Webpack could just traverse your project structure and parse all your dependencies license files and generate the proper attributions, that would be amazing.
EDIT: Before anyone replies with "Why would you want that?", it's fairly common to stage a project privately on GitHub before publicly releasing it. It'd be nice to see that the license is detected correctly before going public with it. As it is now, I don't know what'll happen until I go public, and my first public commit in the repo may well be fixing up something minor to get the license detected properly.
https://github.com/benbalter/licensee/blob/3692df44ab32772a9...
This gets about a 97% hit rate, but even for "hits" it's sometimes unclear what specific license version a project is under. For example, many projects just say "licensed under MIT"...but "MIT" isn't a specific license. There are several versions of it and there's no way to know which version the author intends to use for the project. That might be a minute point, but this all adds up to a lot of uncertainty around licensing.
So, project authors, please use metadata and include a specific version :)
Now that github is adding the features that gitlab already added, they are more neck and neck again.
For example, lots of projects have more than one license, but GitHub seems to list only one. Incorrect information is worse than no information.
Besides current implementation only seems to pay attention to most popular licenses (?)... arguably CERN Open Hardware Licence is not amongst the most popular, but for some reason I was expecting GH to detect that one ;) So again: incomplete information.
Perhaps asking the repo owner to manually specify the licence could be an option, but if the repo owner cares about licences, I'm sure that information is available already.
> repository's LICENSE file to a short list of known licenses [...]
I have seen more people putting the license of their projects at the end of the README.md than in an individual LICENSE or LICENSE.md file which is what this feature analyzes. I noticed the addition of this feature a few days ago while checking the repository for the Atom.io project, but without an official blog post I was left thinking why none of my repositories (which are MIT licensed) were missing it. I guess reading LICENSE(\.md)? is good enough.
... which I would be perfectly okay with.
- License.(md?)
- README.md parsing the license
- package.json reading the license (it's for NPM)
To try to solve this exactly issue for a dependency tree:
I agree that we need to keep thinking about what one person has the right to do with another person's code, but copyright is a terrible starting point for that thought process, centering as it does the business models of eighteenth-century stationers at the expense of the much broader interests of political dissidents, scientists, historians, patients dependent on medical devices, teachers, students, librarians, archivists, whistleblowers, anybody trying to fix broken things, tinkerers, and journalists.
Also, it seems to be missing a lot of licensing cases. You can have files under multiple licenses in one repository and dual licensed projects. There doesn't seem to be any "GPLv2 only" and "GPLv2 or any later version of the GPL", which is also a big deal. For example Git and Linux are under "GPLv2 only", but are just listed as GPLv2 just the same as they list a license that's "GPLv2 or any later version".
Even more conspicuous is the lack of support for licenses with additional clauses. For example, many compilers like gcc have additional exception clauses allowing you to link the compiler runtime to your library without incurring the GPL requirements. Swift has a similar exception clause for their runtime library. Even though it's Apache v2 which is permissive, Apache v2 still requires distributing the license/copyright info with all copies binary or source for the software, which would be extremely annoying for a compiler to require. LLVM is discussing switching to a similar Apache v2 plus exception as well.
There's also a lot of licenses missing. And I'm not talking about ones that are obscure or equivalent to MIT, I'm talking about for example the Boost license, which is designed specifically to deal with the binary distribution requirements problem, and is popular in the C++ community. [0]
Just looking at the little badge isn't telling you enough useful information. For example, say you are writing a GPLv3 program, and you want to use a library. Looking at the github page shows you its has a GPLv2 badge. But if it's "GPLv2 only" instead of "GPLv2 or any other license" then you can't use it with your project. And the only way you can find that is by reading the license, or at least the README if the author explains the license there. Similarly, just looking at the badge doesn't tell you if the authors have added any additional exception clauses that could be useful in legal compatibility for your program, so you'll have to click through for that as well.
In the end, I think this just provides potential for confusion, and doesn't really make the job of seeing what license the software is under any easier. There could be advantages in listing the license in a standard place and way, but it should allow the developer to manually select the license, and for arbitrary text input for additional notes, or for licenses that github hasn't added. If they insist on keeping it automated, then there should be a way to opt out (of course it'd be best if it was opt-in, but that's not going to happen, so I won't even go there).
0: The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.
As others have commented, kragen is jumping to excitement a bit too quick. GitHub's license data is not curated, and I'm quite sure determining a license of software is an undecidable problem; it just requires human judgment, and many self-report their own license incorrectly to GitHub.
GitHub has a lot of problems to solve before the license data they are presenting can be trusted. Even many very common programs have licenses that can't even be described with an SPDX moniker, so the "badge method" just isn't going to work.
It looks like they try to read `LICENSE`, so maybe if you avoid using the American spelling and just put `LICENCE`, github will skip it. I know gitlab had this bug/feature.
Setting the license manually, of course, would solve the problem.