Hacker News Reader

Comment by j1elo | Hacker News Reader

About the choice of license (MIT): could you share your considerations about it? (if any)

It's a topic I'm interested in. Mainly to see examples (and learn from them) about when people prefer lax licenses on the style of "do what you want with this, including a closed-source proprietary business" (MIT, Apache) which has allowed in the past that big Co's. benefit from it without giving back (lots of cases in HN), vs. strong copyleft "do what you want except closed-source proprietary stuff" style (generally speaking, the GPL family -- EDIT: I know that this, being mainly a server-side thing, would be more affected by AGPL than by GPL. Bear with me.).

If there are no business / commercialization intentions in the foreseeable future, would it make sense to use a GPL license (one of them) to build a strong open-source community?

Or it doesn't matter in practice? (i.e. it doesn't really affect the chances of building a good and strong developer community)

View on HN

Would I like a strong open source community? Absolutely, could you fork this and make money off of it right now? No not even close. Maybe in the future I would consider a different license but at the end of the day if you take this and make it profitable good for you :) my goal wasn’t to make money

I am also pro-MIT. For me, "freedom" doesn't mean "restricting what users can do."

GPL restricts what users can do, and thus restricts freedom in my eyes.

Not sure why anyone would care but it seemed like a good time to explain my thoughts on that while agreeing with you.

This kind of thing has been needed for some time, so thank you for creating it.

Realize how I oriented my question around how it might affect building an OSS community.

A MIT or Apache license might detract contributors, because essentially these licenses say "your contribution is OSS today, but it might end up resulting as unintended free labor that helps build a commercial product of which you won't be part of".

However some see GPL licenses as a guarantee that external contributions are actually contributions to the overall Open-Source community as a whole, because they cannot be turned into other non-OSS product without explicit permission of all people who built it.

So yes, copyleft is more restrictive than non-copyleft. But only in the subtle sense of ensuring that no further restrictions will get added by any third party, ever. Which is a strong promise that should encourage contributions.

Ultimately, my objective is to learn if this theory matches the practice.

> because essentially these licenses say "your contribution is OSS today, but it might end up resulting as unintended free labor that helps build a commercial product of which you won't be part of".

Contributions to non-copyleft OSS licenses _are_ actual contributions to the open source community as a whole.

There's nothing preventing your GPL'd project from being used to make a commercial product that you are not a part of either. You're talking about enforcing perpetual conditions on the future of the product/license for your free labor. This is the reason why projects like MAME have contributor agreements now.

Even if through some process the license changes in the future, your contributions were still to an open source license and that version of the code will remain open forever.

I haven't seen anyone discouraged from contributing to OSS-licensed projects that are not GPL unless they are an extreme ideologue. I myself generally prefer to license my work with something like MIT or Apache (read: the ISC license, generally) and that choice is absolutely fine.

> There's nothing preventing your GPL'd project from being used to make a commercial product that you are not a part of either.

Copyright law does exactly this. The role of the GPL is to carve out explicit exceptions to the "you can't copy this" rights granted by copyright law.

A lot of people seem to confuse Commercial with Proprietary...

They are not the same.

Doesn't matter. Copyright, without the licensing exceptions, won't allow EvilCorp Inc. use your code even if you publish it in the clear on the internet.

Also, more relevant to the discussion I was responding to, the GPL license doesn't allow re-licensing without consent (or a pre-arranged copyright assignment - a contributor's agreement). And it's copyright law which enforces this.

Given past experiences, I see large group projects trending towards having CLAs/DCOs where you give up ownership of your code anyway.

Most people don't want to work with random contributors who wish to hold a gun to their heads in perpetuity.

DCOs don't give copyright ownership to anyone else or even any more rights to anyone else. It is simply a declaration that you have the permission to license the code you wrote under the license you're giving it for.

This article gives a nice description of the differences: https://opensource.com/article/18/3/cla-vs-dco-whats-differe...

> who wish to hold a gun to their heads

An aside, that's an awfully violent visual for discussing ownership of code.

True. Although in practice, the end-user freedoms that are guaranteed by copyleft practically destroy all, if not for a couple exceptions, of viable business plans.

So even if theoretically the most aggressive licenses still allow for commercialization, the practical effect is that commercializing a copyleft codebase won't travel too far on its own as a business plan.

This has been discussed a lot of times in HN, and the conclusion always is something on the lines of "don't do copyleft if you want to have any aspirations of commercialization on the software itself as opposed to peripheral elements such as support services or similar".

> So even if theoretically the most aggressive licenses still allow for commercialization, the practical effect is that commercializing a copyleft codebase won't travel too far on its own as a business plan.

Red Hat was acquired for $34 Billion.

It really depends on what you're selling and how good your product is.

> "don't do copyleft if you want to have any aspirations of commercialization on the software itself as opposed to peripheral elements such as support services or similar"

Cop out argument. This comes from the same people who do split licenses that spit in the face of the spirit of OSS. It's people who want all of the benefits of writing OSS (outside contribution, growth in use of your product, less investment in sales) but none of the risks (someone else using what you offer for free and having a better product than you). It's purely anti-competitive.

Redhat is the exception that proves the rule. How many more companies which relied upon selling services around GPL'ed code have died? Lots.

Canonical and SUSE are still around and have millions in revenue.

Turns out that Linux is a good product that needs a lot of stewardship and support that's worth paying for.

