
GitHub unveils its Licenses API - Iuz
http://lwn.net/Articles/636261/
======
FiloSottile
I and a friend wrote a tool to check your repositories with this API:

[http://put-a-license-on.it/](http://put-a-license-on.it/)

~~~
ImJasonH
This is great, I was considering making something like this myself. A few
suggestions:

\- It seems to run out of quota very quickly, I get 403s after listing the
repos of just a few users.

\- The "Click here" for adding a license just plops me into a page to add a
file to the repo. With some work, this could be replaced with a dropdown to
choose the license, and it could send a Pull Request to add it (or ask for the
user's permission to add it directly!)

\- I don't see any links to the code for this, in case I want to check it out
or send a Pull Request (to fix the issues listed above, for example).

But, great job so far, this should make it just a bit easier to add a license
to your repos.

~~~
joshschreuder
If you type LICENSE into the filename box, Github provides a dropdown of
licenses to choose from.

[https://i.imgur.com/opCBKHT.png](https://i.imgur.com/opCBKHT.png)

With that in mind, it would be nice if the Put A License On It site could open
to the create screen with the filename filled in with LICENSE.

This can be done using the following URL pattern:
[https://github.com/[user]/[repo]/new/master?filename=LICENSE](https://github.com/\[user\]/\[repo\]/new/master?filename=LICENSE)

------
brandonwamboldt
It's actually been out for a couple of weeks, see the blog post from March
9th: [https://github.com/blog/1964-open-source-license-usage-on-
gi...](https://github.com/blog/1964-open-source-license-usage-on-github-com)

------
michaelmior
Previous discussion
[https://news.ycombinator.com/item?id=9173171](https://news.ycombinator.com/item?id=9173171)

------
kijin
The quibble about GitHub not correctly handling files named COPYING is spot
on. I have some LGPLv3 projects, and whenever possible I put the license into
two files named COPYING (a verbatim copy of GPLv3) and COPYING.LESSER (an
addendum that converts GPLv3 into LGPLv3). Because that's what the FSF
recommends. I have no idea how GitHub's crawler will interpret this. Maybe it
only sees the first file and thinks I'm using GPLv3?

Anyway, the whole "scan the repository for anything that looks like a license"
approach seems to be misguided from the beginning. What if the license is in a
comment at the top of an ordinary source file, as I often do with short
licenses like MIT? What if it's just a link to the FSF or opensource.org? What
if it's a translation of a popular license into another language, or a link to
a translation? What if the only file that contains a license is a library with
a different license than what the owner intended? Approximations and second-
guesses are good enough if you're just trying to pull some statistics, but
open-source licenses have legal implications for everyone involved.

Just let me pick a license in the repository settings, not only for new repos
but also for existing ones. And if I do so, please display my choice
prominently in search results so that nobody will misunderstand my intentions.
I don't really care about the API, I want to see the options in the official
web interface. You are welcome to throw a warning if you detect something in
the repository that seems to contradict my selection. You are welcome to
suggest that I add a license file. But they should be suggestions, not
prerequisites for GitHub to recognize a license in the first place. The owner,
not some half-baked robot, should have ultimate authority over what the
license is.

Bonus: Forks automatically inherit the license of the original repo, unless
the forker explicitly picks a different one. First-time pull requesters are
informed that their patches will be licensed under the same license as the
repo, and by clicking "Submit", they agree.

~~~
pjtr
I really like your bonus idea. But it's surprising that after you explain how
complex licensing scenarios can be you still recommend to force a very
inflexible single-license-per-repository model. What about dual licensing?
Differently licensed code in the same repository? (e.g. for vendored third
party code etc.)

~~~
kijin
Dual licensing is fine, I simply omitted it from my suggestion because it
didn't occur to me at the time.

As for third-party code included in a repo, I don't think their licenses
should be shown prominently on any listing. It's the job of the project
maintainer to ensure that all of the licenses for third-party libraries are
compatible with the main license(s) for the project, and if possible,
enumerate them somewhere in the tree. Most third-party libraries probably have
their own GitHub repos anyway.

------
andrewchambers
I think the real reason there are so many without licenses, is because most
projects on github are just a few commits and then abandoned. They are just
created as a quick hack or experiment.

The popular ones with many users seem to all have a license.

------
rgarcia
I open-sourced a tool a few days ago that lets you do mass modification of git
repos, including (but not limited to) adding license files:
[https://github.com/clever/gitbot](https://github.com/clever/gitbot). I've
used it to add licenses to close to a hundred repositories at Clever. Would be
great to see if others find it useful.

------
prayerslayer
I collected the most popular repositories and their license. This post
includes a CSV dataset which you can process yourself:
[https://npiccolotto.com/2015/03/licenses-of-popular-open-
sou...](https://npiccolotto.com/2015/03/licenses-of-popular-open-source-
software/)

------
task_queue
It will be interesting if they ever pursue providing a way to enforce licenses
and IP.

If a user browses or pulls repository A and releases repository B, which is
found to be violating A's license or IP, a log could provide evidence of
culpability.

------
teamhappy
Does anybody know where the license texts come from? Copy & paste from the OSI
website? In other words: Are they equivalent?

(The OSI is part of the SPDX workgroup, but that doesn't really answer the
question.)

~~~
icebraining
They seem to be using the same licenses they used in choosealicense.com, and
those are hosted in this repo[1] and have source information embedded.

[1] [https://github.com/github/choosealicense.com/tree/gh-
pages/_...](https://github.com/github/choosealicense.com/tree/gh-
pages/_licenses)

~~~
teamhappy
The ISC licenses from choosealicense.com, the SPDX site, and the OSI site
differ (very very slightly.)

------
avinassh
link to API -
[https://developer.github.com/v3/licenses/](https://developer.github.com/v3/licenses/)

------
pepijndevos
I never put a license on any of my small projects. I'm the kind of person that
happily combines incompatible projects. I simply don't care, and neither does
anyone else.

Once my projects gain traction, issue #1 is usually "add a license". I add
whatever the reporter wants.

The bottom line is that any project with actual users has a license.

------
dwyer
> one of the leading complaints being that it takes a lax approach to software
> licensing

I never understood this criticism. There's plenty of software I haven't bought
a license for. I don't feel that just because somebody shares their code or
archives it in public that I'm entitled to a free license.

That said, I've been approached on Github about licensing my code and I'm
happy to grant one. For the most part, however, I just dump code to Github
because it's a convenient way to backup and dealing with licenses just creates
friction. I'd rather know that somebody out there explicitly wants the code
before dealing with it.

~~~
kijin
Of course nobody is entitled to a free license.

But if somebody posts code on a website where most of the public content is
under free licenses and the TOS explicitly dictates that you grant certain
licenses to other users for free, I think we can all have a reasonable
expectation that the code in question will also be under a free license. And
if the expectation is broken without a clear indicator, that's a recipe for
confusion.

~~~
dwyer
> most of the public content is under free licenses

Is it? I've read reports that all but a fraction of Github repos are single-
commiter code dumps.

> the TOS explicitly dictates that you grant certain licenses to other users
> for free

Where?

[https://help.github.com/articles/github-terms-of-
service/](https://help.github.com/articles/github-terms-of-service/)

The only stipulation I see is:

> By setting your repositories to be viewed publicly, you agree to allow
> others to view and fork your repositories.

Unfortunately, the TOS doesn't provide a clear legal definition of fork. Does
it go beyond clicking the fork button and copying the repo across Github
servers? Does it including cloning the repo to a local disk? Or running the
code? Or maintaining a derivative project?

