

Why I’d like a “license type” setting for GitHub projects - madrobby
http://mir.aculo.us/2012/04/05/why-id-like-a-license-type-setting-for-github-projects/

======
mindcrime
For "GPL type" licenses, it would probably be better to use the term
"copyleft" rather than "restrictive" since their copyleft nature is really
what's particular about them.

That said, I'd almost prefer a setting that lets you specify the exact
license. The problem is, what do you do about dual/multi licensed projects, or
projects which contain code that's under a mixture of licenses? I suppose you
could argue that it refers to the "dominant" or "main" license, but - to be
pedantic - you can't always describe a project as being under one single
license.

~~~
madrobby
Many people don't know what "copyleft" is, so "restrictive" makes more sense.
There are more restrictions.

For complex situations, you can always choose "other". As stated in my
article, this isn't a replacement for a project's LICENSE file.

~~~
pygy_
Prepare for an uproar if an entity the size of GitHub summarizes the GPL as
"restrictive".

The GPL enables freedom for the end user, who's entitled to obtain and modify
the source of the programs he uses. It offers some protection against
repressive governments and monopolistic companies, a much broader scope than
what permissive licenses enable (freedom for the developers).

"Copyleft" is well defined and easy to google. Education doesn't hurt people.

~~~
madrobby
So what if there's an uproar? Other license writers could also want to be
treated specially.

This is just about a general filter, into "proprietary", "do whatever you want
to", and "restrictive" open source licenses; for developers when they choose
which projects on GitHub might be a good fit for their needs.

If you read the GPL it puts a lot of restrictions on what you can do as a
developer. So do other licenses (for example licenses that allow you to use
the source in open source projects but require some form of payment when used
for commercial products).

~~~
pygy_
> _So what if there's an uproar?_

It would be boneheaded from a PR stand point, and it is insulting towards the
GPL.

> _Other license writers could also want to be treated specially._

You seem to have a serious gripe with the GPL. The GPL (its unnamed ancestor,
to be pedantic) is the mother of open source licenses. It enables Freedom,
with a capital "f" for its users, at the expense of obligations for people who
_distribute binaries_. Liberal licenses turn the situation around.

Labeling the GPL, but not liberal licenses as restrictive is heavily biased,
and simply does not reflect reality (since liberal licenses put implicit
restrictions on binaries recipients).

I speak as a license author, BTW: <https://github.com/pygy/The-Romantic-WTF-
Public-License>

~~~
gte910h
I'd love to release source, and USE gpl software, and even make a unsigned
binary available that if you could hack your own hardware to run, you could.
But even if I did, the GPL would prevent me from releasing said software using
GPLed libraries, as the actual binary they get has to be trivially copyable.
That's crap. That's restrictive. Why can't I supply you with an alternative
binary on a website just like I can with the source?

Restrictive isn't hate. It's a description. GPL licensed code is useless code
to people who develop for top tier gaming platforms other than the PC.

~~~
pygy_
_> I'd love to release source, and USE gpl software, and even make a unsigned
binary available that if you could hack your own hardware to run, you could.
But even if I did, the GPL would prevent me from releasing said software using
GPLed libraries, as the actual binary they get has to be trivially copyable.
That's crap. That's restrictive. Why can't I supply you with an alternative
binary on a website just like I can with the source?_

I'm afraid I don't understand your point... You can distribute GPLed software
as binaries, but you must provide the source on request.

Edit: Perhaps you mean that you want to release your source code under another
license?

 _> Restrictive isn't hate. It's a description._

My point is that all licenses are restrictive in a way or another.

Even WTF-type licenses or the public domain have implicit restrictions.

Singling out the GPL as restrictive is insulting, because its restrictions are
designed to enable the freedom for people to check the source code for
vulnerabilities or user hostile features (how many backdoors for the US govt.
are there in Windows?).

 _> GPL licensed code is useless code to people who develop for top tier
gaming platforms other than the PC._

... because of restrictions imposed by the SDK user agreement.

~~~
gte910h
Section 6 of GPLv2 says:

