Why I’d like a “license type” setting for GitHub projects
mir.aculo.us
mir.aculo.us
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.
For complex situations, you can always choose "other". As stated in my article, this isn't a replacement for a project's LICENSE file.
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.
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).
The gradation of rights and privileges goes farther than "Public Domain, Sort of Public Domain, Restrictive".
The best way is to just have a dropdown that lists the name of the license.
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
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.
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.
> 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.
The fact that it implies that you cannot disallow users to produce and distribute additional copies is the whole point of GPL.
What a benefit for them.
Copyleft licenses really don't seem to be a problem unless you're trying to make something proprietary?
Unless I'm missing some other restriction...
These restrictions may be for copyleft, for benefit of end users, pro bono, for whatever else, but there are restrictions, and the term "restrictive open source" captures the essense of this license.
Also, these restrictions won't disappear no matter how low your (or mine) comment is downvoted here on HN.
I could see that holding true among the general population, but among developers? What developer who's going to be browsing Github doesn't know what copyleft means?
There are more restrictions.
Yes and no. Even licenses like the Apache License do impose restrictions of sorts, and the whole "permissive" vs "restrictive" thing is hardly a binary proposition. It's a continuum... and that's not even considering that saying "restrictive" raise the issue of "restrictive for who?" Yes, arguably the GPL is more restrictive in terms of how a developer can interact with GPL'd code, but from an end-user perspective the GPL is "more free" in a sense.
All of that said, I get the point behind a simple binary "restrictive/permissive" flag, and I think most people would intuitively grok the general sense of it. I'm not opposed to it, but I think we could do better.
Hmmm... that raises an interesting point... does Github have any sort of notion of explicit support for DOAP[1] files? Encouraging people to use DOAP files might be a better answer anyway.
This is an important point. How many people know that they should list their changes when using EDIT:Some licenses or the patent stuff in the Apache license etc...
These tags don't really make sense.
Exactly. That's a great example of what I had in mind. Nobody talks about it, but that stuff is there and is important.
For example, both GPL and CC-NC are "restrictive", but GPL is "copyleft" while CC-NC is not.
Also, "copyleft" would somehow suggest compatibility, but this is not the case: GPL and CC-SA are definitely not compatible, so "restrictive" would also be a good adjective in that case.
Licenses are complicated, and what people want to do with code is complicated too; "restrictive" vs. "permissive" cannot be defined well. "copyleft" represents a well-defined, understandable concept; while not without edge cases, it makes it fairly clear what kind of license we're talking about.
Categories which are dependent on the user's own viewpoint are not suitable for a wide audience because the people are too different.
It's a difference of priorities. Which aspect do you think is more important? You value different things higher than others.
The license needs changing. It isn't protecting anyone with the requirement that the binary that someone gets isn't DRMed. There are many software channels (Apple, Xbox, Sony/PS3, Nintendo, just to name a couple big names) that don't have a DRM free way to run them.
IMHO. :-)
It's pretty much a pipe dream of course...
Many parents love that part of it.
All questions that were answered over a decade ago by sites like SourceForge. Though not perfect, their solution was using tags for each license, and letting developers tag their project with multiple licenses (among other attributes, like language used, development state, etc.). This tagging system was called the Trove system, but since a software company has named itself "Trove Software", my last few Google queries didn't lead me to the origins of the system, only Freshmeat and SourceForge's references to the name.
http://sourceforge.net/apps/trac/sourceforge/wiki/Software%2...
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.
Yes. But what I ‘hate’ even more is not finding any license info. Adding this would probably help in that area as well.
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.
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.
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.
The downside is, of course, that you probably need it at the time you come across it, so time wise I often have to roll my own in these cases. That’s why I hope this would make that more clear.
On that note, we need this for gists as well (maybe even more). Could be on an account-wide basis in my case.
On the other hand, I have asked several developers who released code without a license if they would mind licensing their code under a permissive license, and each time they have been glad to do so.
Just some anecdotal data...
A lot of people just forget to put up a license. I file a polite bug with the project, and they generally fix it within a day or so.
My point goes further than people forgetting to add a license, though. Some people think that just adding it as an open repo to GitHub is enough, which, depending on the country, it clearly isn’t.
In my opinion, GitHub should educate people a bit more about this. A simple feature like this could just be enough.
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.
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.)
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.
I've learned through much harsher experiences than the one you describe that life is unfair.
You're using free code off the internet. If you don't like the license terms, don't use it
It is a common myth (propagated by anti-GPL activists) that using GPL'd code in your software requires you to put your software under the GPL. In reality, your code can be under nearly any open-source license.
I often receive emails from users asking me to re-license one of my libraries from GPL to BSD/MIT so they can use it in their own open-source projects. These users are often confused when I tell them that they can have a BSD/MIT project depend on GPL'd code.
Everyone who cares about the health of Free software (and open-source in general) should be careful not to fall prey to this misinformation campaign.
When people are concerned about including GPL in their work code (as the OP is) then they are typically concerned with issues of linking/importing/etc.
As far as I understand, the viral nature of the GPL does not allow this.
If you copy and paste functions into your code, then those functions are still under the GPL, and your code is still under the BSD.
Anybody could then copy and paste your BSD code into their proprietary software, and only have to conform to the BSD licence's requirements.
The main issue with this is that it when you mix code from various sources in the same file, it can be very difficult for readers to know what licenses each section of code has. For that reason, when I need to include code which has a different license or copyright from the main work, then I put it in its own file with its own copyright/license header.
1. You can't change the license on other people's code.
2. Other people can't change the license on your code.
-----------
1.
If you fork an application licensed under the GPL, and you make some changes, the original code is still licensed under the GPL. You may not distribute it under the BSD or MIT licenses.
If your changes are big enough, you could maybe license just those under a more permissive license, but then your final product really has two licenses (see case #2).
-----------
2.
If you fork an application licensed under 3-clause BSD, and you copy code into it from both a GPL'd library and an MIT'd library. The application's code is still BSD'd, but your project itself is now derived a derived work of three separate projects (with three separate licenses), and you will need to obey all of them:
* You will need to include the licence text and copyright information of all three projects (required by GPL BSD MIT)
* You may not use the names of the original application's authors to endorse or promote your work (required by BSD). You may use the names of the GPL or MIT library authors (permitted by GPL MIT).
* Anyone who compiles binaries of your project, including yourself, will need to include the complete corresponding source code (required by GPL).
-----------
Note that there's a difference between having a choice between multiple licences (aka "dual-licensed", "multi-licensed") and having a codebase covered by multiple licenses.
> The GPL is the first copyleft license for general use, which means that derived works can only be distributed under the same license terms.
Overall, even if you're complying with the GPL (using the software in an approved manner), it's not usually worth the hassle of proving you're complying with the GPL _in a way that is legally defensible_.
The FSF's position as of November 2010 is that you can't comply with the GPL's terms if you distribute that code as part of something else on the iOS app store.
http://mailman.videolan.org/pipermail/vlc-devel/2010-Novembe...
Perhaps that has changed, but I doubt it. Binaries are still encrypted, still tied to a specific account, and still can't be re-distributed as the GPL specifically requires, because they won't work.
I don't want to argue the commercial vs open, 'stealing code' vs giving back thing all over again, those are just the facts. According to the people who wrote the GPL, it can't be used on the App Store, so I avoid it when working on something for that platform.
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)
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.
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.
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.
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.
So you end up with a lot of badly marked or unmarked open source, which isn't great.
Without license information you MUST assume full copyright sadly.
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.
[1]. http://creativecommons.org/choose/
*edit - this way it could just be an open source project instead of waiting for github to implement it.
How would you solve this problem?
https://github.com/tantalor/detect-license
Looking for contributors to add more implementations (JavaScript, Ruby, etc), examples license files, and tests.
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.
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.
"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.
Paying for sources, sounds an awful lot like proprietary software. Pay for binaries, sure... sources shouldn't be withheld and should be available for a nominal fee, which in the case of GitHub and others, is $0.
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)
[1]: http://en.wikipedia.org/wiki/Copyleft#Strong_and_weak_copyle...
You can't use GPLed code on Apple, Nintendo, Sony or Microsoft gaming platforms due to the binary copy restriction.
My personal take would be to limit it to: 1. licenses that are certified by the OSI, and 2. licenses listed as "GPL compatible" by the FSF, assuming that (2) isn't just a subset of (1) anyway.
That would include by far the majority of popular and widely used licenses. Maybe have an "Other" field for anything else?
However, if your objective is to convince people of an idea, then you should consider that some opinions are beside your point, and don't need to be expressed. These really are two completely different objectives, and sometimes, if your objective is to persuade and explain, then you have to omit certain opinions of your own which will detract from your point.
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.
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...
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.
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.
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.
So no, it isn't so interesting.
I got distracted by the way he wrote the post.
Edit: typo
Because my issue is the sheer length and complexity of the GPL; I have read it and I do not pretend to understand it, and I don't personally as a developer want to release under a license whose implications I don't really understand. The problems just start with Section 1 and accumulate from there.
For me, the nastiest part is not really the copyleft or DRM so much as the no-linking aspect of GPL. I still don't know what precisely constitutes "linking". I don't know whether Python is in violation of the GPL because the standard library has a readline module, and I don't know if my own code is in violation of the GPL because it's written in Python. GPLv3 actually made this point a little clearer; in GPLv3 you would say "Python as a whole plus its readline library is probably GPL, but as long as you don't write 'import readline' you could probably release under something else instead." Now that there is a BSD version of readline called editline, I wonder if even that analysis holds. But the GPL makes even this analysis complicated, because if Python forgot to mention that the whole package was GPL, then actually their license to readline can potentially be revoked at any time by the readline copyright holders.
And there are some nasty parts too, like the ongoing incompatibility between the Eclipse Public License and the GPL. You now have people explaining how to get readline and wrap Clojure in a readline interface (which is allowed) because Clojure presumably isn't allowed to connect directly to readline in its own REPL.
LGPL, at least, I don't have to worry about this crap when building an application which uses yours as a tool. You can license under LGPL if you really think that GPL's legal phrasing is absolutely magnificent and you love it. I don't want to release under such an ugly license myself, and GPL forces me to violate my aesthetic principles.
So, never mind, some guy whining about GPL over here. (whistles aimlessly.)