Expurple

No, I can't remember any dead proprietary forks that would support that idea.

But somewhat, I can't remember any counterexamples either. I mean, a proprietary fork killing the permissive original. I can only remember:

- AppGet vs WinGet. But that's one permissive program killing another.

- The proprietary build of VSCode. But it's basically "a set of patches" on top of a still-maintained permissive base. And its popularity is at least somewhat dependent on the existence of that permissive base.

Perhaps you'll find MPL 2.0 less complex and more "in the spirit of the LGPL":

https://www.reddit.com/r/rust/comments/msjil9/opinions_on_th...

https://www.reddit.com/r/opensource/comments/msjk93/licensin...

https://www.reddit.com/r/opensource/comments/1g2sprd/could_a...

Although that won't help you with GEOS, which is already licensed as LGPL-only.

Disclaimer: I haven't been following any of these projects.

Based on quick googling, they all follow a very similar pattern. The original is permissively licensed. After a decade of growth and popularity, it's relicensed as source-available to prevent AWS from hosting it and harming the financials [1][2][3]. Copyleft community forks fail to get traction. A permissive, corporate-funded fork gets traction. It's adopted by the Linux Foundation and is provided on AWS. Enough users and contributors switch to make it relevant and active to this day. In the few years that pass, the permissive fork doesn't die, but it doesn't overthrow the "official" fork either. The "official" fork makes money and is still widely used. Later, it becomes dual-licensed under a copyleft license [4]. The CEOs say that they've always wanted to stay open-source, and the goal of the license change was to force AWS to fork [1][2].

It's hard to tell whether the permissive forks will overthrow the "official" dual-licensed forks in the future. We need to wait for a decade to see.

So far, at least in this space (dev-oriented tools that started as permissive), it seems like:

- Permissive corporate forks get vastly more investment and interest, and quickly beat copyleft community forks (confirming the article).

- Companies prefer more community-friendly licenses over full-on proprietary licenses (confirming the article). The originals are relicensed as source-available to cause the fork without alienating the community too much. The AWS forks are permissively licensed to get outside contributions and attract the community.

AWS, obviously, profits the most from permissive code. That's because it doesn't really care about the code itself, and profits from hosting it instead. It reminds me of this timeless post about "commoditizing complements": https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/. Now I see the connection between this idea and the original post. Permissive code "unlocks" more of the "adjacent value", and that's why it's more desirable by most entities.

Another post about corporate investment that I found while googling the topic: https://www.infoworld.com/article/2338938/follow-the-cloud-m...

[1] https://www.infoworld.com/article/3499400/elastics-return-to...

[2] https://www.infoworld.com/article/3975620/redis-bets-big-on-...

[3] https://www.infoq.com/news/2023/08/hashicorp-adopts-bsl/

[4] The latest versions of Elasticsearch and Redis are dual-licensed under AGPL. BSL'ed Terraform versions become available under MPL after 4 years from the publishing date: https://github.com/hashicorp/terraform/commit/b145fbcaadf0fa....

That's a different argument, unrelated to the one that I originally responded to:

> > all of the big, successful open-source projects are either GPL, or can't be GPL because of the GPLs murky legality around linking

I don't see how your argument is relevant to that, or how it disputes the article. The article is not about funding or "organic growth". It's about survival characteristics and winning the mainstream. Blink, WebKit, and Gecko are all a mixture of permissive and weak copyleft licenses. There are no popular GPL browser engines. There are no popular proprietary browser engines. That's exactly the outcome that the article predicts! (Of course, it doesn't need to "predict" the most popular browser engines specifically. In 2015, they already looked similar and had a similar moat).

Although I have to admit now, we'd probably see proprietary browser engines if it wasn't for the "weak copyleft" part. Now I think that it's actually the most long-term competitive license type for some projects!

If we continue with the topic of web browsers, then we'll see a seemingly strong counter-example: the most popular browsers are proprietary, and have been for a long time. But that's a thin layer on top of a larger open foundation. A thin layer is easy to replicate and compete against. Thus, Chromium and Firefox shells are maintained (and kept competitive) just fine. They are less popular than Chrome or Edge, but not because they are less maintained or broadly inferior (they may be for specific tasks). They are long-term viable options that aren't going away.

> Firefox is controlled opposition, paid $400 million per year by Google. They would have died long ago if it weren't for that little detail.

Depends on how you define "died". Broadly, I disagree. Too many developers are interested in the existence of Firefox. According to an Igalia employee [1], during the first half of 2024, 10.71% of contributions to mozilla-central came from Igalia, and another 8.74% came from Red Hat. I wanted to see an aggregate share of Mozilla employees (which must be even less than the remaining 80%), but I couldn't find that.

But anyway, even if Firefox died, that wouldn't be related to its license (and this article) at all. Chromium and WebKit have similar licenses.

> But my argument is, if you find them, they're mostly GPL.

