
License now displayed on repository overview - joeyespo
https://github.com/blog/2252-license-now-displayed-on-repository-overview
======
infodroid
...but it is only visible if you are logged in. That inconsistency is a little
weird.

~~~
masklinn
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
What would you prefer GitHub do? Display multiple licenses? I see that
situation as not really solvable.

~~~
tetrep
Why not apply the same solution already applied to branches? Have a drop down
that lists the different branches and their licenses, with it sorted such that
the branches with different licenses are displayed first.

~~~
dominotw
I would think that would be UI overload for such an edge case.

------
chrismorgan
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](https://github.com/benbalter/licensee/issues/57)

------
Pfhreak
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
You might be able to write that as a Webpack plugin with a couple of hours
work... could be neat.

------
CydeWeys
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.

~~~
SamBam
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.

------
sciurus
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/](https://lwn.net/Articles/636261/)

~~~
justinlardinois
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
Github uses an open source gem [0] to detect the license. You're welcome to
contribute enhancements.

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

~~~
sciurus
Looks like although the README says it only looks at LICENSE, it has improved
and checks more files; nice!

[https://github.com/benbalter/licensee/blob/3692df44ab32772a9...](https://github.com/benbalter/licensee/blob/3692df44ab32772a98a3aec8a44080f7dbe3d50a/lib/licensee/project_files/license_file.rb#L15-L25)

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

~~~
Chronic9q
Gitlab is a dying product.

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

~~~
matt4077
It's called "inheritance". It's an OOP concept, you functional kids won't
understand.

------
_ph_
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.

------
rmchugh
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.

~~~
reidrac
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.

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

------
kijin
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.

------
guessmyname
> 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.

~~~
cyphar
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.

~~~
pluma
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.

~~~
cyphar
Yeah, that's also a valid point. I've contributed license PRs to several
projects, just so that the next person doesn't need to trawl through the
readme or source code to find the one line that specifies the license in the
most ambiguous way possible.

------
kragen
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.

~~~
cyphar
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.

~~~
kragen
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.

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

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

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

------
tbirdz
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
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.

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

------
pcl
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.

------
brink
Neat.

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

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

~~~
jdubs
Err, the file browser area.

