Hacker News Reader

Exactly. The choosalicense site is designed to be neutral enough to avoid overt bias. It wouldn't work if it didn't appear neutral. But it is not neutral.

First of all, it says that the main default simplest license should be the permissive one. It chooses that first on purpose. Second, they say that you should use Apache if you care about patent issues when actually GPLv3 is arguably superior for that. So, they worked to actively relegate GPL to the last choice.

And you picked out the small text. The big text is "I care about sharing improvements" — what does that mean? It's much more wishy-washy than "I want to block the code from being used in proprietary projects" or "I want to require that derivatives stay free". The motivation behind the GPL is about freedom, not about improvements. But GitHub doesn't want to talk about freedom, they only want to talk about code improvements.

Anyway, it's already aggressive to encourage people to use GPLv2 instead of GPLv3, given that v3 specifically closes loopholes that GPLv2 has.

Anyway, it's not a lie… watch https://www.youtube.com/watch?v=-bAAlPXB2-c to hear the GitHub co-founder explicitly tell people to reject the GPL in the very presentation in which he announced the choosealicense site.

I think the text for GPL is much more discouraging than the others ...

How about: "The GPL (V2 or V3) requires anyone who distributes your code - or a derivative work - to make the source available. V3 is similar to V2, but it also demands that, whenever the code comes "pre-installed" in a device, the user can run a modified version in the device"

Or even: "The GPL (V2 or V3) requires anyone who distributes your code - or a derivative work - to make the source available. V3 is similar to V2. Only worry about the difference for code that comes "pre-installed" in a device"

Those edits are completely insubstantial. #1 is basically s/restrict/demand. #2 completely obscures the actual differences with a "don't worry about it" handwave.

The GPL is objectively a more restrictive license than BSD/MIT/Apache - just because you think the word "restricted" is ugly doesn't change this rather uncontroversial fact.

the GPL restricts the developer more and forbids restrictions on the user. Just saying it is more "restrictive" does not clarify that

(and yes. If you dont know if you want MIT or GPL, "dont worry about" V2 vs V3)

Trying to paint that line is a bit too politically minded for my tastes. From the perspective of choosing a license for your GitHub project, GPL is restricting the consumers of your project (other developers). Attempting to explain the purpose of those restrictions will just make this less clear.

The GPL is a political weapon, designed and built for a political purpose: to fight the venal and short-sighted policies of software producers (companies and developers.)

The "purpose of those restrictions" is the whole and entire point of the GPL. If you don't explain (to users or developers) why the GPL restricts distribution of code and future changes the way it does, well, you might as well just not mention it at all.

I think josinalvo has a point. Can we at least agree it's not the most likely wording that the FSF would have chosen? So while "discourage" might be too strong, it's likely not a favorable way to put it. Perhaps a pull request would be welcome?

Sure! But consider that the whole point of choosealicense is to be non-judgmental and to explain facts, and the facts are not in question here. Saying that the GPL is more restrictive is not some slight against the GPL, it is a forthright explanation of its attributes.

Furthermore, the FSF are precisely the last people I'd go to for a forthright and non judgmental description of the GPL and its purpose. The FSF is at least a primary source in this matter, and furthermore an advocacy group.

If the point of choosealicense is to be non-judgmental, they should use non-judgmental language to do so.

So lets change the "I want it simple and permissive" text to "I want attribution. The MIT License only requirements is that users provide attribution back to you and don’t hold you liable."

Its a forthright and non judgmental description of the MIT license and its purpose, and it matches perfectly with the style of the GPL description.

“[…] to make the source available under the same terms.”

You are omitting what is probably the most important part of the GPL.

I agree that this is the most important thing to know about how the GPL works.

I disagree that it is an important thing about what is its intent

I disagree: the intent of the GPL is to preserve freedom; the way the GPL preserves freedom is by preventing you from removing it by changing the terms.

If I'm choosing a license for a project, it's important that I know that changes other people make will be available to me under the same terms as my own code.

A license that requires you to make the changes available but allows you to restrict my use of those changes is plainly in contrast with the intent of the GPL.

I'll try another rewording: "GPL is a license designed so that, no matter how many times people alter your code, a user that gets the program also gets the source code. To do that, it forbids developers from using your code in some contexts."

better ?

(sure, there is a tradeoff between comprehensibility and precision ...)

If you want to propose improvements, stop accepting the V2 or V3 nonsense. Telling people to use an old version is an aggressive rejection of the new version. Adding extra version choice is a subtle way to make it more complex and even less likely for people to choose the GPL overall. V3 is an improvement over V2 in basically every respect — unless you like the loopholes in V2 or are worried about compatibility with V2-only code.

> Github without distributed commits isn't based on git anymore, and the other stuff is ancillary (and also easily exportable)

I don't think issues and PRs, along with all the comments on them, are ancillary.

Github does make it easy to export that data, but then it's not necessarily easy to bring it in somewhere else and keep using it. That's not Github's fault, but there is definitely a degree of lock in.