That may be true if you artificially limit yourself to non-corporate-driven projects. But that's not what the article is about. And that distinction is irrelevant to me, too. If the "official" corporate-driven fork turns into something that I dislike, I have the freedom to switch to a community-maintanied fork (for popular projects, usually there is one) or fork the project myself. Or, I put up with the non-ideal corporate project if it's still the most attractive option. Being community-driven isn't a guarantee that the project will always be maintained and that the maintainers will always agree with you and put your use cases and needs above others.

[1]: https://bkardell.com/blog/2024-Midseason.html

> You assume that corporations would not choose aggressive and hostile business models if they weren't forced to, which is obviously wrong.

But, in my scenario specifically, they will be forced to by market forces (to some degree). Being less aggressive is a competitive advantage. In my scenario, the market is going to be flooded with competitors, some of whom are going to use that advantage. Even if some users still prefer the other advantages of proprietary Apple (as they do in reality), at least the users who care can switch and benefit.

> This would not be possible with licenses that allow Apple to keep everything proprietary

Sure, you can't clone Apple with literally "zero software investment". They will always have some proprietary parts. What I mean is that, in my scenario, they would have fewer proprietary rewrites (from GPL) and would use common permissive dependencies more often. Thus reducing the amount of proprietary code, and making their stack more uniform, "shallow", and easier to copy. Being easier to copy sounds like a downside that they'd like to avoid, but it's also cheaper, so a tradeoff comes into play.

Unless it's a heavily-modified proprietary fork, the cloud providers are only "eating" your profits. Not the share of the project itself. Profit isn't the top priority for everyone. I just want to have quality free software that I can use for my tasks. The more companies contribute and support it - the better.

And even regarding proprietary forks, the article makes a point that, long-term, those are prone to enshittification and/or abandonment, while the open fork is always there and keeps changing maintainers and maturing unstoppably

Are you seriously trying to imply that Firefox and Chromium aren't big open-source projects? Define "big" then. "Literally only Linux"?

Yeah. Related: https://hypercritical.co/2013/04/12/code-hard-or-go-home

It's a worthy tradeoff if your goal is to have the best (free) software possible, rather than making as much money as possible

Your comment is pointless, unless you follow up and point out what specifically has changed in these 10 years and invalidated the argument made in the article.

I don't take its conclusions uncritically. I examine them logically and I map them onto my own recent practical experience. Actually, in this thread people gave multiple good counter-examples that I haven't processed yet

> What are the outcomes that we are talking about here?

Living a life free of guilt and regrets. People make mistakes and can't foresee everything. That's normal. That shouldn't imply any guilt. I was talking specifically about cases where, in advance, you think that you're doing the wrong thing at the cost of short-term convenience.

Regarding KHTML, I don't have any data and can't say for sure. But I'd be surprised if most developers regretted their decision later. They knew in advance that they were getting into an LGPL project that can be used as part of something freedom-restricting. And, in my subjective opinion, Safari isn't so catastrofic and harmful that it defies common expectations of how harmful a freedom-restricting product can be

This is true in the short-term. One of the points of the article is that, long-term, proprietary forks are prone to enshittification and/or abandonment, while the open fork just keeps chugging along, maturing, and changing maintainers

"Following my inner guiding principles without compromising" seems clear enough. I don't think that you have to fully verbalize and rationalize your principles in order to commit to a clear goal of following them. You clearly feel when you do the wrong thing.

Ideal for whom?

It's still not ideal for downstream proprietary developers. The requirement to provide some means to relink the project is extra headache that can be avoided by using permissive dependencies, reinforcing the point of the article.

Also, in theory, I can imagine a situation where a proprierary developer strongly needs to make a change, and for some reason is strongly against open-sourcing it, and is strongly law-abiding. And thus, a proprietary rewrite is born. Sometimes, instead of a complete rewrite, that's going to be a fork of a permissive project, boosting its usage and reinforcing the point of the article.

For library authors, LGPL/MPL is often a good tradeoff, indeed. You still get all the modifications back, while also having more users then you would have with GPL. Although, as seen in this thread, enabling proprieraty dependents is actually a downside for some authors, due to their beliefs.

To me, it looks like LGPL/MPL become irrelevant in the "longer" run too.

---

I agree with you regarding the "tipping point". There's nothing we can do about this. In a similar vein, when considering a massive investment into a GPL project, they are going to conclude that they are better off invesing a similar amount into a proprietary rewrite and keeping the added value to themselves.

Most users and contributors put the functionality above copyleft. You are a minority. The article doesn't imply that you don't exist. It implies that copyleft projects such as yours will be largely pushed out of the mainstream. And that it will happen even faster when a project is clearly inferior and can't offer anything that's not offered by a permissive project that can be used anywhere without legal headaches. Such permissive projects will always spead and develop faster, all other things being equal

