LWN: Comments on "GitHub unveils its Licenses API"

GitHub unveils its Licenses API

mirabilos — Mon, 30 Mar 2015 12:28:34 +0000

They should just make the licencing information metadata about the repository, and not require actual files in the repository, which may not work for a publish-only copy, for example.

GitHub unveils its Licenses API

mathstuf — Sat, 21 Mar 2015 13:33:14 +0000

I'm well aware of the pitfalls around open core projects. However, I tend to offer the benefit of the doubt in most cases where development is more in the open (in contrast to "over the wall" open core projects). Can you point to patches rejected (or ignored) because they implement Enterprise's features? Even so, the code is permissively licensed (only an ICLA, no assignment), so if the patches exist, there is no reason to not grab them and apply them to your local install if you need them.

GitHub unveils its Licenses API

donbarry — Fri, 20 Mar 2015 19:31:22 +0000

I apologize if the particular antecedent reference was unclear: I tried to indicate Gitlab was the purchaser of Gitorious, but I see how you could have read it as Github.

But Gitlab is one of those "freemium" offerings: what you download is not the codebase used to serve the site. Such sites rarely accept patches from others which add the missing functionality, and that ethos of excluding development which permits the free codebase to develop the features needed by all users -- including the most demanding -- is diametrically opposed to the principles of free software.

Yes, you can fork -- but it can be very difficult, particularly when the original commercial team has the money and resources to keep the free offering "just good enough" to keep the attention primarily on it.

GitHub unveils its Licenses API

mathstuf — Fri, 20 Mar 2015 11:11:26 +0000

FTR, Git*Lab* bought Gitorious, not GitHub. GitLab is FOSS. I will see how they are with patches next month.

GitHub unveils its Licenses API

flussence — Thu, 19 Mar 2015 20:15:40 +0000

> Were you aware that the Unlicense is considered unreliable and may scare off people who would otherwise use your code?

Absolutely. I've made a conscious decision to alienate a whole bunch of people, just like the authors of every other software license in the universe have done. Most consumers of prewritten licenses do so unconsciously.

GitHub unveils its Licenses API

donbarry — Thu, 19 Mar 2015 15:51:37 +0000

This seems like a good time to remind free/libre software advocates that Github is itself a proprietary tool and thus a trap. Fortunately, unlike Bitkeeper, the protocol and the underlying DVCS remains free. This gives options, but most remain problematic. Gitlab offers the disingenuous "use our proprietary site for which we distribute a limited copy of the code under a libre license as advertising" model. And let us not forget that they bought and shuttered Gitorious, which developed its web system under a fully libre model.

The only truly free option right now seems to be Kallithea, thanks to the foresight and critical investment of the Software Freedom Law Center. It also began life as a libre project, accepting code contributions, and was then taken proprietary by its founders -- contributed code included. The Kallithea fork restores to the community something worthy of their contribution. It deserves your efforts at improvement and your loyalty.

Is it any surprise that a company based on proprietary software might put off concern about licenses until late in the game? It is encouraging the worst habits and intellectual sloth among its users.

GitHub unveils its Licenses API

ssokolow — Thu, 19 Mar 2015 10:22:35 +0000

Were you aware that the Unlicense is considered unreliable and may scare off people who would otherwise use your code?

https://programmers.stackexchange.com/questions/147111/wh...

License combos

david.a.wheeler — Tue, 17 Mar 2015 13:39:04 +0000

There are many ways to record combination licenses. Fedora and SPDX both support "and", e.g., "GPLv2+ and MIT".

The real problem is software that has NO license stated. Those are legal traps for naive users.

GitHub unveils its Licenses API

jzb — Sun, 15 Mar 2015 21:51:29 +0000

Lots. No doubt there's tons of stuff on GitHub that probably of interest to only one user - and maybe not even that user for a very long period of time.

Still, I've seen a shocking number of repositories that are something that others do want to use (and even have been promoted by the creators) and have no licensing information.

What would be very interesting would be to see how many repositories lack a license *and* have been cloned/forked by other users. It might really get folks' attention if, say, 15% of repositories without a license have been forked at least once.

GitHub unveils its Licenses API

xtifr — Sat, 14 Mar 2015 18:57:58 +0000

