License now displayed on repository overview

https://github.com/blog/2252-license-now-displayed-on-repository-overview

by joeyespo • 10 years ago

173 65 10 years ago

github.com

brink• 10 years ago

Neat.

jdubs2• 10 years ago

Interesting that they're devoting screen real estate to something that can be found in the data section.

rahkiin• 10 years ago

The language the project is written in can also be found in the data section, still there is the language bar :)

CydeWeys2• 10 years ago

What is the data section? I don't see that on GitHub.

jdubs2• 10 years ago

Err, the file browser area.

_ph_• 10 years ago

A nice small enhancement. While many projects mention the license in the README, not all do. So it is very easy to see at a glance which license a project is under. In this context, I really appreciate how github offers to add the license while creating a new repository with a quick list of the most common licenses. A good incentive to put a new project under a proper license from the start and making sure that the correct license terms are attached.

eriknstr• 10 years ago

I noticed this a few days ago and I think it's a great addition. I hope they keep this feature.

pcl• 10 years ago

This is great! I often find myself clicking through to the license file and trying to remember which license text it looks like. This'll be both easier and more reliable.

infodroid• 10 years ago

...but it is only visible if you are logged in. That inconsistency is a little weird.

shakeel_mohamed• 10 years ago

This seems very odd, I wonder if it's a bug or by design

SpaceManiac• 10 years ago

I'm gonna guess it's temporary; I get the impression GitHub likes to test its changes before it releases them (I've been seeing the announced license indicator for several days), and that probably goes extra for logged-out users.

masklinn4• 10 years ago

And as with many other information (such as the bloody fucking search) it's only taking in account the repository's main branch and ignoring all others, if you decide to relicense in a branch for some reason that will not be displayed by github.

jsmthrowaway• 10 years ago

What would you prefer GitHub do? Display multiple licenses? I see that situation as not really solvable.

in_the_sticks• 10 years ago

Change what your main branch is?

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.

CydeWeys2• 10 years ago

This is really cool. One little detail I've noticed is that it doesn't seem to apply to private repositories, which seems like a bit of an oversight. The repo I'm checking clearly having an Apache 2.0 license text in the LICENSE file. Just because a particular copy of a repo is private doesn't mean that the code within it isn't still bound by an open source license.

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.

j_koreth• 10 years ago

It also doesn't detect if you aren't logged in, in my case.

SamBam2• 10 years ago

It seems to work fine on my org's private repos. Not sure if it's having trouble detecting the license in your case, or if it just hasn't worked through all the repos yet, or what.

libeclipse• 10 years ago

I've noticed that it doesn't distinguish between the different versions of the CC licence. It just puts them all under CC BY 4.0

sciurus2• 10 years ago

This is nice, but the way they gather license data has serious limitations if it hasn't improved in the last year.

https://lwn.net/Articles/636261/

justinlardinois2• 10 years ago

I was thinking the same thing. Just a few years ago GitHub used to automatically "figure out" what programming language your project was in, and it was pretty bad.

dankohn1• 10 years ago

Github uses an open source gem [0] to detect the license. You're welcome to contribute enhancements.

[0] https://github.com/benbalter/licensee

kmewhort• 10 years ago

This is tough problem to solve given how many different ways projects have to declare licenses. I run a project called git.legal and we do ALL of the following, but still don't quite a get a 100% hit rate of finding a project's license: 1. Check for a license declaration in package manager metadata (eg. package.json) 2. Check for a license.txt file or try to parse out a readme's license section, and do a full-text diff against known licenses 3. Check the readme for an extensive set of regular expressions matching known license identifiers and common declarations such as "licensed under ...". 4. Check for a consistent license declaration in project source file headers

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 :)

mordocai2• 10 years ago

Another feature copied from gitlab. Not that that is a bad thing.

Chronic9q• 10 years ago

Gitlab is a dying product.

imtringued• 10 years ago

If it's dying why would GitHub implement their features? Do they want to die too?

pluma2• 10 years ago

... How? If anything, Gitlab seems to have grown a lot recently. As far as I can tell, the competition with Gitlab is one of the main reasons GitHub has started releasing so many features (many of which Gitlab had first).

matt40772• 10 years ago

That's rich considering Gitlab is basically a Github clone.

mordocai2• 10 years ago

For quite a while github looked like a cheap gitlab knock off rather than the other way around due to gitlab actually innovating and adding new features and github stagnating.