Do you consider open-sourcing the software a necessary precondition for making the world better?

In other words, can a company make the world better by making proprietary software? In my opinion, that's obviously true. (Although I too dislike Apple specifically)

Your approach forces every company to redo the work, even the "good" ones. In fact, that probably makes the situation worse, because it raises the barrier to entry and forces companies to choose agressive and hostile business models in order to get that investment back. If a new "More Ethical Apple" could be started instantly with no software investment, we would have one, the users would be able to switch, and would directly benefit from this

> all of the big, successful open-source projects are either GPL, or can't be GPL because of the GPLs murky legality around linking (the article mostly hinges on such a case - LLVM).

Another comment trivially points out that this isn't true: https://news.ycombinator.com/item?id=44607038

Indeed, MPL/LGPL are often a better tradeoff than GPL.

But, in theory and according to the article, they should experience same effect. Just slower. When a (law-abiding) company finally has a strong reason to make some modification and keep it private, a proprietary replacement is coming. (Sometimes, as a "thin" fork of a permissive project, which then gets an engagement boost, reinforcing the point of the article)

"Doing the right thing" (whatever that means for a person specifically) can be considered a goal too. Goals don't have to be selfish.

Software developed by enthusiasts that also receive patches from corporations (that can use the software thanks to a permissive licence) might be even better

That's true. But at the same time, the risk is kinda overblown. You can still use the last open version of Redis. There's even an open, community-maintained fork that you don't have to maintain yourself.

Even GPL can't force a company to maintain and keep developing an open version when the company doesn't want to. Even if Redis was GPL (no CLA), they could still abandon it and write a compatible clone from scratch. AI makes it even easier to do

Rewriting "any software" is an extremely high bar to begin with. I think, we can agree that smaller utilities and libraries can be rewritten by anyone.

Another comment [1] even references the "Bram's Law". It basically says that any piece of software that's easy to rewrite will be rewritten countless times (and most rewrites are going to be bad)

[1] https://news.ycombinator.com/item?id=44606219

It's true that we don't have any definitive data on this.

But I buy the article's argument that upstreaming a patch once is simply cheaper than maintaining your own proprietary fork forever. It externalizes the efforts of maintaining it in the future. This means that public, community-maintained, permissively-licenced projects are a good deal for companies, and should win from the economic / game theory POV

Compared to permissive licences (from the user's POV), GPL is merery a guarantee that a proprietary fork won't left you behind in the dust overnight. That's a rather strong guarantee that most people (including myself) don't need. I'm fine with a "plain" guarantee to fork the last free version. In exchange, I usually get better, well-supported software with more corporate contributions.

> Apple has famously used a lot of time and money to rewrite GPLd thengs. This is the goal.

As an aside, that's a terrible goal. Rewriting the same projects over and over is a waste of human potential. We could be solving unsolved problems and actually making the world better, instead of pursuing this weird and misguided notion of "fairness"

> I don't see why a company that refuses to add to a GPL project has a "decent change" of releasing their code under a more permissive license.

Because upstreaming a patch once is cheaper than maintaining your own proprietary fork forever. It externalizes the effort of maintaining it in the future. That's the point that the article makes. And it's true in my experience. My employer allows and encourages me to contribute back to our dependencies. Those aren't the core of our business and our competitive advantage

The article makes the point that, in practice, permissively-licenced projects see more contributions back. Copyleft projects are being rewritten as proprietary instead (with a few exceptions like Linux, which are too big to fail). The end result may be even worse for the user, if the proprietary alternative ends up being the most developed one, grows an ecosystem and a network effect, and eventually everyone is forced to use that. There's plenty of examples.

It's not about "fairness". It's about reality and survival characteristics.

As a user, I care about my freedom too. But permissively-licenced projects give me enough freedom to choose them over copyleft projects that are even slightly worse in quality

Redis has an open fork. Seems "free" enough to me. Companies are not obligated to keep developing the open version forever, anyway. If Redis was GPL, they could've just abandon it and write a compatible clone from scratch. Nowadays, with AI, that even easier to do

But a proprietary fork doesn't change anything for permissively-licenced projects either! The open original is still available, you can still use it and fork it. If it's a popular project, a community-maintained fork will always happen.

As a user, permissive licences give me enough freedom.

The point of the article is that BSD & Co have better survival characteristics, eventually attracting more developers, producing higher-quality software, and making the users switch to that.

In the long run, even from the user's perspective, GPL & Co is only for enthusiasts who don't prioritise the actual quality of the software that they use.

As a user, I value my freedom, but BSD & Co gives me enough freedom. The article assumes that it's the best tradeoff for most users, and I agree with that

Are you seriously trying to imply that the GPL isn't largely about granting you the freedom to fork? Sure, it's also about forcing the copyleft responsibility on you. But come on... That's not even relevant if you don't fork or otherwise depend on the project in the first place