A repository doesn't necessarily have a single license. Subtrees may be licensed under different terms.

Indeed, I have one project like that—a GPL'd app that has an MIT'd library (eventually to be split off)—and the API currently reports just the GPL. So it definitely doesn't handle this case.

GitHub unveils its Licenses API

mathstuf — Sat, 14 Mar 2015 01:25:45 +0000

The file is usually excluded when making the archive, but not always. I try to make such things closer to the files affected personally, but some people like using top-level files for it.

GitHub unveils its Licenses API

cesarb — Fri, 13 Mar 2015 16:33:42 +0000

> Using gitattributes to annotate this seems appealing, but suffers from a few issues. For one, the information is lost if a revision is exported as a tarball / zip.

Aren't git attributes stored in a plain text file called .gitattributes within the repository itself? Exporting a revision would unavoidably export that file together with everything else.

GitHub unveils its Licenses API

jond — Fri, 13 Mar 2015 13:30:16 +0000

I read that to mean some build systems can't handle such things.

GitHub unveils its Licenses API

Limdi — Fri, 13 Mar 2015 00:58:05 +0000

> Relying on a LICENSE (or COPYING or whatever) file is problematic too, because some repositories can't have arbitrary files lying around at the top level.

What kind of repositories cannot? Assuming "repositories" is reffering to git repositories.

GitHub unveils its Licenses API

ringerc — Fri, 13 Mar 2015 00:05:29 +0000

A repository doesn't necessarily have a single license. Subtrees may be licensed under different terms.

For that reason it's always going to be necessary to let people choose "no license" or provide a "multiple licenses" option.

Using gitattributes to annotate this seems appealing, but suffers from a few issues. For one, the information is lost if a revision is exported as a tarball / zip. Additionally it can lead to the license metadata getting out of sync with the real license if the user changes the license in a subtree.

Relying on a LICENSE (or COPYING or whatever) file is problematic too, because some repositories can't have arbitrary files lying around at the top level.

I'm not convinced a comprehensive technical solution to this is possible. The main thing to do, IMO, is encourage people to think about the license and provide tools (like they have) to make adding license info easier.

GitHub unveils its Licenses API

jond — Thu, 12 Mar 2015 22:07:35 +0000

Debian have done a lot of work on implementing a machine-readable copyright format that can describe some complex mixed-license schemes. I wonder if that work would be useful to this problem. http://dep.debian.net/deps/dep5/

GitHub unveils its Licenses API

flussence — Thu, 12 Mar 2015 17:12:44 +0000

I hope to see such badly machine-detected alerts start popping up on my repos; I made a conscious decision to use the Unlicense.

GitHub unveils its Licenses API

smitty_one_each — Thu, 12 Mar 2015 16:14:41 +0000

I'm probably an offender here, too, but I just can't get past the most abstract intellectual concern.

Perhaps "git clone" should produce a warning?

mathstuf — Thu, 12 Mar 2015 11:36:00 +0000

I see no problem setting it on other files as well. Maybe "license-file" for the actual license files themselves?

GitHub unveils its Licenses API

yosch — Thu, 12 Mar 2015 11:03:18 +0000

Seems like only a fraction of the SPDX spec is actually supported.

Perhaps "git clone" should produce a warning?

tzafrir — Thu, 12 Mar 2015 07:16:59 +0000

Assuming you actually have a single license for the whole code in the repository.

GitHub unveils its Licenses API

alison — Thu, 12 Mar 2015 06:24:36 +0000

>Would be great to see a bit, prominent "YOUR PROJECT DOES NOT INCLUDE A LICENSE" at top of the page

I couldn't agree more. Until a friend pointed me towards this article, I didn't realize that *my* public Github repos had no license. Shame on me. Github certainly does bury the question. Thank you, Paul, I am closing that personal ticket now!

Perhaps "git clone" should produce a warning?

alison — Thu, 12 Mar 2015 06:21:48 +0000

Good idea.

GitHub unveils its Licenses API

cmbang — Thu, 12 Mar 2015 04:33:42 +0000

Would be great to see a bit, prominent "YOUR PROJECT DOES NOT INCLUDE A LICENSE" at top of the page on any repos lacking proper documentation. Likewise, a big obtrusive header on any forked repository lacking such docs would also be useful.

