Comment by wglass | Hacker News Reader

Comment by wglass | Hacker News Reader

Parent Full thread

Good comments on each license, but misses a major point about sharing and community.

Despite the rhetoric about "freedom" the GPL is a huge disincentive for developers to participate. A larger code base that contains a GPL component must also be GPL. This is a nonstarter for most business users.

If you want to encourage a variety of developers to adopt, modify, and share changes, you are much better off with a permissive license such as MIT or Apache.

Paradoxically, the fact that you aren't forcing developers to share changes to the code encourages more use and makes it more likely you'll get a community contributing to the project.

Good examples of open source projects with diverse developer communities and permissive licenses include Hadoop, Apache webserver, Tomcat, NPM, Kubernates, TensorFlow and many more.

If you want to keep tight control over the code base and dictate all future changes, choose GPL. This was the choice for the JDK, MySQL, and many other projects controlled by corporate entities with little outside contribution.

(Yes, Gnu/Linux is a major exception as a GPL licensed ecosystem with diverse contributor base. But it's the exception rather than the rule).

> Despite the rhetoric about "freedom" the GPL is a huge disincentive for developers to participate.

The "freedom" references from GNU are with respect to the users of the software, not necessarily to any entity that may participate. It's perfectly possible for a proprietary closed-source product to leverage code from a BSD/MIT project to remove user freedoms.

> Despite the rhetoric about "freedom" the GPL is a huge disincentive for developers to participate. A larger code base that contains a GPL component must also be GPL. This is a nonstarter for most business users.

I think developers should really start to question this. Why is a GPL component a problem and who is really inconvenienced by it and for what reason are they being inconvenienced by it? What do they want to do that GPL becomes a problem for them doing it?

It's not possible to devise framings which will please everyone in both the Free Software and Open Source movements. The disagreements between them are very old, and for some, embittered.

Which is why the LGPL exists. Most code that is designed to be shared & incorporated rather than complete/forked should likely be LGPL (if the GPL ideals are what is wanted).

Personally I just go with MIT/X11 but there are good reasons to want to use a GPL-type license

LGPL is sensitive to linkage, which means it has very different effects on different programming languages. For example, it's stricter for Rust and Go (as those languages are typically used) than for Java and Python (as those languages are typically used).

MPL, on the other hand, is per-source file.

Yes. But the LGPL is still more restrictive as it requires you to share your changes. Not as much of a disincentive but it still discourages community.

There are two good reasons to go with a gpl or lgpl license.

One is ideological. You believe software should be free and that downstream developers must conform to your ideals. This is the Richard Stallman approach.

The second is control. You actively want to discourage forking and outside contributions. This is Oracle’s approach. This isn’t necessarily bad or evil, but it’s pragmatic. Generally a corporation doing this will offer the license under a separate paid offering as well.

I can’t think of any other good reasons to choose GPL.

> But the LGPL is still more restrictive as it requires you to share your changes. Not as much of a disincentive but it still discourages community.

Not a fan of GPL (because of developer restrictiveness), but I don't see how requiring changes to be shared implies more restrictiveness or discourages community. Can you explain the reasoning here?

In the early days of a software project, the most likely people to use it are business programmers: front line devs who have no say in corporate policy.

Typically, they want to use your code to save their own time. The code rarely does exactly what they need, so they almost always need to make changes. And since they are required under their NDA not to disclose any company related work, this prevents them from incorporating your code.

I have no feelings about this one way or another, but it's an answer to your question.

Here's a third reason:

"I used to be worried about fragmentation, and I used to think that it was inevitable at some point," said Torvalds. “Everyone was looking at the history of Linux and comparing it with UNIX. People would say that it’s going to fail because it's going to fragment. That's what happened before, so why even bother?"

What made the difference was the license. "FSF and I don't have a loving relationship, but I love GPL v2," said Torvalds. "I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back, which meant that the fragmentation has never been something that has been viable from a technical standpoint."

https://www.cio.com/article/3112582/linux/linus-torvalds-say...

LGPL only requires you to share changes to the LGPL code that you publish (you don't even have to submit them back, just make them available).

And yeah, that comes down to "well if you want to use our stuff and base new work on our stuff... share it to the world" but it has no effect on the wider application.

Yeah, it discourages the community from benefiting from other people's work without giving back.

Reply on news.ycombinator.com