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.
No. "Restrictive" vs. "permissive" captures exactly the relevant information. If I look for some code to include in my project, I don't care if the license is "copyleft" or "copyright" or whatever. I just need to know if including the code puts legal restrictions on my project.
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.
Those are still biased terms, similar to how people highlight the positive for characterizing their political stances. (I've never met someone who considered themselves "anti-life" or "anti-choice.") Someone could equally say that what you call "restrictive" licenses are "freedom preserving."
I don't understand how anybody can complain that "restrictive" is a bad adjective for a license that contains hundreds of restrictions. "Freedom preserving" sounds a bit like Orwellian double speak.
Consider the other viewpoint: "I don't understand how anyone could complain that a license which ensures that users maintain all freedoms to modify the code as 'restrictive.'"
It's a difference of priorities. Which aspect do you think is more important? You value different things higher than others.
The BSD license prohibits you from falsely claiming authorship of the code it covers, so I guess that's going to be filed under "restrictive" too?
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.
It might be difficult to find a formal and logically coherent definition of "restrictive" vs. "permissive", but I was thinking in more pragmatic terms. Like with porn, "I know it when I see it". As I see it, required attribution somewhere in the docs is not very restrictive. On the other hand, 20 pages of legal mumbo jumbo concerning distribution are restrictive.
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.
The problem is, what do you do about dual/multi licensed projects, or projects which contain code that's under a mixture of licenses?
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.
They are restrictive: It is impossible to release Apple Mac Appstore or iOS Appstore with them even if you release your source, as the binaries can't even have DRM on them even if you're giving away the source.
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.
Isn't that precisely the point of the GPL? To create as much software as possible that cannot be run in DRM environments so that eventually it's the DRM environments that have to die?
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.
> 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.
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.
I've done this twice with GPL code, when I was writing a library and/or library bindings that I specifically wanted to be available for use by all developers, including those working on proprietary products. Both times I've been turned down. One of them was a abandonware. Great C code that the author explicitly disowned. Now it will bitrot.
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.
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.
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.
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.
That’s what makes it so annoying, though, the fact that we _know_ they probably meant to share it as free software.
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.
I don't think 'giving back' is the only practical difference with the GPL even if you open source your own code and hand it out freely.
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.
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.
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.)
"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.
>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.
It is indeed the whole point of the GPL. It also makes it impossible to use GPL code in a wide variety of situations. OP was asking what the problem was with the GPL, and that's what it is.
No, this is not true. If you include GPL'd code in your code, then your code's license is unchanged. You do not have to license your code under the GPL just to use GPL'd code.
No, the GPL linking exception exists to allow proprietary code to link against GPL'd code.
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.
It depends on what sort of "derivative" it is. Follow these two simple rules of thumb:
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.
Perhaps I was not clear, but I was saying the same thing as your first sentence.
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.
So are you saying I can copy and paste some useful functions from your GPL code into my BSD code? And then the next person can use my code (with the pasted code from your project) in their proprietary software, given they stick to the requirements from my BSD license?
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.
Having anything with GPL in it in a startup is a red flag during diligence. Goes double for Enterprise level. For that reason, most companies won't use GPL software or, if they do, they have it all "fire-walled" from all their other software. The fear is that someone inadvertently includes it in the companies other code and causes a huge legal mess. Or you patch something, and now you need a way to open source stuff -- companies are built to prevent code from leaving, getting stuff going the other way is a bureaucratic nightmare.
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_.
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)
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.
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.
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.
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.
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.
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.
One obvious solution is for github to autodetect the license if a LICENSE file is present. This will work in most cases, most people just copy&paste one of a small set of licenses.
Yeah it's just unfortunate. It's effectively like attempting to distribute a broken library. People simply can't use it, and even though it may have had the workings of a good solution for many people, you're just not going to get any users/contributors. shrug
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.
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.
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?
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).
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.
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).
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?
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.
"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.
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)
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]
> "Restrictive": anything that is GPL or requires you to pay for or share all sources
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.
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.
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.
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.
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.
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...
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.
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.
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.
Absence of test cases? Surely this is not a function of the license in use, correct? There can be shitty BSD-licensed swill with no test cases just as easily as there can be that as GPLv3.
You haven't been browsing HN long enough. People go off on rants about the GPL restricting their freedom and just generally being evil all the time, has nothing to do with corporate lawyers.
Sure, but consider: what is your objective? If your objective is to express your opinion, then say things however you want, and if people react negatively, then tough.
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.
1) his blog content isn't software
2) the general issue with GPL isn't copyleft; it's the patent clauses (in GPLv3), and all of the various distribution requirements, plus the essential forbiddance of DRM (in GPLv3)
At the risk of coming off as one of the maligned "personal opinion" people, I have to object a little to (2). That may be the general issue, I could agree, but it's not my issue.
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.)
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.