This lack of requirement is likely what has caused GitHub to succeed, as most users don't understand or care about licensing. Definitely more could be done to educate here.

Perhaps "git clone" should produce a warning?

mathstuf — Thu, 12 Mar 2015 01:04:52 +0000

Using gitattributes for this would be nice. Something like:

> LICENCE license=BSD3
> LICENSE.third-party license=MIT:WTFPL

GitHub unveils its Licenses API

lambda — Thu, 12 Mar 2015 00:14:29 +0000

Nevertheless, the GitHub Licenses API does appear to be strangely naive in its approach. For example, it is well-established that a significant number of projects place their license in a file named COPYING, rather than LICENSE, because that has long been the convention used by the GNU project. Even scanning for that filename (or other obvious candidates, like GPL.txt) would enhance the quality of the data available significantly. Far better would be allowing the repository owner to designate what file contains the license.

It looks like it isn't quite as naive as you may believe from its description. For example, I tried it out on some random fork of GNU coreutils which contains only the standard GNU COPYING file, and it returned the correct metadata for the GPLv3:

$ curl 'https://api.github.com/repos/goj/coreutils' -H 'Accept: application/vnd.github.drax-preview+json'
{
  "id": 3237260,
  "name": "coreutils",
  "full_name": "goj/coreutils",
  // ... snip ...
  "license": {
    "key": "gpl-3.0",
    "name": "GNU General Public License v3.0",
    "url": "https://api.github.com/licenses/gpl-3.0"
  },
  "network_count": 18,
  "subscribers_count": 7
}

So, it is at least looking at files named COPYING as well as LICENSE. And here's another that has a file named LICENSE-2.0.txt which it correctly reports as Apache licensed:

$ curl 'https://api.github.com/repos/SmartBear/ready-api-plugins' -H 'Accept: application/vnd.github.drax-preview+json'
{
  "id": 25704802,
  "name": "ready-api-plugins",
  "full_name": "SmartBear/ready-api-plugins",
  // ... snip ...
  "license": {
    "key": "apache-2.0",
    "name": "Apache License 2.0",
    "url": "https://api.github.com/licenses/apache-2.0"
  },
  // ... snip ...
}

It does not, however, pick up on Documentation/GPL.txt in this repository, or just gpl.txt in this one.

GitHub unveils its Licenses API

jefftaylor — Wed, 11 Mar 2015 23:14:07 +0000

How many of these repositories are "real"? I've got several GitHub repositories that don't correspond to anything that anyone would ever want to use (eg. English homework). They don't have a licence. Yet they're a part of the the 80% of unlicensed projects.

Just how many "foobar", "homework", and "test_git" repositories are there out there?

Perhaps "git clone" should produce a warning?

droundy — Wed, 11 Mar 2015 21:26:06 +0000

At first I thought git was the wrong place for this. I use git for all sorts of projects that are not software and will never be public, and it would seem annoying to have to either add a nonsense file to each repository or change the git defaults or see a warning message.

On the other hand, I also only very rarely clone my own repositories, so I suppose it really bother me to have a rarely-seen polite warning that I am cloning an unlicensed repository. And actually, this suggestion puts the warning in the right place: users who download the software should be aware that by using it they could put themselves at legal risk.

Perhaps "git clone" should produce a warning?

david.a.wheeler — Wed, 11 Mar 2015 20:51:05 +0000

It might be useful if "git clone" reported a warning if the clone didn't have COPYING*, LICENSE*, or similar file. This won't change people who like to put their users at legal risk, but it would help those who simply forget.

GitHub unveils its Licenses API

w00t — Wed, 11 Mar 2015 20:30:18 +0000

I'm still not sure just how accurate their statistics are.

Let me first state that I think they are right: there's a lot of people (and projects) that don't get licensing "correct", even to the point of not licensing their code.

On the flipside of the coin, they acknowledge that they only look for the presence of a LICENSE file. They don't scan code headers (which will get a large amount of code), and also presumably runs into the problem of not accounting for multiple licenses in a codebase correctly.

I know that I'm personally very lazy when it comes to LICENSE files. I often forget to add them. The code headers, however, are always intact. I've seen others do this quite often too.