> Each time you redistribute the Program (or any work based on the Program),
> the recipient automatically receives a license from the original licensor to
> copy, distribute or modify the Program subject to these terms and
> conditions. You may not impose any further restrictions on the recipients’
> exercise of the rights granted herein.

This is the issue: You HAVE to put Fairplay on the programs (aka, drm, aka,
Further Restrictions).

It is not Apple's licensing agreement, but instead the uniform Fairplay system
on the device.

This is the same issue on Nintendo, Sony, and Xbox (although some platforms
have source provided libraries which likely would have to be GPLed as well,
and you can't under NDAs, the uniform DRM makes GPL2 incompatable with those
platforms).

GPL3 has changed this area, which I take to be admission of the flaw there.
Then again, GPL 3 added a ton of stuff people disliked as well, so it's
adoption is less than full.

You can meander back and forth that many licenses are restrictive or not, but
the GPL is designed to force certain actions from users of the code. That's
fine that they release their code that way, but the fact they're trying to do
more then get attribution and not get sued with the license, or even get fixes
back for their own parts of the code, means people should be warned about
this.

------
jballanc
More annoying than people that choose licenses in an uneducated fashion, are
people that do not choose a license at all. Under the Bern Convention, your
work is copyrighted by default. If you don't add a license, I cannot use it.
Period.

At the very least, it would be nice if Github could provide a warning to that
effect. Github is doing a wonderful job of growing the open source movement
from an infrastructure angle. I would love to see them also grow the movement
from a community/education angle as well.

------
phillmv
Why on earth would the GPL ruin your day? What's with all the fear mongering?

The only practical difference is you're forced to put up your patches
somewhere… which you've probably already done when you hit 'fork' on Github.

~~~
jakobe
I can't include code under GPL in my own code without changing my own code to
GPL. That's why it ruins my day.

~~~
phillmv
1\. This only kicks in if you're distributing the program. If you're building
a web service, you're good to go. It's only an issue if you're using the
Affero GPL.

2\. You're using _free code off the internet_. If you don't like the license
terms, don't use it. It's within the author's prerogative to set his or her
own license to his or her own code.

(The most you can do is send them a politely worded email on how you want to
use their code without being obliged to the virality clause - I imagine a lot
of people would be okay with moving down to the LGPL at least. If not… deal
with it.)

~~~
jakobe
"You are using free code". It's not free. The cost for this "free" code is
that I apply the same license to my own code.

Of course the original author can put whatever license on their code. But the
license effectively renders the code useless to me. Not because I dislike the
GPL, but because I use a different license.

And it's simply very disappointing when I see that someone has already solved
a problem I'm struggling with, and advertises their "free" solution, that then
turns out to be not free for me.

~~~
phillmv
>Of course the original author can put whatever license on their code. But the
license effectively renders the code useless to me. Not because I dislike the
GPL, but because I use a different license.

I've learned through much harsher experiences than the one you describe that
life is unfair.

------
superalloy
> Don’t you just hate it when you find some great piece of code on GitHub and
> then you realize that somewhere at the end of the README the frightful
> acronym GPL is ruining your good mood?

Yes. But what I ‘hate’ even more is not finding _any_ license info. Adding
this would probably help in that area as well.

~~~
orta
This happened to me yesterday, and it was the only type of code of it's ilk I
could find. Real shame, probably going to have to write my own version.

~~~
bmelton
Have you considered emailing the author?

I know that personally, I've relicensed code to be more permissive on request.
Of course, you have to ask, but sending an email might be less work than
writing your own version.

~~~
tommi
Does it make you more vulnerable to law suits if the author says no and you
decide to code/acquire something similar?

~~~
bmelton
Honestly, I don't know. I'd suppose it depends more on the sort of thing we're
talking about than anything. If it's something like "Obtvse", or a fully
formed system and you're copying it outwardly, then probably yes.

If it's a ilbrary that fetches RSS feeds as part of a larger system, I'm
guessing no.

Of course, it also depends significantly on the author. If it's a public git
repository, one assumes that it's something people wish to be forked.

Though I suppose an interesting experiment would be to publicly post closed
source code with a closed source license attached as honeypots and sue
everyone that forks / modifies your code base.

