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 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.
For complex situations, you can always choose "other". As stated in my article, this isn't a replacement for a project's LICENSE file.
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.
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.
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.
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...
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...
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.
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.
So no, it isn't so interesting.
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.
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.
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.)
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_.
So you end up with a lot of badly marked or unmarked open source, which isn't great.
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.
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.
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?
Yes. But what I ‘hate’ even more is not finding any license info. Adding this would probably help in that area as well.
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.
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.
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 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.
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.
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.
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.
