Many people don't know what "copyleft" is, so "restrictive" makes more sense.
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.
"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."
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...
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.
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).
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'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.
> 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.
> 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.
GPL actually does not care about binaries, it only stipulates that if you are distributing binaries you have to distribute matching GPL licensed source code with it.
The fact that it implies that you cannot disallow users to produce and distribute additional copies is the whole point of GPL.
You do understand how there are people who would disagree with your characterization, and thus the more neutral term 'copyleft' is the most… let's call it politically-safe term to use. Let's not even touch lumping the copyleft licenses with non-commercial-only licenses.
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.
Yes, the GPL (specifically GPL2) is powerful enough to empower users on those systems to never have to worry about using a program with any GPLed code in it.
I don't understand why are you being downvoted, as GPL does actually impose some restrictions in comparison to BSD/MIT.
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.
For complex situations, you can always choose "other". As stated in my article, this isn't a replacement for a project's LICENSE file.