~~~
benmanns
Yes, however, GitHub's Terms of Service section F.1.
([http://help.github.com/terms-of-
service/#f_copyright_and_con...](http://help.github.com/terms-of-
service/#f_copyright_and_content_ownership)) specifies "By setting your
repositories to be viewed publicly, you agree to allow others to view and fork
your repositories."

I suppose you could write a license that allows others to view and copy your
code, but not make any modifications, as fork doesn't seem to be defined to
include modification.

------
simpleascouldbe
I think having a hard-coded drop down for actual licenses is a good idea,
because then we can do the searching and filtering you suggest.

I don't like grouping them into 'types'. I think that's too much of a value
judgement. Any enterprise's legal department is going to approve or disapprove
of specific licenses, so that's what developers like me will be looking for.

Potential issues: * Modified licenses (eg: JSLint's MIT + "do no evil" clause)

~~~
madrobby
A list of every type if license can't work, because it needs to be constantly
updated and people may want to write their own, etc.

That's why the general type makes much more sense for a quick glimpse if some
code is _probably_ suitable license-wise for your project.

~~~
metamattl
You're against the GPL, but you're okay with people writing their own new
licenses?

~~~
Sanddancer
If one feels that the license is flawed, then why not? It's possible to not
like the viral clauses for various reasons, such as incompatibility with other
viral licenses, but feel there is some issue, like patents, that are not well-
covered under the BSD license, for example.

------
huskyr
I was actually rather surprised when switching from Google Code to Github that
they didn't have a license option. Especially if you need code for a business
licenses are pretty crucial.

I don't like this idea however. It's too general. I would make the license an
input field with autosuggest with 10 or so of the most popular licenses (like
Google Code). If you have something funky you can still enter it.

~~~
metamattl
The FSF has a pretty decent list of licenses --
[http://www.gnu.org/licenses/license-
list.html#SoftwareLicens...](http://www.gnu.org/licenses/license-
list.html#SoftwareLicenses)

------
phaylon
GitHub already parses README files of various formats. I wonder how hard it
would be to just parse a LICENSE/COPYRIGHT file if it's available. This would
make sure the licenses are distributed with the code. If the license file
couldn't be parsed, a "Custom License" link to the corresponding license file
could be a good general fallback too.

~~~
technoweenie
GitHub detects the presence of README files by file name. It'd be pretty easy
to do that for LICENSE files too of course. Look for LICENSE, MIT-LICENSE,
etc.

The trick is actually identifying what type of license it is.

Pop quiz: What license is this?

<https://github.com/sinatra/sinatra/blob/master/LICENSE>

This problem would be perfect for a tiny ruby script like Linguist:
<https://github.com/github/linguist>. Just something simple that's given some
filenames and contents that can return the license type.

It'd also be nice to handle non software licenses, such as creative commons.
I'm not sure what the convention is for specifying that in Git repositories,
however.

~~~
insertnickname
That's the MIT license.

~~~
technomancy
MIT-X11 license to be precise; MIT has spawned a number of licenses.

------
jwr
If I could only spend all my karma on upvotes for this, I would.

I regularly look at various projects that I can use. And the _first thing_ I
check is whether the license is MIT/BSD/Apache/EPL. If it's GPL I won't even
look at it, if it's LGPL I _might_ consider it, but it would have to bring
huge benefits. If there is no license, I have to contact the author and ask
him to include one.

I'd love to be able to just set a filter "never show me any projects which do
not have a license in my preferred set".

Please note that I am not editorializing here, nor am I discussing any values.
This post is about facts and about what would make my life easier.

------
snotrockets
tl;dr: the author dislikes the copyleft nature of the GPL, and shoehorns his
dislike into what could be a useful feature request.

------
tptacek
And when the drop-down disagrees with the COPYING or LICENSE file...?

~~~
madrobby
The LICENSE or COPYING file in the repository wins, obviously. Also, not
everyone would set the setting. But it's a start.

~~~
tptacek
Just seems like a source of potentially expensive misunderstandings.

~~~
there
Sourceforge and Google Code have had these license options available to show
on project pages forever. I think it'll be fine.

~~~
tptacek
Fair enough!

------
alexyoung
I've been thinking about this for a while, because I write about several open
source projects a week and like to mention the license in my articles. It's
often hard to find the license: it might be in the readme, a license file, or
in a boilerplate comment at the top of a source file.

Sometimes a license file is included, but the name of the license is not, so I
have to try searching for fragments of the text to figure out what license it
actually is (I have quite a few memorised now).

It's possible GitHub could solve this by interpreting files intended for
packaging systems like package.json. For example, I occasionally find authors
of Node modules actually include a 'licenses' property in their package.json
but don't mention the license anywhere else.

------
orblivion
For that matter, perhaps Github could just treat the LICENSE file like magic
the same way it does README. It would have the added benefit of convincing me
to add a LICENSE like it did for README.

------
songrabbit
How about a tool that gets authorization from your github account and let's
you automatically upload LICENSE files to your project. The particular license
is based on user input, similar to [1]. Does something like this exist?

[1]. <http://creativecommons.org/choose/>

*edit - this way it could just be an open source project instead of waiting for github to implement it.

------
wolfgke
The problem is: there are Open Source projects that are a compilation of works
of different licenses that are sometimes more permissive in one term but less
in another one (see for example the table on
<http://www.osscc.net/en/licenses.html#compatibility> to see what kinds of
problems can occur).

How would you solve this problem?

------
tantalor
I started a project on GH with a starter python implementation:

<https://github.com/tantalor/detect-license>

Looking for contributors to add more implementations (JavaScript, Ruby, etc),
examples license files, and tests.

------
chj
Google code has a license type setting long ago. Github should get one too. It
definitely helps everybody, no matter you are a GPL hater or lover.

------
DannyBee
I would love this, but there are at least a thousand open source licenses.
Even if you limit it to licenses that have at least 1% adoption rates, you
still have at least 40 (there are more, i just stopped counting).

As such, this would be a confusing dropdown. A free form text field with
autocomplete (and synonyms, so if you typed "general public license", it would
still autocomplete GPL.

~~~
madrobby
The drop down has 4 entries. Please read the article again. :)

~~~
DannyBee
Even in that case, he's trying to classify 1000+ open source licenses into 4
categories, which doesn't really work out well without a dictator.

People have different views on what "permissive" is. Even if you told people
what they should choose for each license, they will still choose what their
ideology says is right about the license.

IE plenty of people will choose "permissive" for GPL.

I've spent an inordinate amount of time classifying licenses into ~4
categories for compliance at Google, so i know where this path leads :) In my
case, I can end discussions by fiat and say "this is how it's going to be".
When you have 1000+ different project owners who each get to make their own
decision, the field will become useless because you won't be able to tell what
it really means.

~~~
madrobby
It's actually really simple:

"Permissive": anything that is generally MIT/BSD/WTF/Apache 2.0

"Restrictive": anything that is GPL or requires you to pay for or share all
sources

Given that the vast majority of software use only one of a handful of
licenses, I think that's a non-issue (tho there may be edge cases, I agree
with that). For stuff that is not categorized, people can just put in "other".

(Do you have a list of those classifications btw, that would be useful.)

In general, a setting like this would likely raise awareness of people sharing
code that they should choose a license in the first place. Far too many useful
pieces of code on GitHub don't come with a license or copyright statement at
all.

~~~
DannyBee
Okay, so let's start simple: Where does LGPL fit into these two? (LGPL is in
the top 5 licenses, so it's important)

So, vast majority depends on how you look at it.

If you are talking about organized software projects, yes, the vast majority
use about 20 licenses (I cut off the count at 90%)

If you are talking about code that is out there and has a license marking,
"Other" is the #3 category, and we classify over 1000 licenses. (I hand check
a lot of these, and only about 1% are classification errors, not really
licensed, or munged).

So as you can see, the story is not great, particularly for people who want to
just take pieces of code.

Don't get me wrong, I absolutely and completely agree that things should be
marked with licenses and give people some idea of what they can do. I'm just
saying doing it usefully is not as simple as giving people 2-4 categories and
saying "have at it!"

As for the categories we have, our categories are based on what would be
required if the source is used in a product shipping outside of Google. The
categories have been mentioned publicly before, so i'll mention that they are
"notice", "reciprocal", "restricted", and "use by exception only" (IE you can
only use it if you talk to us first)

~~~
mindcrime
Right, and likewise for the MPL, which is a sort of copyleft license, but is
generally considered "weak copyleft" unlike the GPL, which is "strong
copyleft."[1]

[1]:
[http://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyle...](http://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyleft)

------
aa4hn
so many different versions of free. let's just have two licenses free and non-
free.

------
Manfred
I like this idea.

------
nknight
The unnecessary editorializing is annoying. The point, which I agree with,
could have been made without the self-centered snipes at licenses you happen
to dislike.

~~~
snotrockets
I'm usually in favour of modified BSD or a similar permissive license; but
whenever I read someone who is bitching about the GPL because it is too
restrictive (i.e. it forces them to give back as they were given,) I consider
only adhering to the GPL in the future.

~~~
stephencanon
I don't know anyone who complains about GPL forcing them to give back.

I know many people who cannot touch GPL3 code because of corporate legal
departments' fears (especially with regard to patent clauses) and the absence
of test cases, but who frequently contribute back to BSD/Apache/MIT/etc-
licensed projects.

~~~
gte910h
Or who code for the Xbox, Sony, Apple or Nintendo platforms, where you can't
turn off the DRM on your binary, so can't use GPLed code in your project even
if you release the entire project as source/art/whatever.

~~~
snotrockets
Copyleft tries to discourage closed platforms. As such, you wouldn't expect
Copyleft-ists to support those platforms by making developing for them
easier/cheaper.

They give you the carrot of free code; the stick is the viral nature of the
license. Expecting to reap the fruit without giving anything is best left to
spoiled brats, not clear thinking developers.

In fact, the FSF proudly claim that by keeping some libraries GPLed, instead
of LGPLed, they caused some software that used those libraries become FOSS,
where it wouldn't be released as such had those libraries been licensed under
a more permissive license.

PS You can not distribute GPLed software for Nintendo's platforms not just
because it would go against the GPL, but also because it would also go against
Nintendo's SDK license, which prohibits use of FOSS with their code. See:
[http://sev-notes.blogspot.com/2009/06/gpl-scummvm-and-violat...](http://sev-
notes.blogspot.com/2009/06/gpl-scummvm-and-violations.html)

~~~
gte910h
You can use most libraries on Nintendo, just not the GPL, because you have to
release source code that is nintendo IP.

I'm happy you've decided I'm a spoiled brat when I give back fixes, libraries
and presentations all the time, and this includes several Linux kernel
drivers.

Either way, the GPL is _intentionally_ restrictive, in part to thwart these
platforms you do not like, so perhaps we should label it so to be forthright
and honest with developers so they don't find out thousands of dollars later
in some GPL violation suit? Perhaps "Restrictive to persuade others to do
software our way"? Or just "Restrictive"?

Software was better before source was hidden away. While the LGPL has gone far
(and I contend the Linux kernel is far closer to the LGPL than pure GPL), the
GPL is still a bit too idealistic to fit the practical nature of some
projects.

~~~
snotrockets
I've stated earlier that I'm more of a fan of the BSD license than of the GPL.

But no matter what philanthropic tasks you or I may have done, in software or
otherwise, I don't feel as if others should make their code available to us
under my preferred license.

Therefore, unlike some commenters here, I don't bitch when I can't use a piece
of code due to its license, or go on tirades about how people release their
own work under a license not to my liking, even if I think they are choosing
the wrong license.

~~~
gte910h
I'm happy all of this is your opinion, but I haven't done any of those things

I just say "restrictive" is a fair description of the Apple appstore, Sony's
Approval process of the PS3 game catelog, and the GPL, and labeling it as such
is a worthwhile service vs permissive licences that almost everyone can use
the code of.

For a service such as github, which is about social coding, it's okay to point
out some people being idealistic and somewhat slightly less inclined to share.

