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)
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"
It's not about fairness. It's about making bad actors like Apple pay to do their own bad work. If they chose to make open source software and actually make the world better we wouldn't even be having this discussion.
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
> can a company make the world better by making proprietary software?
If you assume a company that does not have any profit driven incentive to be anti-competitive and less accessible to some people, yes. But that's like assuming dictatorship can work if the dictator is just wise and benevolent enough. It's nice to think about but not viable in reality.
> it raises the barrier to entry and forces companies to choose agressive and hostile business models in order to get that investment back
You assume that corporations would not choose aggressive and hostile business models if they weren't forced to, which is obviously wrong.
> If a new "More Ethical Apple" could be started instantly with no software investment
This would not be possible with licenses that allow Apple to keep everything proprietary, which is what any profit driven company is incentivized to do. In other words, you need GPL for this scenario to be even theoretically possible.
> 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.
A good example of this pull towards cheaper maintainance is Microsoft eventually replacing its proprietary web engine with Chromium.
Although, as I've noted in the other comment, that wouldn't happen if Chromium was permissively licensed. It happened because its partially LGPL/MPL, and thus you can't create a proprietary fork (but can still use it in a proprietary browser like the new MS Edge). It seems like somethimes LGPL/MPL have the best survival characteristics
> If they chose to make open source software and actually make the world better we wouldn't even be having this discussion.
You mean like they did with LLVM/Clang?
> The LLVM project started in 2000 at the University of Illinois at Urbana–Champaign, under the direction of Vikram Adve and Chris Lattner. LLVM was originally developed as a research infrastructure to investigate dynamic compilation techniques for static and dynamic programming languages. LLVM was released under the University of Illinois/NCSA Open Source License,[3] a permissive free software licence. In 2005, Apple Inc. hired Lattner and formed a team to work on the LLVM system for various uses within Apple's development systems.[26] LLVM has been an integral part of Apple's Xcode development tools for macOS and iOS since Xcode 4 in 2011.[27]
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
You've been very diligent in replying to the detractors in this thread, but I have yet to see any compelling examples.
You say that there are plenty of examples of copyleft projects being overtaken by proprietary versions that then create network effects that end up being worse for the end user because the original project was copyleft. You further assert that if the original project had been permissively licensed, this wouldn't have happened.
I'm unaware of this ever happening. Can you list a few of the examples you had in mind?
This thread has eventually changed my own stance on permissive licenses. Now I think that LGPL/MPL have the best survival characteristics: https://news.ycombinator.com/item?id=44657017
> Can you list a few of the examples you had in mind?
As I think about it, I see that I wrote "plenty of examples" mechanically (pulled it out of my ass). Sorry :)
That entire argument of mine is stupid because it hinges on the ability to see alternative universes:
> if the original project had been permissively licensed, this wouldn't have happened
I could pull any unpopular GPL project as an "example" (that would be more popular with a permissive license because "trust me, bro"). But that's a bad argument.
> The article makes the point that, in practice, permissively-licenced projects see more contributions back.
How are we measuring this? I mean, sure, MIT will get more contributions than GPL.
But the MIT code is used commercially. So you can get, say, 10x more contributions, but you're losing 100x more money. Is that a worthy tradeoff?
The idea of corporate contributions is that the company is probably making WAY more money off your code than they are spending contributing back to it. Otherwise, they probably just... wouldn't.
// The article makes the point that, in practice, //
The article is over 10 years old. Which is 100 years in computer-dog years. What may or may not have been true about 2015 may or may not be true about what is going on today. We cannot just uncritically take its conclusions as read.
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
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.
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
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
> The fact that very large corporations are willing to spend tens and hundreds of millions of dollars to replicate software is exactly why the GPL is not irrelevant.
No, it's the opposite. The premise of copyleft is forcing the dependents to contribute back to the community. If the corporations are writing proprietary replacements instead of contributing, copyleft has failed to deliver on its premise.
In practice, permissively-licensed projects get more contributions back and benefit the community more. Simple as that.
We have no data on how much has not been contributed back due to corporations forking code or just copy pasting it into other projects. For all you know permissive licenses have dramatically reduced contributions back.
We only know when they contribute, we have no data on when they don't. Stories like LLVM are good evidence for what you are saying, but the linux kernel is good evidence against it. Dozens of companies are forced to work together for the common good at a scale and level of resources that is unprecedented. Without the GPL this simply wouldn't (actually from an economic / game theory standpoint it couldn't) happen.
> I wasn't there, but the narrative online seems to be that Linux won due to its strong momentum and the leading position that it established back in the 90s, while the BSDs were held back by the AT&T lawsuit. Due to this leading position and the network effect, using and contributing to Linux is simply much more cost-effective. Privately forking a BSD and making it "better" than Linux would give you a competitive advantage, sure. But it's a prohibitively expensive thing to do.
> In other words, it's a historical accident that there was no strong BSD alternative when Linux was picking up steam. Now it's too big to fail, and the GPL works in full force. GPL can't work in full force in the early stages of a project.
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
I feel like a massive counterexample here is embedded. Hardware companies tend to laugh at maintenance (it's expensive and extends the life of their products, so you don't have to give them money as often). If Linux was not GPL, many embedded platforms like routers or smartphones would not have kernel code available.
Also, it depends how much value-add they see their modifications having. For small tweaks and bug fixes they'll contribute it. If they invest a lot of money into something, they'll be loath to hand that value over to their competitors. There is some tipping point where the competitive value (or more realistically the jealous urge not to share) of their efforts exceeds the utility of easy tracking with upstream changes.
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.
They might decide to rewrite an lgpl project, but there is a massive sunk cost. At the point they make the decision the gpl project is less tempting to bring fully in house.
(L)GPL:
- Investing $3M to extend.
- Would cost $17M and 3 years to re implement to baseline and then extend.
- Lose all community development inputs because new solution is fully in house.
Permissive:
- Investing $3M to extend.
- Would cost $0 and 0 years to keep in house and still extend
- Keep 100% of community development inputs initially and potentially forever if they are able to extend in a way that avoids conflicts. Can port most community developed features with some effort.
Corporations make decisions 1 quarter and at most 1 year ahead. It's a very hard sell to say "we need to take 3 years and a huge investment to get to where we already are at". It could happen for some very specific, high value technologies where someone at the Sr. Director or VP level is taking a long view , but it would be extremely rare.
Ok, I have thought more about the topic. You're right. LGPL/MPL have amazing survival characteristics. Probably better than those of permissive licenses. See my other comment: https://news.ycombinator.com/item?id=44657017
Most other "flagships" of the Rust ecosystem (including rustc itself and ripgrep) are permissively-licensed, and still haven't been "hijacked" by a proprietary fork. Or by a copyleft fork, for that matter. Permissive licenses simply have better survival characteristics in the long run
But your habitual workflow isn't "doomed". You can always fork and keep using the same open version of the project that you've always used. If the project is popular enough, there's usually a community that keeps maintaining that fork.
That's the deal that you get. Free software was never about "free upgrades forever". It's about the freedom to fork.
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
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