There's also hundreds of thousands of software developers and consultancies offering their services that make use of GPL'd (and other OSS-licensed) code. Probably 90% of this board is selling their services/labor of GPL'd projects. It's been my whole career.

No, what it sounds like is we're talking about people who want to write OSS but also want ownership and exclusive rights to make money off of it. My argument there is pound sand.

Note Canonical was created by an already millionaire. He already managed a Venture Capital at that time, and I assume had other businesses around. fwiw Canonical might as well be all lost money (millions of revenue, but how about profits?).

No idea about Suse.

In any case, even if they are great success examples, these can be counted on the fingers of one hand... so I'd say the sample size is not precisely "enough", not at least to prove a point.

EDIT: (reply to an edited part of the comment)

> what it sounds like is we're talking about people who want to write OSS but also want ownership and exclusive rights to make money off of it

I agree. On the other hand, most of the OSS that exists is created by such people, and what do we prefer? Idealistic but non-existing OSS software? or compromised but existing and useful OSS software? That's the question that I feel is behind all the conversations about this topic.

Wealthy people invest in things that are successful, not piss their money away for no reason. Canonical's revenues are around 110 million a year, taking in about a 10% profit margin since 2018 (which tracks with about how long it takes big tech companies to be in the black). SUSE's around 300 million.

You miscategorize Canonical like it's some vanity project. Even vanity projects can be profitable enterprises! Look at Koenigsegg cars! They're literally a millionaire's vanity project that is a profitable enterprise employing hundreds of people.

> I agree. On the other hand, most of the OSS that exists is created by such people, and what do we prefer? Idealistic but non-existing OSS software? or compromised but existing and useful OSS software? That's the question that I feel is behind all the conversations about this topic.

Free software has been around since the 80s, at this point. With or without the GPL. It turns out that there are many, many successful products and businesses that use other OSS licenses. I don't think we're in any danger of people with our skillsets not being able to eat. We're basically all potential millionaires.

The GPL is _not_ the only option available. Heck, Apache is absurdly popular and the bedrock of many enterprises...

> Even if through some process the license changes in the future, your contributions were still to an open source license and that version of the code will remain open forever.

Well, that's a good take. You're right of course: the exact version of the codebase you contributed to, was licensed as OSS and it will always stay like that.

So yes, copyleft is more about providing guarantees about the future, while non-copyleft can only provide guarantees about the present.

I think this way of putting it is clearer than my previous way of saying it. Thanks for bringing up this point of view.

> This is the reason why projects like MAME have contributor agreements now.

Hence articles such as [1] and [2], which have been posted in HN before, albeit with pretty much zero conversation.

Still, just like I'm interested in the topic of OSS licenses and the thought process of people who choose them for their projects, I find also interesting the matter about CLAs and whether to go on with one or instead opting to use a DCO [3], which some well known OSS projects have preferred in the past: [4], [5].

[1]: Why CLAs aren't good for open source -- https://opensource.com/article/19/2/cla-problems

[2]: Why you probably shouldn’t add a CLA to your open source project -- https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-...

[3]: CLA vs. DCO: What's the difference? -- https://opensource.com/article/18/3/cla-vs-dco-whats-differe...

[4]: (GitLab) We're switching to a DCO for source code contributions -- https://about.gitlab.com/blog/2017/11/01/gitlab-switches-to-...

[5]: Helm Moves To DCO -- https://helm.sh/blog/helm-dco/

Yes and this makes 100% sense. This is my first Open Source project so its definitely something to think about!

Actually those who prefer GPL see things from the perspective of the code, not the users.

GPL ensures the code is freely available at all times, and anyone can use it, change it, distribute it but not take it away or restrict access to it.

From the code pov, MIT/Apache is freedom to take away and restrict access.

Depends on how you define "user".

A developer is the "user"? MIT is freer for the dev, but the dev is free to restrict the end-user.

End-users are the users? GPL restricts developers from closing the source, empowering end users to become developers too.

At least in the case of GPL, "user" refers to the end user, and yes, the license is all about some freedoms that are guaranteed to percolate towards the end users, indeed empowering them to become developers themselves, if they wanted:

> It is absolutely essential to permit users who wish to help each other to share their bug fixes and improvements with other users.

https://www.gnu.org/licenses/gpl-faq.en.html#WhyDoesTheGPLPe...

MIT freedom is like the freedom to enslave.

Restricting the freedom to use your work to restrict others' freedom, is not nearly so onerous or hypocritical as GPL bemoaners try to characterize it.

I feel absolutely zero sympathy for the argument.

> For me, "freedom" doesn't mean "restricting what users can do."

> GPL restricts what users can do, and thus restricts freedom in my eyes.

A few sibling commenters have already rebutted, but to add to that, a way of looking at this is that all licences necessarily restrict users (with the possible/arguable exception of things like CC0).

The difference with GPL vs MIT is that MIT gives users the "freedom" to further restrict other users in future, whereas GPL restricts users from ever further restricting other users

Thanks!

As I said, I'm not trying to push for this or that license, just want to have a perspective of the choice for new OSS projects.

Mostly the usual lesson is that authors typically don't really think through much about the licensing choice when they are hyped about an upcoming first release. Technical concerns are, understandably, what gets most attention at the beginning. Your position is the most common one I've found for small-ish projects.

Reply on news.ycombinator.com