Now that github is adding the features that gitlab already added, they are more neck and neck again.

tbirdz• 10 years ago

Is there any way to disable this, or set it manually at least? I'm concerned there may be a situation where the license is detected incorrectly, and then Github brands your repository as being under a certain license, when it really is not.

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.

bkuhn• 10 years ago

Hey, Tim, I've talked a number of times with GitHub about the issue of lack of nuance in their license monikers on GitHub. I haven't gotten very far, but this change will cause me of course to raise it again.

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.

hobarrera• 10 years ago

Is there any way to disable this, or set it manually at least?

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.

kijin2• 10 years ago

In order to distinguish between "GPLv2 only" and "GPLv2 or later", they can't just parse the LICENSE file, they need to look at comments in the actual source files to see if they contain "or (at your option) any later version" or some such disclaimer. This could lead to a lot of false positives and false negatives, especially if the project contains third-party code.

Setting the license manually, of course, would solve the problem.

kragen2• 10 years ago

This is a really good development. Programmers shouldn't have to worry about copyright; in the world of software, it does far more harm than good and should be done away with entirely. But for now we do have to worry about copyright, and the proliferation of "open-source" Github repositories with no explicit license puts us at risk of being sued in the future if our projects are successful. Little nudges like this will help a lot.

cyphar3• 10 years ago

I think that developers _should_ think about how they licence their software. Software licences are a cornerstone of the free software movement, and people should really consider what they believe people should have the right to do with their code.

kragen2• 10 years ago

Software licenses are a cornerstone of the free software movement because they are our only defense against copyright.

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.

Pfhreak• 10 years ago

Anything we can do to improve the usability and detection of licenses is a big win in my book. Even the best intentioned people have a hard time consistently doing the right thing -- whether that's attributing the right copyright owner, reproducing the right copyright message, or otherwise abiding by the license, it can be hard to be 100% correct.

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.

mbrock• 10 years ago

You might be able to write that as a Webpack plugin with a couple of hours work... could be neat.

guessmyname• 10 years ago

We use an open source Ruby gem called Licensee to compare the
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.

cyphar3• 10 years ago

The tool they use explains why they don't just scrape the entire repo. Basically it's because software licences are legally binding and it's not a good idea to put your license at the bottom of an FAQ in your readme. Licensing needs to be clearly deliberate.

pluma2• 10 years ago

I think a less charitable explanation is that they hope this will pressure developers into making their license info more consistently available to the advantage of everyone -- like how Google adjusts its search ranking algorithm to punish certain kinds of behaviour/problems.

... which I would be perfectly okay with.

franciscop• 10 years ago

I created a command-line tool with basically three columns which are:

- 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:

http://github.com/franciscop/ianal

tananaev• 10 years ago

How long does it take to index the file? I've added LICENSE.md to my project (https://github.com/tananaev/traccar), but the license doesn't show up at the top bar.

vbernat• 10 years ago

When I added one to one of my project, the change was immediately detected.

CannisterFlux• 10 years ago

I think it is because of the .md extension. I have LICENSE files (no .md) and they are picked up correctly.

susam• 10 years ago

I have my license in LICENSE.md, LICENSE.rst, etc. and they are picked up correctly. For example, https://github.com/susam/uncap and https://github.com/susam/ice.

chrismorgan• 10 years ago

Dual-licensing seems to not be supported by licensee [1]; MIT/Apache-2.0 is what’s used for Rust and a substantial fraction of the Rust ecosystem.

[1] https://github.com/benbalter/licensee/issues/57

rmchugh• 10 years ago

It's a good idea to make this more visible, but they should also make it visible when a repository does not have a license. If they did the UI right this would encourage developers to license their code in the same way that Facebook encourages users to add a profile picture.

dasmoth• 10 years ago

Please don't -- there's more than enough of that kind of nagging on todays web as it is.

kabouseng• 10 years ago

No licence means copyright applies I believe. So maybe if there is no licence then a generic copyright applies, contact the author message would suffice.

reidrac• 10 years ago

I don't think they should do that, for different reasons.

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.

kijin2• 10 years ago

Just checked a few of my own projects. Github doesn't recognize LGPLv3 properly, where the license is split into a GPLv3 "COPYING" file and an LGPLv3 "COPYING.LESSER" file. They ignore the latter and just slap GPLv3 on the project.

License now displayed on repository overview

Related Stories