Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade license to GPLv3 #918

Merged
merged 1 commit into from
Apr 18, 2020
Merged

Upgrade license to GPLv3 #918

merged 1 commit into from
Apr 18, 2020

Conversation

wren
Copy link
Member

@wren wren commented Apr 18, 2020

The MIT license is old and doesn't provide much protection for modern open-source.

This change has been cleared with @maebert (as the original maintainer).

@wren wren force-pushed the upgrade-license branch 3 times, most recently from 2219b18 to 9562db1 Compare April 18, 2020 20:18
micahellison
micahellison previously approved these changes Apr 18, 2020
Copy link
Member

@micahellison micahellison left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯

The MIT license is a bit outdated, and doesn't provide the protections
we'd like in a modern open-source application.

Co-authored-by: Micah Jerome Ellison <micah.jerome.ellison@gmail.com>
Copy link
Member

@micahellison micahellison left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯💯

@wren wren added the enhancement New feature or request label Apr 18, 2020
@wren wren merged commit fae7585 into jrnl-org:develop Apr 18, 2020
@wren wren deleted the upgrade-license branch April 18, 2020 20:31
@StanczakDominik
Copy link

The MIT license is old and doesn't provide much protection for modern open-source.

I'm curious - care to expand on that point a little, if it's not much of a hassle?

@MinchinWeb
Copy link
Contributor

Hi @wren, @micahellison,

I'm not sure this is an upgrade. I would prefer we stick with the MIT license. That is what I use for my personal projects, whenever possible, and seems to have served jrnl well till now.

One of the features I like about the MIT license is that it's short enough (21 lines) and clear enough that I can understand it and feel comfortable about where I stand legally. I'm not a lawyer, but I've dealt with reasonably complex business deals, and so feel somewhat legal competent. But I've read (or tried to read) the almost-700 line GPL text, and find myself running into a surprisingly large number of unclear edge cases, and the shear number of them can make me nervous.

I also think that the ability to change the license like this (from MIT -> GPL with a single commit) is a feature of the MIT license that the GPL lacks. I've been around a couple of discussions about going the other way (from a copyleft license to a "permissive" license) and the change typically either is nixed before it gets started because of the potential work to try and bring every former contributer onboard, or the change withers after a couple of years because every contributer has a veto on moving forward. I don't think this is a feature that should be discarded lightly.

I'm also not sure what the change is trying to protect us from? To me, it seems that most of the additional protections in the GPL are about protecting a business model or protection against someone else's business model. Have you somehow turned jrnl into a business? (If so, that's wonderful! and I don't think Open Collective counts, at least yet.) Has someone else turned jrnl into a business?

Finally, because I can't write better than this talk (Open Source Beyond the Market by David Heinemeier Hansson, aka DHH), I'll quote it here, a bit at length:

The MIT license to a large extent is the anti-license. The utopia of socialized programs, one that embraces the lack of marginal cost for software goods.

It’s an explicit rejection of the strong-property rights approach taken by both Gates and Stallman at their respective ends of the libertarian spectrum.

It’s the language of giving without expecting anything in return. It’s the language of sincere charity. A charity without strings attached, neither commercial nor reciprocal. With the risk of sounding sanctimonious, I read it as a pure projection of altruism.

It’s kinda funny to analyze the MIT license from this perspective, because I do remember feeling the pull of a primordial debt to the software community when I started Rails. A motion to give back now that I had something to give. I was born into the software community through the grace of open source, and now I had the opportunity to participate as a contributor, and it felt wonderful.

But it felt like that exactly because there was no sword hanging over my head. Nobody telling me that this is what I ought or had to do. No one expecting me to do it. So it was an act of volition rather than one of duty. A truly authentic choice.

That to me is freedom.

[...]

Open source, as seen through the altruistic lens of the MIT gift license, has the power to break us free from this overly rational cost-benefit analysis bullshit that’s impoverishing our lives in so many other ways.

It’s a lens that isn’t smudged by the tragedy of the commons. [...]

To borrow a phrase from Stallman, “free labor” under free as in freedom, not free as gratis. Free from demands, free from debt, shame, and repayment.

And, this part I’m still working on, free from having to sell. To reject measuring my worth in the same bullshit measures of engagement that’s driving the wider world off a cliff.

Free to pursue intrinsic motivation from a quest for autonomy, mastery, and purpose that isn’t shackled solely to employment or business.

Free to reach for the self-transcendence that lies in giving away the best of what you got and asking nothing in return.

In short, I feel like moving from the MIT license is giving up something of innocence and wonder, and I'm not sure I'm getting anything back.

I hope you'll reconsider. Thanks.

@wren
Copy link
Member Author

wren commented Apr 29, 2020

Yup, happy to explain my reasoning.

I have a few concerns about the more permissive license like MIT. I like their spirit, but in practice they lead to some issues that I won't go into here.

My main problem is that it provides no protection for a project. What I mean by this that anyone can walk by, take the entire codebase, make it closed-source, slap a "My Awesome Product" label on it, and build an entire closed-source business off of it without ever even acknowledging the original project.

The GPL fixes this. If you use a GPL open-source project to build your own project, you have to make your project available as open-source, too. This doesn't affect open-source projects that are already sharing and sending their contributions upstream, but this definitely stops anyone that is looking only to take and take without contributing anything in return.

In short, the biggest win from the GPL in my view is that it's a guarantee to our contributors that--no matter what happens with the codebase in the future--their hard work won't go unacknowledged.

That being said, I hear you that the actual text of the GPL is a bit... verbose. Github provides a tl;dr at the top of the page when viewing the license. And gnu.org provides a breakdown of the license, and an FAQ. Do you think we should provide some more links to more average-reader-friendly explanations?

@travankor
Copy link

@wren

Could you clarify the licensing?

Here it says GPL-3.0-only, while in cli.py it says GPL-3.0-or-later.

@eshrh
Copy link
Contributor

eshrh commented Jun 14, 2020

This is good to clarify.

The GPL isn't about open-source. It's about free/libre software. The GPL ensures that the freedom the authors intended end consumers to have with the software will always be preserved. Personally, I hate proprietary software passionately, so I see every GPL'ed project as a step in the right direction. I would hate to see my or anyone else's contributions subverted in any way into a program from which other people make money by restricting the freedoms of users.

I generally don't have a preference between only/later, but I do have a great amount of trust in GNU and the FSF to preserve software freedom to the greatest extent possible, which they have treated well.

wren added a commit that referenced this pull request Jul 25, 2020
The MIT license is a bit outdated, and doesn't provide the protections
we'd like in a modern open-source application.

Co-authored-by: Micah Jerome Ellison <micah.jerome.ellison@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants