This article is already largely irrelevant. The GPL (and the FSF), whether you like it or not, always has been a political movement. The aim of the movement is to expand the pool of free/libre software and to disallow commercial entities from gaining an unfair advantage without contributing back. With the GPLv2 they already have, as it permits them to run the software in the cloud, with their proprietary additions, without contributing back. AGPLv3 closes that loophole that's why it's even less popular.
You can license your software as you wish, but in the long run the GPL has ensured that contributions reach back upstream for the common good, rather than for profit. The GPL gives protections for the people/end consumers, much like labour laws do in your own country. The GPL ensures that your contributions are respected, available to all, and not abused for profit (not always true, but tribunals have enforced the license terms before). The GPL has the effect of doing this globally while allowing contributions back from a global audience. It's genius and the companies absolutely hate it.
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?
> 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
People seem to judge these licenses with measures that might not mean anything to the authors or the users. There are different kinds of authors and users.
GPL authors want their rights preserved for the users. MIT authors might just want their stuff "out there", or really not care how their stuff is used.
The aregument here is sort of like judging football as more relevant than baseball because plays are more exciting but short enough to still show ads on TV.
(also both gpl and bsd licenses have been around ~40 years, so what does long run even mean?)
Your comment is ignoring the realities and practicialities in the real world, just like GPL does. GPL is a theoretical idea that doesn't work in the real world, because in the real world, not everyone wants to or even can share their work products with everyone, and especially not just because some person talking about "libre software" says so. No one really cares if they have access to their refrigerator's source code.
There are many, many software libraries and tools that are excellent and yet aren't popular. A very common reason as to why they aren't more popular is because they are often licensed with GPL.
> GPL is a theoretical idea that doesn't work in the real world, because in the real world, not everyone wants to or even can share their work products with everyone
In practice, that is wrong. GPL software is useful even in a corporate environment because you are required to distribute your modifications only to the users who you distribute the software to. So if your modifications are meant for internal use only, then it's perfectly fine to keep the modifications confined to internal distribution.
On the other hand, if you're talking about publicly distributing modified software with undisclosed modifications, then you're financially exploiting the labor of the original contributors. They did most of the work from which you derive monetary profits. The fair thing to do in such a case is to negotiate an alternate arrangement with the original contributors. Or you could opt to distribute the changes according to the original license, if that's an acceptable option.
I have seen GPL software used in corporate environments in both the manners described above, without any sort of legal or ethical concerns. But the avenue of unpaid labor is so enticing for many large tech companies, that they fearmonger against copyleft licenses as if they're the worst crime committed against open source. Their argument is that copyleft licenses are too restrictive. Restrictive to their financial ambitions, perhaps? Because I don't see them restricting the developers or the normal users in any manner.
> A very common reason as to why they aren't more popular is because they are often licensed with GPL.
They're unpopular simply because of the vilification campaigns I mentioned above. It was very popular at one time to diss on copyleft licenses without a discernable reason. That was until many realized that the permissive licenses, combined with CLAs were an easy avenue for many of those companies to extract free labor from them.
Just anecdotally, but this aligns with my observations on the trend/growth of successful useful open source projects that go with permissive BSD-like license. ~20 years ago there were way less of those than now.
And as a SW developer doing client side/apps as well, using GPL/LGPL is a total pain and basically cost prohibitive, unless I work on my personal small project where I don’t care about having to/risking to open source the rest of the code and getting sued/cloned…
Real life example from ~2010 - we ended up including an LGPL library in our mobile app code, and published/upstreamed all the modifications we did to that code (mostly ARM optimizations). Once the app became popular, our competitors came to us demanding the source code of our app - just because iOS didn’t support dynamic libraries (so we had to statically link it), and giving them the object code to relink it wasn’t enough for them (which would satisfy the spirit of LGPL), because they really wanted to see how we hacked around iOS camera input APIs…
> giving them the object code to relink it wasn’t enough for them (which would satisfy the spirit of LGPL)
Doesn't that also satisfy the letter of the LGPL v2?
> Accompany the work with the complete corresponding machine-readable source code for the Library [...] and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library
I agree that permissively licensed projects are more successful if you define "successful" as "having the most number of users possible". Of course, this "success" often results in the unpaid volunteer maintainers being inundated by bug reports and feature requests from employees of major corporations, so there's drawbacks to that approach.
Yeah, you're saying that BSD code, which you can get for free and give nothing, is the most convenient thing for you in helping you create closed source commercial programs. Well sure.
I'd mention for a commercial library creator, say QT, the GPL can be quite convenient because the commercial clients they have can't just take their stuff for free and use it but instead can use the GPL to sample and then come for a commercial license when they're going to use it that way.
That is to say, just about every license that is used today serves a particular purpose for vendors and thus none of the licenses are likely to go away as long as we have different vendors with different aims.
> using GPL/LGPL is a total pain and basically cost prohibitive
It's not, if you can comply with the license.
If you want to take advantage of free (L)GPL code in statically linked binaries without providing the source code to your customers, then yes, that is a problem. Although with LGPL the linkable binaries should probably be enough.
I think the LGPL is becoming particularly irrelevant. I’d like to use GEOS (LGPL 2.1) in a macOS app but the risks are high as you point out. I think it’s going to be significantly less risky long run to rebuild GEOS in Swift. The complexity and lack of clarity in the licensing is a real burden.
I don’t think this is the spirit of the LGPL - it’s just code signing prevents the use of dynamically linked libraries in the way LGPL intended.
> just because iOS didn’t support dynamic libraries (so we had to statically link it)
if you develop closed software for a walled garden then relying on gpl is still possible but a rather contradictory philosophy. i guess the alternative would have been developing all that from scratch, or getting it from elsewhere, likely paying for it, which would have made those costs even more prohibitive ... otoh i really don't understand those prohibitive costs because supplying the object code was all you needed. what were those? lawyers?
I can think of at least a few counterexamples. The logic behind the hypothesis is decent and tells a plausible story, but I'd like to see a more robust analysis; has anyone done one since the article was first posted 10 years ago?
Noteable counterxamples (excluding e.g. Linux):
- Git (GPLv2)
- Blender (GPLv2 & 3, from the looks of it)
- Krita (GPLv3)
- MySQL (GPLv2) -- still seems very popular in 2025
I always use git as a binary and don’t have any interest in forking it.
Most of the new databases of last 15 years have some kind of restrictive license that aims to stop AWS from selling a managed version of it that also limits what I can do it. So they are dead to me. Postgres is growing not just because it is a good database which is taking ideas from document databases, but because you can build on top of Postgres and feel confident that you can commercialize or open source your work and people will be able to use it.
Blender used to be proprietary,the community had to raise money to buy the source code to make it free software. What a crazy success story for opensource.
Git - jj[1] uses gitoxide for its git interop/backend (git being the backend of jj you're expected to use), both Apache/MIT; it functioned so cleanly I assumed it was invoking git directly, but apparently it's all custom!
For new things I'd guess PostgreSQL vs MySQL is probably on the same order as llvm vs gcc; probably with PostgreSQL being better off than llvm even.
[1]: https://github.com/jj-vcs/jj/ (started by a Googler as a hobby project, now their full-time job at Google, so kinda fits into the "big orgs will replace things with permissive-licensed versions" narrative)
It’s a recent change, there were just too many folks who had network requirements that it couldn’t do, so it’s easier to just piggyback on top of git, which supports all that stuff.
These are mostly executables/end products, aren't they?
GPL allows protecting the business logic by discouraging hostile forks: after all, forks of such projects can't relicense GPL files w/o permission, and upstream can just copy the changes back w/o having to ask.
On the other hand, permissive license favor dissemination. Would {fmt} (libfmt) be as ubiquitous as it is, if it were GPL instead of MIT?
In the very long run I'd hope we get sane intellectual property law: Software and logic circuitry is mathematics and should be unpatentable and trade secret is about the only protection for software/firmware/hardware; copyright terms shortened to the actual window of profitability (5-10 years) and only applying to "business logic". Nothing else makes much sense in the modern world; standards and interoperability benefit everyone to such an extent and change happens so rapidly that the majority of existing IP protection duration only harms historians.
That's why I used the scare quotes; I don't have a hard and fast rule here for what's legitimate market-making software value and what's just rent-seeking.
I think that much of the core features in Desktop Photoshop-style products or video games probably requires legitimate short copyright, for example. I don't think copyrighting a plugin interface or header files or hardware drivers makes any sense, unless there's significant creative work like e.g. the portions of GPU drivers that trade off appearance and speed in novel ways.
The AS/400 (now IBM i) platform has a neat feature: all application software is compiled into a sort of bytecode called TIMI, for Technology Independent Machine Interface. The use of TIMI is completely transparent to developers and is implemented at an OS level; you as a programmer do not get access to the underlying instruction set. When a program is run, if the OS does not detect a native-code "shadow" binary for the program, it will AOT-compile it from the program's TIMI code before running it. Among other things, this allowed IBM to convert their systems from AS/400 CISC to 64-bit POWER-architecture in one swift yank of the tablecloth, with all application software running 100% backward-compatibly on the new architecture.
But that's not the reason why TIMI was implemented. TIMI was implemented to fulfill an antitrust consent decree, under which IBM agreed to unbundle IBM hardware from software. But they still wanted to ship an OS with each system! So they declared that the OS was "firmware" and "microcode", hence part of the hardware, despite being loaded and booted from disk like any other OS. Anything considered "software" for the platform was written in TIMI.
So here we indeed have a bright-line distinction between OS and application code; between platform and business logic. Such a sharp definition is pretty rare in the industry.
There can never be a sane intellectual property law, if by "sane" you mean reasonable and/or free from negative consequences.
Imagine you live in the star trek universe, and we have those replicator machines which will happily deliver as much of anything to you as you wish to get.
Now imagine trying to come up with some "sane property laws" to exclude people from using them. What would even be the point of trying? How would any such attempt be anything more than arbitrarily giving one class of people unjustifiable power over another class of people?
We are actually in that very position with the fruits of intellectual labor. Just because one person is using a program, or an algorithm, or a theorem, that doesn't prevent anybody else from also using it.
So any mechanism for prohibiting somebody from using a program--which is to say, any mechanism to turn a program into property--is going to be globally suboptimal. It is going to arbitrarily harm one class of people so that another class of people can benefit.
The genius of the GPL is that it it gets this. The miracle of the GPL is that has found a way to give us something like a replicator machine even in this ultra-capitalistic society.
Your star trek example is cute but misses one important point: cost.
In ST there is apparently an infinite energy source running these replicators, so almost no cost. For any software project, developmemt and maintanenace costs time/money, so anyone replicating your invention or contributing to your project requires time/money(/expertise as a derivative).
That's what the GPL doesnt get and what scares me alittle about the future of the linux foundation.
Imagine Torvals gone and only highly payed corporate devs maintaning the linux kernel and worse, controlling the foundation. If a user hostile descision is made and the nerd outcry is shacking the force, what are they supposed to do? Forking and maintaning their own kernel in competition with high velocity veterans that just boil the frogs slow enough?
I cant imagine this succeeding. Just look at the slowly shrinking market share of BSD.
// In ST there is apparently an infinite energy source running //
Think about a server farm, which rents out cpu time for linux servers. Sure, you have to play for energy, land, and labor. But are you saying that somehow implies that linux would have to be BSD licensed instead of GPL licensed?
I agree, energy, land, and labor are things which we don't have infinite supplies of, and therefore we need some way to ration them and distribute them efficiently. But I don't see what bearing this has on software licensing.
// If a user hostile descision is made //
Yeah, I don't see what this has to do with BSD vs. GPL or any other software license. I mean, Microsoft has been "boiling the water" forever.
// cant imagine this succeeding. Just look at the slowly shrinking market share of BSD. //
So the answer is not releasing things under the GPL? I don't quite follow the argument here, would you care to clarify?
> I don't see what this has to do with BSD vs. GPL
That is my point, license does not matter that much (and i meant the BSDs OSes).
A license is not the only barrier of participation, you need to have the resources (time/money/expertise) too, and when you enter as a directly competing fork with marginal market share, you better have more resources than the parent project or otherwise your fork will not be able to keep up to with an adversarial company, trying to keep that jucy monopoly, they might have build ages ago with community contributions.
Forking and maintaining a gigantic project is not really a practical option for angered hobbyists. The costs are too high or competition to harsh.
IMO this is not only a problem of the GPL but of FOSS in general. Lets call it capitalistic capture.
This whole argument hinges on the statement that the GPL "does nothing for users" but is "annoying for developers". I dispute both of these claims.
GPL is all about doing something for users. It is users who are able to request source code. My entire network setup is based on the fact that I can customize my router which I can only do because users were able to request the source for the router in order to customize it.
When it comes to "annoying for developers" we need to be clear. The GPL is annoying for developers of software that is not open source. It annoys them because it says they must either take the open source deal or else rewrite it themselves. Apple has famously used a lot of time and money to rewrite GPLd thengs. This is the goal.
OTOH open source developers need not be annoyed by any GPL dependency since they can always use it without any trouble to themselves.
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.
> 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]
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.
> OTOH open source developers need not be annoyed by any GPL dependency since they can always use it without any trouble to themselves.
Counterpoint: GPLv2-only is an absolute PITA to deal with but that's the point; GPL (especially v2-only or v3+section7b,7c) is good at preventing hostile forks
Moreover, a company can release a GPL'd version of their software and also offer a commercial license for their software (see Qt etc). So someone who's charging for their software can use it if they themselves pay. Some commercial vendors might annoyed by even this. But it would seem they "doth protest too much".
It may be true, but the GPL is uniquely positioned to create a floor that ratchets upwards, whereas the other licenses are susceptible to being consumed and extended.
> […] whereas the other licenses are susceptible to being consumed and extended.
Often in practice people found that does not work with BSD/MIT-like licenses: you keep your changes and patches in-house and the original project moves forward. You then have to keep carrying forward your work, and you're either losing out on public fixes or have to expand energy to fix merge conflicts.
Lots of vendors learned this the hard way with (e.g.) FreeBSD: you want to follow the development branch (-HEAD) and merge early and merge often.
An exception to this would be one-shot forks, like Sony did with the PlayStations: you have your base functionality and it will never change for the life of the product so you don't really need future updates.
True, but the article makes a point that it's very hard and unlikely to maintain technological superiority over a coproration that's determined enough. A corporation simply has much more resources. See also: https://hypercritical.co/2013/04/12/code-hard-or-go-home
I'd say no, crushing / surpassing the competition is not a goal for non-commercial software and it doesn't have to be.
The thesis is that "GPL code becomes irrelevant", and they are probably right about GCC. It doesn't mean GCC goes away, just that it will become irrelevant to more people.
Sun Studio and Borland C++ are even more irrelevant, not sure where that fits in the conversation.
Is MS Visual Studio becoming irrelevant?
From a developer/business point of view, there's no reason to use a more restrictive GPL dependency if it's not clearly "superior" to a permissively-licensed one.
The article makes a case that this will eventually push GPL out of the mainstream. No one will use GPL because they "have to" (which is the whole premise of copyleft!). It will only be used by enthusiasts
If the business wants to develop non open source software, then having them not use the GPLd project and thus profit off the free labour of others is a wonderful outcome.
Your argument is in terms of "fairness". But most users don't care about fairness. They care about better software. I'll use a permissively-licensed project if it's better. Most people will use a proprietary project if it's better.
The article makes a point that permissively-licenced projects have the best survival characteristics, and that's why most (quality) software will eventually be permissively-licensed, while GPL will fade into obscurity and will be used only by enthusiasts why care about fairness more than they care about the actual quality of the software that they use.
> But most users don't care about fairness. They care about better software.
Users care about convenience and familiarity, then perhaps (perceived) functionality. People who care more about quality are a niche, not only in the software industry. Prioritizing quality means higher cost in some way, even if it's just effort to research the best choice.
> Most people will use a proprietary project if it's better.
Most people don't even compare available choices. Usually they don't choose based on license, but based on popularity or familiarity, based on what's the standard in the industry or within their community. If a user's been running a tool for years and it's good enough for their purposes they have no reason to look for an alternative, and the license or whether it's "better" is irrelevant. And big tech platforms love to amplify this effect with dark patterns and various forms of lock-in.
Software developed by enthusiasts that also receive patches from corporations (that can use the software thanks to a permissive licence) might be even better
I think those same people I mentioned would argue that being mainstream is also not a project goal, nor is utilization by corporations at all.
I have to admit I think a lot of people with this sort of "death to capitalism" mindset simply won't get anywhere, because they literally don't want to. I guess that means they may eventually fade into obscurity.
But the majority of project leaders I have talked to all seem to follow this mindset... they're not interested in making money, and "this is not a popularity contest."
Yet when a fork inevitably emerges, they go nuclear. Reminds me of a quote I saw one time... "they don't want open source, they want to be the ONLY source."
While it's not the explicit goal, it was because of technological superiority that most of us got into free software in the first place. There was a time where Linux worked great while Windows 98/XP struggled to maintain in its own feet without crashing down (yes, even XP)
While there's nothing wrong with purely enthusiast projects, they never got the amount of traction practical FOSS projects get. How many users does SerenityOS have, compared to Linux?
I invite people to ask themselves, do we really want a "pure hobbyist Linux OS"? How many modern feature are we willing to surrender for it?
Haha. I work on Solvespace which is technically inferior to FreeCAD, which is also inferior to the big commercial offerings. We shall have our MVP in a few more years! Most our contributors would not be working on it under an MIT license. I certainly would not.
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
> Most users and contributors put the functionality above copyleft
Most users put functionality above the license, copyleft or not. Among two comparable projects one will always be more popular and I highly doubt the license is often a deciding factor for that.
> It implies that copyleft projects such as yours will be largely pushed out of the mainstream
Those CAD projects were never in the mainstream to begin with. And FreeCAD might have a niche target audience but for me it has no viable competitor. The situation got better in recent years but I don't see why I should make myself dependent on a subscription based commercial project that's incompatible with everything else including other products from the same company.
> Such permissive projects will always spead and develop faster, all other things being equal
Such as? Wouldn't one expect BSD systems to have overtaken Linux in the last three decades with that assumption?
I thought the author made the case that because of complexity economics the ratchet still works either way, and in fact that in 2025 GPL is actually a less-strong ratchet compared to Apache and MIT. If GPL was the stronger Ratchet you wouldn't ever expect to see an existential risk to a GPL project posed by an Apache one right?
Licenses that allow more collaboration end up winning, and permissive licenses allow more collaboration.
That said, the source-availability requirement of the GPL did help kickstart things.
In the 80s every unix vendor had their own closed source version of everything. The GPL - through the requirement of source availability - helped flip the industry over to collaborative building. It would’ve never gone that way if those working in the open did it under permissive licensing - that would have given closed-source vendors free labor and discouraged those working on free software.
Nowadays it’s about velocity. In domains where collaborative building is producing more better software faster, it’s more expensive to work behind closed doors than to take others’ work for free. So you may as well use the open thing. And then when you want to add features or fix bugs, it’s a hassle to maintain your own fork while integrating new work from upstream. So you may as well upstream your work too!
2. If there is a permissively-licensed project in that area, at least there's a decent chance that the "reimplementation" will be a fork of that project. At that fork has a decent chance of staying open or even being merged back into the upstream. That benefits the community more than a proprietary from-scratch rewrite (which would follow from a GPL-only open-source scene)
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.
If you're going to talk about theoretical behavior from big companies, you can make stories any way you want.
Let's say a big company selling computers wants to include a PCB editing software by default. If KiCAD was Apache licensed they may be tempted to make a special version for their customers, as a unique selling point. But it's GPL, so they have to choose between rewriting completely (a huge process), or just publishing the changes and being happy to include a good program.
Or a company makes modifications to a GPL program for internal use, and decides they want to share it with partners/customers later.
I have no reason to think these stories are more or less likely than the story of a company completely rejecting the GPL option but still deciding to upstream their changes.
Didn't Sony gobble up a whole bunch of stuff from FReeBSD for the last few Playstation release without hardly contributing anything back at all ? IIRC the might have sent some patches to improve SMP or sponsored a conference.
Same with Microsoft and the Windows TCP stack lifted from BSD as well.
Compare with GPL licensed projects, like the Linux Kernel & its license making many projects possible, like the OpenWRT project for example.
Yeah I see a lot of corporate backing of Linux (GPL) and a bit of proprietarization of non GPL OSS. Meanwhile my employer also uses git and gcc, which are both GPL.
Companies that use software like it Free. Companies that develop software like it permissive. There are more users than developers, especially for large more important programs.
> 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
> 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.
It's simple in my experience.
Many big companies have some set "A" of code that they want to keep private, and some set "B" that they don't care about keeping private.
Lawyers are worried that at some point someone will accidentally include GPL code in something from "A" and force it to be made public. So they ban GPL entirely. They could in theory just ban GPL code from "A" and allow it in "B", but they can't trust that among thousands of employees none will make a mistake, so they just ban the GPL entirely.
So if we're nice to the billionaires, they may return that kindness with table scraps - if we're lucky? Sounds like the tech version of trickle-down economics.
Yes, but what's the better alternative? The article makes the point that you're not even getting table scraps back into your GPL project. In most cases, the companies prefer a proprietary rewrite. Now you're just stuck with a less-developed project, while the world around you uses more-developed proprietary alternatives and pushes you to do the same. But I guess, that somehow makes you feel better because you don't let the corporations "feed off your work" and instead just waste everyone's time on infinite rewrites?
Yeah, I don't get that argument. "Apple is funding LLVM, therefore it is getting better than GCC!". They are only funding it because it advances their goals. The moment they get what they want they will drop it or look for ways to keep the advantage all to themselves.
The same could be said about non-corporate contributions. "People only contribute as long as they have a personal itch to scratch. The moment they get what they want, you're on your own again".
That's always been the deal. Open source is not a guarantee of free support forever! It's a guarantee that you can always fork and keep using the project (or even developing it further)
I'm less concerned about "free support" and more about "commons-oriented R&D".
There are some projects/people that I donate a small monthly amount. I don't do it because I'm expecting a specific feature to be developed, but simply because I think it's important to have support developers and let them work on something without being concerned about how to make a living out of their work.
It’s just the academic method of sharing your work so the collective knowledge and state of the art increases monotonically. People seem to like to productive it, but even just publishing your source code so I or my llm can read it and modify it is useful. Very useful.
Everyone only does anything if it advances their goals. Luckily Apple's goals w.r.t. LLVM are the same as everyone else's: have a high-quality compiler backend.
Beware of sweeping generalizations. Most people only do things when it advances it goals, but there certainly are people that do things simply because they think is the right thing to do.
"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.
> Following my inner guiding principles without compromising" seems clear enough.
To me, it's not. What are the outcomes that we are talking about here?
> You clearly feel when you do the wrong thing.
Do you think that the developers of, e.g, KHTML felt they were doing the wrong thing when they started working on a browser engine for Konqueror under LGPL? Would they continue working on it had they known that Apple would take their work to build what is arguably the most freedom-restricting web browser out there?
> 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
Sorry, this is not an outcome. Maybe you can say it's an strategy to help you define your priorities and it can help you set your goals in whatever endeavor you're taking on, but it's not something that has a clear goal post.
> Safari isn't so catastrophic and harmful
Taken in isolation, no it's not so bad. But the issues of Safari are the context where its development happens. Safari is intentionally stripped of any feature that could threaten Apple's market dominance in the mobile market.
And that is the problem with too-permissive software licenses.
Some people always forget that GPL is about the end user's rights, not developer's rights. If a fortune 500 re-implements some GPL library to make proprietary, then by all means. It changes nothing for the GPL code, it's still GPL and its license should guaranty user's rights.
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
> With enough time, any sufficiently large company can implement their own version of any software that anyone else has written. They usually won't write their own version if a high quality opensource version exists with a permissible license.
Is this a true assertion? If you define sufficiently large company to be Google, Microsoft, Amazon, etc. then sure, of course they can. That's an extremely high bar though and I would bet that even then, these companies would have to pick and choose their battles.
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)
I've been thinking about this a lot recently, because GPL was meant to ensure that vendors couldn't take OSS, turn it into closed source, and use it to extinguish the OSS.
As JS-writing eng I live in an MIT-native offshoot of the OSS world and for us the ratchet that ensures we always get more and more free software is basically the fact that when your product is a script run in a scripting engine you can't ever truly hide anything.
Since we have an alternate ratchet that has proven that it works to increase the amount and quality of OSS (over a 20-year time period), the GPL does seem as you say: a relic of times when we it seemed like software might only be a hobby.
I'm writing a VCS kernel, basically, and its cost me the last 5 years of my life. My code is MIT. Do I have to think about the dangers of embrace-extend-extinguish? Yeah, but having the best product is a very strong defense, and building the widest coalition of supporters you can is how you get there.
To be more clear: my strategy is to eliminate the room that could be used to undercut me with more virulent technological or techno-social solutions.
GPL would not be eliminating the room to undercut me with a slightly more viral clone of my product, but rather creating more room to undercut me. This is a real problem for a piece of software the value of which is in simplicity not complexity!
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.
What makes the GPL irrelevant is AI. AI in it's current incarnation is basically a magic copyright remover. It can memorize all the patterns, tricks, algorithms, and architecture of open source software and implement it again. In a few years you won't need git because you will just have an AI stamp out a git compatible tool if you need one.
So if you care about Freedom, we need to move the battle from making sure you can get a copy of the source code to git, to making sure you can get a copy of the weights of the AI you are using to create software on demand.
> 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.
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.
One of the interesting things about the experience of LLVM and Clang isn't that it's killing off gcc--a decade after this was written, gcc is still the compiler of choice for most Linux distrubtions--but that it's killing off EDG, the C++ frontend that all proprietary C++ compilers used to use. Killing off proprietary software because the open source stuff is so much better is the vision of Stallman, and it's telling that a permissive license has been much more effective than a copyleft license in doing so.
Ignores the MPL as usual. IMO the MPL is better than BSD/MIT/Apache since it prevents your code getting closed, and better than GPL by not forcing others to open their code.
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)
using BSD/MIT licences is like betting against black swan event
sure, "contributing is cheaper than maintaining a fork" is true most of the time - but the moment new Microsoft comes in with "embrace, extend, extinguish" (or just copy and change), you're doomed
and heck, we had that exact thing happen last autumn, iirc - making big news on this website
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
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
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
I think this is largely an illusion. Most open-source software isn't that successful, so it might seem like the choice of license didn't really matter for their success. But you'll notice that 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).
The author talks about GPL projects feeding back on themselves to create technological dominance. But it's much more than that. GPL encourages organizational dominance, too. It starts with watch dogs looking out for GPL violations. And it ends with a big nonprofit foundation providing training and paying developer's salaries. Why did Linux blast past BSD? The popular story is that some company was trying to claim ownership over BSD. But the same thing happened to Linux a decade or so later with SCO. I think the license created a no-win situation for anyone who wanted to create their own Unix-based OS. If it wasn't Linux-compatible, it wasn't valuable. And nobody could keep up with Linux's rapid pace of development. So everyone gave up and started contributing to Linux, causing the pace of development to increase even more. Now, Linux has what, a million commits per year? Something insane like that. Try achieving that with a BSD license.
> 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).
I think that the SCO threat to Linux also came at a time when Linux was pretty immune from such a threat. If it's the early-90s and there's two options in their infancy and one had AT&T (one of the 5 largest companies) threatening it, you'll go with the other. In 1993, you're not using BSD or Linux and making a choice between them. The legal threat weighs heavy there.
When SCO sued IBM, people were already using Linux including one of the biggest and most trusted names in computing (at the time): IBM. Migrating away from something is a hard choice. Likewise, Linux had IBM's army of lawyers defending it (yes, BSD was defended by UC Berkeley, but the school could have easily folded over a project that wasn't part of the school's core mission). SCO also wasn't much of a threat - they were a dying company trying to win a case against the biggest names in the industry.
It's a lot easier to spread FUD against something no one is currently using that has a viable alternative. In 1993, Linux and BSD may have been equal, but AT&T's legal threat carried weight. People choosing one or the other weren't already using one. By 2003, 25% of the internet was powered by Linux. People were already using it and weren't going to be scared away by the claims of a dying corporation while powerful companies were defending Linux.
You say yourself that if something wasn't Linux compatible, it wasn't valuable and so everyone had to be chasing and reimplementing Linux compatibility. But if BSD had been established for a decade and Linux was chasing BSD compatibility in 2003 and then SCO sued BSD, BSD would still have maintained dominance.
When a company claimed ownership matters. Which company claimed ownership matters. "How big" the OS was when the challenge came matters.
Frankly, reset Linux adoption to 0. Have everyone use BSD for 2-4 years. Then reintroduce Linux. You won't end up with Linux dominance. You'll end up with BSD dominance. Linux had a multi-year head start. As you note, once you become the dominant target, everyone else is chasing you. If BSD had a multi-year head start, Linux would have been chasing BSD and the roles would be swapped.
SCO was suing on two grounds. First was the claim that they were the corporate heirs of the AT&T copyrights, and they claimed that Linux infringed on them. Second was from a joint development agreement with IBM - they claimed that code from that had been contributed to Linux by IBM, and that IBM didn't have the right because it was half SCO's code (or rather, Novell's code that SCO inherited).
That second claim could not have happened until IBM was contributing to Linux. That part of the lawsuit could not have happened in 1993. (The first part was similar to the BSD lawsuit.)
To me the larger question is whether or not GPLv2 achieves the goal of forcing big companies to contribute back to a project better than a more permissable license does.
As stated in the article, Linux is the notable success story, but anecdotally it seems that the majority of projects with large company contributions are licensed with BSD/Apache/MIT but with contributor agreement attached.
I wonder if anyone has compiled any data on whether GPLv2 does actually encourage contributions more than the more permissive alternatives.
GPLv3 isn't even worth mentioning in this context, great concept, abject failure to thrive IMO.
Yeah, the Apache/BSD licensed code will always come out on top, when some big company eats it, and effectively dictates its development with no other fork gaining any traction and with the project effectively becoming enterprise-ified.
This happens to a lesser or greater extent, but it happens.
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
> 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
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
I think people who prefer GPL and I hope for the same outcomes but we have a different (irreconcilable?) philosophical approach to getting there.
In my view code (and all knowledge) wants to be free and a commons of knowledge enriches the whole world. I am opposed to most forms of copyright, patents and intellectual 'property'. Aside: My compromise position to this maximalist view is that I'd accept a 5 year copyright term with an exponentially increasing renewal fee.
For me MIT/BSD/Apache is a way to provide code with minimal encumbrances under the current dominant legal system. GPL is an attempt to free knowledge that relies on the legal system and the threat of men with guns coming to force you to comply. However noble the intentions at the end of the day it is reliant on state force and reduces freedom, it is very good at providing fees for lawyers.
Corporations can't embrace-extend-extinguish open source. This is because the source is always available. Sure they can use that knowledge to build a new, more popular, thing, but the existing source never goes away. It represents an un-enclosable commons.
> Corporations can't embrace-extend-extinguish open source. This is because the source is always available. Sure they can use that knowledge to build a new, more popular, thing, but the existing source never goes away. It represents an un-enclosable commons.
Some counter-examples:
* git is now mostly github
* khtml is now mostly chrome
* linux is now more android and chromeos than linux. Anyhow, the plain kernel is deeply corporate.
You can still fork those project. But it would be mostly meaningless to do so.
But this doesn't really contradict the idea, in my view. Our existing property framework is built around physical goods that experience scarcity. The cost of code duplication is zero and it is (barring catastrophe) indestructible. Today you can browse the git codebase in the same way as 2 decades prior or hence.
All the knowledge in those codebases is preserved for all time, freely available to anyone. They have been built upon in ways that don't necessarily give back but that wasn't a destructive event.
Aside: Though if I remember correctly git and Linux are GPL so they create categories of thought-crime under copyleft if a judge holds your code to be too influenced by them. How influenced is too much? You better have enough money for lawyers to find out.
What does this sentence actually mean? Every time I've heard of it it is just stated as an obvious fact with no explanation, or it seems to just mean "I want knowledge to be free".
I had prefixed that with "in my view" but in a purely literal sense you're right. Code and knowledge are inanimate objects, they don't 'want' anything. The statement is influenced by my belief, it is merely a common turn of phrase.
To expand a bit more, code is freely, instantly, trivially duplicated, shared and remixed[1]. Much like knowledge there is no scarcity for these artifacts without legally mandated, police enforced, artificial scarcity. If the full source code for anything (Windows 11, EPIC Systems, whatever) was leaked tomorrow that would be a non-destructive event for both the code and knowledge involved. People work around this with trade secrets and intellectual property law but the 'entropic' norm is for these things to become more available, not less.
[1]: Since we're being literal there is of course some energy and time cost to the listed actions.
Some situation being the "entropic norm" that things tend to without intervention is not a good reason to prefer it. If we allowed everything that costs nonzero effort for the state to prohibit, we wouldn't have a civilization at all -- the ultimate "entropic norm" is pure anarchy.
So rather than arguing from these philosophical principles I think it makes more sense to answer a pragmatic and very concrete question: is the world would be better off, or worse, for having intellectual property protections? I think it's clearly better because the existence of these protections encourages people to spend time and effort making creative works (including software). That said; I think software patents are counter-productive, as are extremely long copyright protections for software. But I think that for pragmatic reasons, not abstract ones that seem to fall apart when you examine them closely.
Ultimately you end up in an abstract or values based discussion either way though.
Your question, is the world better off, is impossible to answer in a manner that isn't based in conjecture I feel. Would people not feel the urge to create with a 20 year copyright term? 7 years? 90? zero? Aren't some of the most valuable pieces of software in terms of social good open source? What drives the creation of those?
The closest we have to a counterfactual of the current US based intellectual property hegemony is probably China, who are renowned for their lack of scruples in this matter. Isn't some part of their supercharged technical progress based off willingness to ignore IP? How much? Is California's ban on non competes partially responsible for it's innovative tech sector?
These are all fuzzy questions that are difficult to answer and you end up approaching them with values judgements in mind.
So to restate mine without that controversial phrase; the more people that can access and share information and knowledge the more we unlock the possibility of progress and improvement for the greatest number of people.
Well, that is a more coherent argument than “information wants to be free”. I disagree with your conclusion, but I’ll at least admit that we’ve now reframed the debate in terms I find meaningful: it depends on one’s subjective judgment of the relative importance of two competing interests: on the one hand, the tendency of state-enforced monopolies to encourage producing creative works for profit motives, and on the other hand, the tendency of free information to encourage faster progress.
Bro quite literally does not understand the stated practical reasons projects use different licenses, makes up rationales for "exceptions" to suit his theory.
This article is a decade old. I wonder if the author still agrees with it given how the software and corporate landscape has changed over the past ten years.
While I have always used maximally permissive licenses on my own open source software, I've been rethinking that stance in the past couple of years. I'm not sure where I stand now, but I don't fully agree with this post.
In particular, perhaps my number one fear about the world at large is that the untethered effects of economies of scale are clearly leading to a net transfer of power into the hands of fewer and fewer corporate leaders.
Permissive licenses are arguably agnostic to that effect: anyone can use the software, corporation or not. But given that large corporations already have significant economies of scale, the emergent effect is that a corporation can extract more value out of a piece of open source software than you or I can. If your goal is to discourage a handful of oligarchs eating the world, a permissive license may be opposed to that.
It's sort of like breeding fish and dropping them in a lake. Sure, anyone can then grab their rod and reel and catch a few, so you aren't privileging the commercial fisheries industry by doing so. But once the trawler shows up, they're going to harvest a hell of a lot more fish than the dude with a bamboo rod.
You may be thinking this analogy doesn't work because software isn't like fish. Copying a piece of software doesn't remove a fish from the lake for others to catch. But think about this at one level of abstraction higher.
Copying software accomplishes nothing. It's just bits sitting on a disk. It's software being used by humans that matters. When a corporation takes a piece of open source software and puts it in front of users, time a user spends using that corporation's code is time not spent doing anything else.
While software itself isn't a consumptive good, human attention is.
Notice how all of the biggest, fastest growing corporations understand this. Attention is the ultimate economic commodity. Any company who can mine it effectively wins and any company that fails loses. This is why in the past decade we've seen seemingly weird business moves like Apple producing movies, NVIDIA doing game streaming, Amazon shipping games, Walmart selling video streaming, etc.
We are shambling towards a post-material world where the most valuable good, the thing that produces the most value, is human attention. And, unfortunately, a few people figured this out sooner than the rest of us and a gobbling up all of that mental real estate and leaving nothing for anyone else.
And even even that's a bit of a problem for the Servo project, as it makes it hard to move code between Servo crates and other Rust ecosystem crates (which are typically MIT/Apache2.0), which means that Servo is it's own "island" somewhat disconnected from the rest of the Rust ecosystem.
(there's nothing inherently wrong with the MPL, but it being a different and incompatible license to the rest of the ecosystem does cause problems)
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
This article is already largely irrelevant. The GPL (and the FSF), whether you like it or not, always has been a political movement. The aim of the movement is to expand the pool of free/libre software and to disallow commercial entities from gaining an unfair advantage without contributing back. With the GPLv2 they already have, as it permits them to run the software in the cloud, with their proprietary additions, without contributing back. AGPLv3 closes that loophole that's why it's even less popular.
You can license your software as you wish, but in the long run the GPL has ensured that contributions reach back upstream for the common good, rather than for profit. The GPL gives protections for the people/end consumers, much like labour laws do in your own country. The GPL ensures that your contributions are respected, available to all, and not abused for profit (not always true, but tribunals have enforced the license terms before). The GPL has the effect of doing this globally while allowing contributions back from a global audience. It's genius and the companies absolutely hate it.
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?
You could even argue the other way.
Proprietary market leaders are not cash cowy enough for the next generation of CEOs, get enshittified, FOSS slowly takes over.
> 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.
It's a worthy tradeoff if your goal is to have the best (free) software possible, rather than making as much money as possible
// 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
I agree.
People seem to judge these licenses with measures that might not mean anything to the authors or the users. There are different kinds of authors and users.
GPL authors want their rights preserved for the users. MIT authors might just want their stuff "out there", or really not care how their stuff is used.
The aregument here is sort of like judging football as more relevant than baseball because plays are more exciting but short enough to still show ads on TV.
(also both gpl and bsd licenses have been around ~40 years, so what does long run even mean?)
Your comment is ignoring the realities and practicialities in the real world, just like GPL does. GPL is a theoretical idea that doesn't work in the real world, because in the real world, not everyone wants to or even can share their work products with everyone, and especially not just because some person talking about "libre software" says so. No one really cares if they have access to their refrigerator's source code.
There are many, many software libraries and tools that are excellent and yet aren't popular. A very common reason as to why they aren't more popular is because they are often licensed with GPL.
> GPL is a theoretical idea that doesn't work in the real world
GPL has been working in the real world for the past 36 years.
> No one really cares if they have access to their refrigerator's source code.
I do, and believe it should be mandatory to open source such code. Proprietary code is an immense security risk.
> why they aren't more popular is because they are often licensed with GPL
There's no evidence of this whatsoever. You can't prove or disprove such an assertion.
> GPL is a theoretical idea that doesn't work in the real world, because in the real world, not everyone wants to or even can share their work products with everyone
In practice, that is wrong. GPL software is useful even in a corporate environment because you are required to distribute your modifications only to the users who you distribute the software to. So if your modifications are meant for internal use only, then it's perfectly fine to keep the modifications confined to internal distribution.
On the other hand, if you're talking about publicly distributing modified software with undisclosed modifications, then you're financially exploiting the labor of the original contributors. They did most of the work from which you derive monetary profits. The fair thing to do in such a case is to negotiate an alternate arrangement with the original contributors. Or you could opt to distribute the changes according to the original license, if that's an acceptable option.
I have seen GPL software used in corporate environments in both the manners described above, without any sort of legal or ethical concerns. But the avenue of unpaid labor is so enticing for many large tech companies, that they fearmonger against copyleft licenses as if they're the worst crime committed against open source. Their argument is that copyleft licenses are too restrictive. Restrictive to their financial ambitions, perhaps? Because I don't see them restricting the developers or the normal users in any manner.
> A very common reason as to why they aren't more popular is because they are often licensed with GPL.
They're unpopular simply because of the vilification campaigns I mentioned above. It was very popular at one time to diss on copyleft licenses without a discernable reason. That was until many realized that the permissive licenses, combined with CLAs were an easy avenue for many of those companies to extract free labor from them.
Just anecdotally, but this aligns with my observations on the trend/growth of successful useful open source projects that go with permissive BSD-like license. ~20 years ago there were way less of those than now.
And as a SW developer doing client side/apps as well, using GPL/LGPL is a total pain and basically cost prohibitive, unless I work on my personal small project where I don’t care about having to/risking to open source the rest of the code and getting sued/cloned…
Real life example from ~2010 - we ended up including an LGPL library in our mobile app code, and published/upstreamed all the modifications we did to that code (mostly ARM optimizations). Once the app became popular, our competitors came to us demanding the source code of our app - just because iOS didn’t support dynamic libraries (so we had to statically link it), and giving them the object code to relink it wasn’t enough for them (which would satisfy the spirit of LGPL), because they really wanted to see how we hacked around iOS camera input APIs…
> giving them the object code to relink it wasn’t enough for them (which would satisfy the spirit of LGPL)
Doesn't that also satisfy the letter of the LGPL v2?
> Accompany the work with the complete corresponding machine-readable source code for the Library [...] and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library
Deliberately so, moreover, because distributing object files for relinking used to be common[1].
[1] https://lock.cmpxchg8b.com/linux123.html
> giving them the object code to relink it wasn’t enough for them (which would satisfy the spirit of LGPL)
So they can take a hike?
I agree that permissively licensed projects are more successful if you define "successful" as "having the most number of users possible". Of course, this "success" often results in the unpaid volunteer maintainers being inundated by bug reports and feature requests from employees of major corporations, so there's drawbacks to that approach.
Yeah, you're saying that BSD code, which you can get for free and give nothing, is the most convenient thing for you in helping you create closed source commercial programs. Well sure.
I'd mention for a commercial library creator, say QT, the GPL can be quite convenient because the commercial clients they have can't just take their stuff for free and use it but instead can use the GPL to sample and then come for a commercial license when they're going to use it that way.
That is to say, just about every license that is used today serves a particular purpose for vendors and thus none of the licenses are likely to go away as long as we have different vendors with different aims.
> using GPL/LGPL is a total pain and basically cost prohibitive
It's not, if you can comply with the license.
If you want to take advantage of free (L)GPL code in statically linked binaries without providing the source code to your customers, then yes, that is a problem. Although with LGPL the linkable binaries should probably be enough.
I think the LGPL is becoming particularly irrelevant. I’d like to use GEOS (LGPL 2.1) in a macOS app but the risks are high as you point out. I think it’s going to be significantly less risky long run to rebuild GEOS in Swift. The complexity and lack of clarity in the licensing is a real burden.
I don’t think this is the spirit of the LGPL - it’s just code signing prevents the use of dynamically linked libraries in the way LGPL intended.
> just because iOS didn’t support dynamic libraries (so we had to statically link it)
if you develop closed software for a walled garden then relying on gpl is still possible but a rather contradictory philosophy. i guess the alternative would have been developing all that from scratch, or getting it from elsewhere, likely paying for it, which would have made those costs even more prohibitive ... otoh i really don't understand those prohibitive costs because supplying the object code was all you needed. what were those? lawyers?
I can think of at least a few counterexamples. The logic behind the hypothesis is decent and tells a plausible story, but I'd like to see a more robust analysis; has anyone done one since the article was first posted 10 years ago?
Noteable counterxamples (excluding e.g. Linux):
- Git (GPLv2)
- Blender (GPLv2 & 3, from the looks of it)
- Krita (GPLv3)
- MySQL (GPLv2) -- still seems very popular in 2025
- QGIS (GPLv2)
I always use git as a binary and don’t have any interest in forking it.
Most of the new databases of last 15 years have some kind of restrictive license that aims to stop AWS from selling a managed version of it that also limits what I can do it. So they are dead to me. Postgres is growing not just because it is a good database which is taking ideas from document databases, but because you can build on top of Postgres and feel confident that you can commercialize or open source your work and people will be able to use it.
Blender used to be proprietary,the community had to raise money to buy the source code to make it free software. What a crazy success story for opensource.
Don't forget Qt (though I think that's more a corporation wanting to create an incentive to make commercial users pay for a license)
Git - jj[1] uses gitoxide for its git interop/backend (git being the backend of jj you're expected to use), both Apache/MIT; it functioned so cleanly I assumed it was invoking git directly, but apparently it's all custom!
For new things I'd guess PostgreSQL vs MySQL is probably on the same order as llvm vs gcc; probably with PostgreSQL being better off than llvm even.
[1]: https://github.com/jj-vcs/jj/ (started by a Googler as a hobby project, now their full-time job at Google, so kinda fits into the "big orgs will replace things with permissive-licensed versions" narrative)
jj does shell out to git for network operations these days, but the majority of it is gitoxide, that's right.
Ah, that appears true. I just tested some commit creation & state inspection commands, didn't bother with network stuff.
It’s a recent change, there were just too many folks who had network requirements that it couldn’t do, so it’s easier to just piggyback on top of git, which supports all that stuff.
> Notable counterxamples (excluding e.g. Linux)
These are mostly executables/end products, aren't they?
GPL allows protecting the business logic by discouraging hostile forks: after all, forks of such projects can't relicense GPL files w/o permission, and upstream can just copy the changes back w/o having to ask.
On the other hand, permissive license favor dissemination. Would {fmt} (libfmt) be as ubiquitous as it is, if it were GPL instead of MIT?
Notably, libgit2[1] is GPLv2 with a full linking exception, while e.g. go-git[2] is Apache2.
[1] https://github.com/libgit2/libgit2
[2] https://github.com/go-git/go-git
In the very long run I'd hope we get sane intellectual property law: Software and logic circuitry is mathematics and should be unpatentable and trade secret is about the only protection for software/firmware/hardware; copyright terms shortened to the actual window of profitability (5-10 years) and only applying to "business logic". Nothing else makes much sense in the modern world; standards and interoperability benefit everyone to such an extent and change happens so rapidly that the majority of existing IP protection duration only harms historians.
Yeah, copyleft has always been just a hack to cope with the current legal framework
One could argue that business logic is mathematics as well.
> and only applying to "business logic"
One person's business is another's platform.
That's why I used the scare quotes; I don't have a hard and fast rule here for what's legitimate market-making software value and what's just rent-seeking.
I think that much of the core features in Desktop Photoshop-style products or video games probably requires legitimate short copyright, for example. I don't think copyrighting a plugin interface or header files or hardware drivers makes any sense, unless there's significant creative work like e.g. the portions of GPU drivers that trade off appearance and speed in novel ways.
The AS/400 (now IBM i) platform has a neat feature: all application software is compiled into a sort of bytecode called TIMI, for Technology Independent Machine Interface. The use of TIMI is completely transparent to developers and is implemented at an OS level; you as a programmer do not get access to the underlying instruction set. When a program is run, if the OS does not detect a native-code "shadow" binary for the program, it will AOT-compile it from the program's TIMI code before running it. Among other things, this allowed IBM to convert their systems from AS/400 CISC to 64-bit POWER-architecture in one swift yank of the tablecloth, with all application software running 100% backward-compatibly on the new architecture.
But that's not the reason why TIMI was implemented. TIMI was implemented to fulfill an antitrust consent decree, under which IBM agreed to unbundle IBM hardware from software. But they still wanted to ship an OS with each system! So they declared that the OS was "firmware" and "microcode", hence part of the hardware, despite being loaded and booted from disk like any other OS. Anything considered "software" for the platform was written in TIMI.
So here we indeed have a bright-line distinction between OS and application code; between platform and business logic. Such a sharp definition is pretty rare in the industry.
There can never be a sane intellectual property law, if by "sane" you mean reasonable and/or free from negative consequences.
Imagine you live in the star trek universe, and we have those replicator machines which will happily deliver as much of anything to you as you wish to get.
Now imagine trying to come up with some "sane property laws" to exclude people from using them. What would even be the point of trying? How would any such attempt be anything more than arbitrarily giving one class of people unjustifiable power over another class of people?
We are actually in that very position with the fruits of intellectual labor. Just because one person is using a program, or an algorithm, or a theorem, that doesn't prevent anybody else from also using it.
So any mechanism for prohibiting somebody from using a program--which is to say, any mechanism to turn a program into property--is going to be globally suboptimal. It is going to arbitrarily harm one class of people so that another class of people can benefit.
The genius of the GPL is that it it gets this. The miracle of the GPL is that has found a way to give us something like a replicator machine even in this ultra-capitalistic society.
Your star trek example is cute but misses one important point: cost.
In ST there is apparently an infinite energy source running these replicators, so almost no cost. For any software project, developmemt and maintanenace costs time/money, so anyone replicating your invention or contributing to your project requires time/money(/expertise as a derivative).
That's what the GPL doesnt get and what scares me alittle about the future of the linux foundation.
Imagine Torvals gone and only highly payed corporate devs maintaning the linux kernel and worse, controlling the foundation. If a user hostile descision is made and the nerd outcry is shacking the force, what are they supposed to do? Forking and maintaning their own kernel in competition with high velocity veterans that just boil the frogs slow enough?
I cant imagine this succeeding. Just look at the slowly shrinking market share of BSD.
https://w3techs.com/technologies/details/os-bsd
Or the very uneven fight between MS Office and LibreOffice.
// In ST there is apparently an infinite energy source running //
Think about a server farm, which rents out cpu time for linux servers. Sure, you have to play for energy, land, and labor. But are you saying that somehow implies that linux would have to be BSD licensed instead of GPL licensed?
I agree, energy, land, and labor are things which we don't have infinite supplies of, and therefore we need some way to ration them and distribute them efficiently. But I don't see what bearing this has on software licensing.
// If a user hostile descision is made //
Yeah, I don't see what this has to do with BSD vs. GPL or any other software license. I mean, Microsoft has been "boiling the water" forever.
// cant imagine this succeeding. Just look at the slowly shrinking market share of BSD. //
So the answer is not releasing things under the GPL? I don't quite follow the argument here, would you care to clarify?
> If a user hostile descision is made
> I don't see what this has to do with BSD vs. GPL
That is my point, license does not matter that much (and i meant the BSDs OSes). A license is not the only barrier of participation, you need to have the resources (time/money/expertise) too, and when you enter as a directly competing fork with marginal market share, you better have more resources than the parent project or otherwise your fork will not be able to keep up to with an adversarial company, trying to keep that jucy monopoly, they might have build ages ago with community contributions.
Forking and maintaining a gigantic project is not really a practical option for angered hobbyists. The costs are too high or competition to harsh.
IMO this is not only a problem of the GPL but of FOSS in general. Lets call it capitalistic capture.
This whole argument hinges on the statement that the GPL "does nothing for users" but is "annoying for developers". I dispute both of these claims.
GPL is all about doing something for users. It is users who are able to request source code. My entire network setup is based on the fact that I can customize my router which I can only do because users were able to request the source for the router in order to customize it.
When it comes to "annoying for developers" we need to be clear. The GPL is annoying for developers of software that is not open source. It annoys them because it says they must either take the open source deal or else rewrite it themselves. Apple has famously used a lot of time and money to rewrite GPLd thengs. This is the goal.
OTOH open source developers need not be annoyed by any GPL dependency since they can always use it without any trouble to themselves.
> The GPL is annoying for developers of software that is not open source.
It is also annoying for developers of open-source software that is not GPL-licensed.
It doesn't need to be, since they can still use it and keep their license the same etc.
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.
> 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]
* https://en.wikipedia.org/wiki/LLVM#History
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.
> OTOH open source developers need not be annoyed by any GPL dependency since they can always use it without any trouble to themselves.
Counterpoint: GPLv2-only is an absolute PITA to deal with but that's the point; GPL (especially v2-only or v3+section7b,7c) is good at preventing hostile forks
This,
Moreover, a company can release a GPL'd version of their software and also offer a commercial license for their software (see Qt etc). So someone who's charging for their software can use it if they themselves pay. Some commercial vendors might annoyed by even this. But it would seem they "doth protest too much".
It may be true, but the GPL is uniquely positioned to create a floor that ratchets upwards, whereas the other licenses are susceptible to being consumed and extended.
> […] whereas the other licenses are susceptible to being consumed and extended.
Often in practice people found that does not work with BSD/MIT-like licenses: you keep your changes and patches in-house and the original project moves forward. You then have to keep carrying forward your work, and you're either losing out on public fixes or have to expand energy to fix merge conflicts.
Lots of vendors learned this the hard way with (e.g.) FreeBSD: you want to follow the development branch (-HEAD) and merge early and merge often.
An exception to this would be one-shot forks, like Sony did with the PlayStations: you have your base functionality and it will never change for the life of the product so you don't really need future updates.
True, but the article makes a point that it's very hard and unlikely to maintain technological superiority over a coproration that's determined enough. A corporation simply has much more resources. See also: https://hypercritical.co/2013/04/12/code-hard-or-go-home
> maintain technological superiority
Is this ever an actual goal for most GPL projects? Usually the ones I talk to are not even interested in gaining more users.
I'd say no, crushing / surpassing the competition is not a goal for non-commercial software and it doesn't have to be.
The thesis is that "GPL code becomes irrelevant", and they are probably right about GCC. It doesn't mean GCC goes away, just that it will become irrelevant to more people. Sun Studio and Borland C++ are even more irrelevant, not sure where that fits in the conversation. Is MS Visual Studio becoming irrelevant?
From a developer/business point of view, there's no reason to use a more restrictive GPL dependency if it's not clearly "superior" to a permissively-licensed one.
The article makes a case that this will eventually push GPL out of the mainstream. No one will use GPL because they "have to" (which is the whole premise of copyleft!). It will only be used by enthusiasts
If the business wants to develop non open source software, then having them not use the GPLd project and thus profit off the free labour of others is a wonderful outcome.
Your argument is in terms of "fairness". But most users don't care about fairness. They care about better software. I'll use a permissively-licensed project if it's better. Most people will use a proprietary project if it's better.
The article makes a point that permissively-licenced projects have the best survival characteristics, and that's why most (quality) software will eventually be permissively-licensed, while GPL will fade into obscurity and will be used only by enthusiasts why care about fairness more than they care about the actual quality of the software that they use.
> But most users don't care about fairness. They care about better software.
Users care about convenience and familiarity, then perhaps (perceived) functionality. People who care more about quality are a niche, not only in the software industry. Prioritizing quality means higher cost in some way, even if it's just effort to research the best choice.
> Most people will use a proprietary project if it's better.
Most people don't even compare available choices. Usually they don't choose based on license, but based on popularity or familiarity, based on what's the standard in the industry or within their community. If a user's been running a tool for years and it's good enough for their purposes they have no reason to look for an alternative, and the license or whether it's "better" is irrelevant. And big tech platforms love to amplify this effect with dark patterns and various forms of lock-in.
But software developed by enthusiasts might be better than software designed by managers and hoards of beginners using AI.
Software developed by enthusiasts that also receive patches from corporations (that can use the software thanks to a permissive licence) might be even better
I think those same people I mentioned would argue that being mainstream is also not a project goal, nor is utilization by corporations at all.
I have to admit I think a lot of people with this sort of "death to capitalism" mindset simply won't get anywhere, because they literally don't want to. I guess that means they may eventually fade into obscurity.
But the majority of project leaders I have talked to all seem to follow this mindset... they're not interested in making money, and "this is not a popularity contest."
Yet when a fork inevitably emerges, they go nuclear. Reminds me of a quote I saw one time... "they don't want open source, they want to be the ONLY source."
While it's not the explicit goal, it was because of technological superiority that most of us got into free software in the first place. There was a time where Linux worked great while Windows 98/XP struggled to maintain in its own feet without crashing down (yes, even XP)
While there's nothing wrong with purely enthusiast projects, they never got the amount of traction practical FOSS projects get. How many users does SerenityOS have, compared to Linux?
I invite people to ask themselves, do we really want a "pure hobbyist Linux OS"? How many modern feature are we willing to surrender for it?
>> technological superiority
Haha. I work on Solvespace which is technically inferior to FreeCAD, which is also inferior to the big commercial offerings. We shall have our MVP in a few more years! Most our contributors would not be working on it under an MIT license. I certainly would not.
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
> Most users and contributors put the functionality above copyleft
Most users put functionality above the license, copyleft or not. Among two comparable projects one will always be more popular and I highly doubt the license is often a deciding factor for that.
> It implies that copyleft projects such as yours will be largely pushed out of the mainstream
Those CAD projects were never in the mainstream to begin with. And FreeCAD might have a niche target audience but for me it has no viable competitor. The situation got better in recent years but I don't see why I should make myself dependent on a subscription based commercial project that's incompatible with everything else including other products from the same company.
> Such permissive projects will always spead and develop faster, all other things being equal
Such as? Wouldn't one expect BSD systems to have overtaken Linux in the last three decades with that assumption?
I thought the author made the case that because of complexity economics the ratchet still works either way, and in fact that in 2025 GPL is actually a less-strong ratchet compared to Apache and MIT. If GPL was the stronger Ratchet you wouldn't ever expect to see an existential risk to a GPL project posed by an Apache one right?
Licenses that allow more collaboration end up winning, and permissive licenses allow more collaboration.
That said, the source-availability requirement of the GPL did help kickstart things.
In the 80s every unix vendor had their own closed source version of everything. The GPL - through the requirement of source availability - helped flip the industry over to collaborative building. It would’ve never gone that way if those working in the open did it under permissive licensing - that would have given closed-source vendors free labor and discouraged those working on free software.
Nowadays it’s about velocity. In domains where collaborative building is producing more better software faster, it’s more expensive to work behind closed doors than to take others’ work for free. So you may as well use the open thing. And then when you want to add features or fix bugs, it’s a hassle to maintain your own fork while integrating new work from upstream. So you may as well upstream your work too!
>But think of the multi-trillion dollar companies!!
If companies want to use manpower to reimplement GPL code, then fine. It’s always funny how accommodating people are for these companies.
The point of the article is that:
1. In most areas, they eventually will!
2. If there is a permissively-licensed project in that area, at least there's a decent chance that the "reimplementation" will be a fork of that project. At that fork has a decent chance of staying open or even being merged back into the upstream. That benefits the community more than a proprietary from-scratch rewrite (which would follow from a GPL-only open-source scene)
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.
If you're going to talk about theoretical behavior from big companies, you can make stories any way you want.
Let's say a big company selling computers wants to include a PCB editing software by default. If KiCAD was Apache licensed they may be tempted to make a special version for their customers, as a unique selling point. But it's GPL, so they have to choose between rewriting completely (a huge process), or just publishing the changes and being happy to include a good program.
Or a company makes modifications to a GPL program for internal use, and decides they want to share it with partners/customers later.
I have no reason to think these stories are more or less likely than the story of a company completely rejecting the GPL option but still deciding to upstream their changes.
Didn't Sony gobble up a whole bunch of stuff from FReeBSD for the last few Playstation release without hardly contributing anything back at all ? IIRC the might have sent some patches to improve SMP or sponsored a conference.
Same with Microsoft and the Windows TCP stack lifted from BSD as well.
Compare with GPL licensed projects, like the Linux Kernel & its license making many projects possible, like the OpenWRT project for example.
Yeah I see a lot of corporate backing of Linux (GPL) and a bit of proprietarization of non GPL OSS. Meanwhile my employer also uses git and gcc, which are both GPL.
Companies that use software like it Free. Companies that develop software like it permissive. There are more users than developers, especially for large more important programs.
> 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
For a library I see what you mean, maybe that's the main case you're thinking about.
But for applications, if they are willing to invest the costs to rewrite the GPL option I don't see how your argument makes sense.
> 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.
It's simple in my experience.
Many big companies have some set "A" of code that they want to keep private, and some set "B" that they don't care about keeping private.
Lawyers are worried that at some point someone will accidentally include GPL code in something from "A" and force it to be made public. So they ban GPL entirely. They could in theory just ban GPL code from "A" and allow it in "B", but they can't trust that among thousands of employees none will make a mistake, so they just ban the GPL entirely.
So if we're nice to the billionaires, they may return that kindness with table scraps - if we're lucky? Sounds like the tech version of trickle-down economics.
Yes, but what's the better alternative? The article makes the point that you're not even getting table scraps back into your GPL project. In most cases, the companies prefer a proprietary rewrite. Now you're just stuck with a less-developed project, while the world around you uses more-developed proprietary alternatives and pushes you to do the same. But I guess, that somehow makes you feel better because you don't let the corporations "feed off your work" and instead just waste everyone's time on infinite rewrites?
Yeah, I don't get that argument. "Apple is funding LLVM, therefore it is getting better than GCC!". They are only funding it because it advances their goals. The moment they get what they want they will drop it or look for ways to keep the advantage all to themselves.
The same could be said about non-corporate contributions. "People only contribute as long as they have a personal itch to scratch. The moment they get what they want, you're on your own again".
That's always been the deal. Open source is not a guarantee of free support forever! It's a guarantee that you can always fork and keep using the project (or even developing it further)
I'm less concerned about "free support" and more about "commons-oriented R&D".
There are some projects/people that I donate a small monthly amount. I don't do it because I'm expecting a specific feature to be developed, but simply because I think it's important to have support developers and let them work on something without being concerned about how to make a living out of their work.
Indeed, that's a very important thing to foster! In fact, I published a post about this just two days ago: https://home.expurple.me/posts/non-profit-foss-solves-the-co...
It’s just the academic method of sharing your work so the collective knowledge and state of the art increases monotonically. People seem to like to productive it, but even just publishing your source code so I or my llm can read it and modify it is useful. Very useful.
Everyone only does anything if it advances their goals. Luckily Apple's goals w.r.t. LLVM are the same as everyone else's: have a high-quality compiler backend.
Beware of sweeping generalizations. Most people only do things when it advances it goals, but there certainly are people that do things simply because they think is the right thing to do.
"Doing the right thing" (whatever that means for a person specifically) can be considered a goal too. Goals don't have to be selfish.
A goal implies a clear objective. "Doing the right thing" is a guiding principle.
"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.
> Following my inner guiding principles without compromising" seems clear enough.
To me, it's not. What are the outcomes that we are talking about here?
> You clearly feel when you do the wrong thing.
Do you think that the developers of, e.g, KHTML felt they were doing the wrong thing when they started working on a browser engine for Konqueror under LGPL? Would they continue working on it had they known that Apple would take their work to build what is arguably the most freedom-restricting web browser out there?
> 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
> Living a life free of guilt and regrets.
Sorry, this is not an outcome. Maybe you can say it's an strategy to help you define your priorities and it can help you set your goals in whatever endeavor you're taking on, but it's not something that has a clear goal post.
> Safari isn't so catastrophic and harmful
Taken in isolation, no it's not so bad. But the issues of Safari are the context where its development happens. Safari is intentionally stripped of any feature that could threaten Apple's market dominance in the mobile market.
And that is the problem with too-permissive software licenses.
Some people always forget that GPL is about the end user's rights, not developer's rights. If a fortune 500 re-implements some GPL library to make proprietary, then by all means. It changes nothing for the GPL code, it's still GPL and its license should guaranty user's rights.
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.
> But a proprietary fork doesn't change anything for permissively-licenced projects either!
It just mostly makes them irrelevant by EEE. A permissive license is simply asking for it.
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
Some people also forget that end users are also developers themselves. GPL helps everyone in this way.
> With enough time, any sufficiently large company can implement their own version of any software that anyone else has written. They usually won't write their own version if a high quality opensource version exists with a permissible license.
Is this a true assertion? If you define sufficiently large company to be Google, Microsoft, Amazon, etc. then sure, of course they can. That's an extremely high bar though and I would bet that even then, these companies would have to pick and choose their battles.
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
Great writeup! I couldn't agree more.
I've been thinking about this a lot recently, because GPL was meant to ensure that vendors couldn't take OSS, turn it into closed source, and use it to extinguish the OSS.
As JS-writing eng I live in an MIT-native offshoot of the OSS world and for us the ratchet that ensures we always get more and more free software is basically the fact that when your product is a script run in a scripting engine you can't ever truly hide anything.
Since we have an alternate ratchet that has proven that it works to increase the amount and quality of OSS (over a 20-year time period), the GPL does seem as you say: a relic of times when we it seemed like software might only be a hobby.
I'm writing a VCS kernel, basically, and its cost me the last 5 years of my life. My code is MIT. Do I have to think about the dangers of embrace-extend-extinguish? Yeah, but having the best product is a very strong defense, and building the widest coalition of supporters you can is how you get there.
To be more clear: my strategy is to eliminate the room that could be used to undercut me with more virulent technological or techno-social solutions.
GPL would not be eliminating the room to undercut me with a slightly more viral clone of my product, but rather creating more room to undercut me. This is a real problem for a piece of software the value of which is in simplicity not complexity!
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.
What makes the GPL irrelevant is AI. AI in it's current incarnation is basically a magic copyright remover. It can memorize all the patterns, tricks, algorithms, and architecture of open source software and implement it again. In a few years you won't need git because you will just have an AI stamp out a git compatible tool if you need one.
So if you care about Freedom, we need to move the battle from making sure you can get a copy of the source code to git, to making sure you can get a copy of the weights of the AI you are using to create software on demand.
> 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.
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.
If this is correct then the lgpl would be ideal?
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.
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.
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.
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.One of the interesting things about the experience of LLVM and Clang isn't that it's killing off gcc--a decade after this was written, gcc is still the compiler of choice for most Linux distrubtions--but that it's killing off EDG, the C++ frontend that all proprietary C++ compilers used to use. Killing off proprietary software because the open source stuff is so much better is the vision of Stallman, and it's telling that a permissive license has been much more effective than a copyleft license in doing so.
That's completely orthogonal to the choice of license, but rather to the architecture of both projects.
> The flaw is that in the long run, it keeps getting easier to write software. And people love reinventing the wheel.
See: Bram's Law
https://files.catbox.moe/qi5ha9.png
The most annoying part about reinventing the wheel might be renaming the wheel.
Ignores the MPL as usual. IMO the MPL is better than BSD/MIT/Apache since it prevents your code getting closed, and better than GPL by not forcing others to open their code.
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)
using BSD/MIT licences is like betting against black swan event
sure, "contributing is cheaper than maintaining a fork" is true most of the time - but the moment new Microsoft comes in with "embrace, extend, extinguish" (or just copy and change), you're doomed
and heck, we had that exact thing happen last autumn, iirc - making big news on this website
> you're doomed
You're making a big stretch here. Sure, you can be left in the dust behind their proprietary fork, that's true: https://hypercritical.co/2013/04/12/code-hard-or-go-home
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.
>> Free software was never about "free upgrades forever". It's about the freedom to fork.
I never noticed the word "fork" in the GPL. You may want to reread it, as I think you missed the point.
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
Can you clarify what happened last autumn? I'm not sure I recall.
Probably this: https://news.ycombinator.com/item?id=43587420
That would be one example. What about Redis pulling a license change, and the whole WordPress battle for control?
If it ain't GPL and it IS popular, I think those kinds of things are more likely to happen than not.
Stallman is a real visionary warning us about those risks since de 80s.
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
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
iirc, some kubernetes library under BSD
microsoft spent a lot of time asking questions to the author - and then rolled out Azure copy of the lib
author went public "how dare they use me like that" - but he did make it BSD himself, it's his problem
I think this is largely an illusion. Most open-source software isn't that successful, so it might seem like the choice of license didn't really matter for their success. But you'll notice that 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).
The author talks about GPL projects feeding back on themselves to create technological dominance. But it's much more than that. GPL encourages organizational dominance, too. It starts with watch dogs looking out for GPL violations. And it ends with a big nonprofit foundation providing training and paying developer's salaries. Why did Linux blast past BSD? The popular story is that some company was trying to claim ownership over BSD. But the same thing happened to Linux a decade or so later with SCO. I think the license created a no-win situation for anyone who wanted to create their own Unix-based OS. If it wasn't Linux-compatible, it wasn't valuable. And nobody could keep up with Linux's rapid pace of development. So everyone gave up and started contributing to Linux, causing the pace of development to increase even more. Now, Linux has what, a million commits per year? Something insane like that. Try achieving that with a BSD license.
> 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
Those are the big open-source projects?
Are you seriously trying to imply that Firefox and Chromium aren't big open-source projects? Define "big" then. "Literally only Linux"?
I think that the SCO threat to Linux also came at a time when Linux was pretty immune from such a threat. If it's the early-90s and there's two options in their infancy and one had AT&T (one of the 5 largest companies) threatening it, you'll go with the other. In 1993, you're not using BSD or Linux and making a choice between them. The legal threat weighs heavy there.
When SCO sued IBM, people were already using Linux including one of the biggest and most trusted names in computing (at the time): IBM. Migrating away from something is a hard choice. Likewise, Linux had IBM's army of lawyers defending it (yes, BSD was defended by UC Berkeley, but the school could have easily folded over a project that wasn't part of the school's core mission). SCO also wasn't much of a threat - they were a dying company trying to win a case against the biggest names in the industry.
It's a lot easier to spread FUD against something no one is currently using that has a viable alternative. In 1993, Linux and BSD may have been equal, but AT&T's legal threat carried weight. People choosing one or the other weren't already using one. By 2003, 25% of the internet was powered by Linux. People were already using it and weren't going to be scared away by the claims of a dying corporation while powerful companies were defending Linux.
You say yourself that if something wasn't Linux compatible, it wasn't valuable and so everyone had to be chasing and reimplementing Linux compatibility. But if BSD had been established for a decade and Linux was chasing BSD compatibility in 2003 and then SCO sued BSD, BSD would still have maintained dominance.
When a company claimed ownership matters. Which company claimed ownership matters. "How big" the OS was when the challenge came matters.
Frankly, reset Linux adoption to 0. Have everyone use BSD for 2-4 years. Then reintroduce Linux. You won't end up with Linux dominance. You'll end up with BSD dominance. Linux had a multi-year head start. As you note, once you become the dominant target, everyone else is chasing you. If BSD had a multi-year head start, Linux would have been chasing BSD and the roles would be swapped.
SCO was suing on two grounds. First was the claim that they were the corporate heirs of the AT&T copyrights, and they claimed that Linux infringed on them. Second was from a joint development agreement with IBM - they claimed that code from that had been contributed to Linux by IBM, and that IBM didn't have the right because it was half SCO's code (or rather, Novell's code that SCO inherited).
That second claim could not have happened until IBM was contributing to Linux. That part of the lawsuit could not have happened in 1993. (The first part was similar to the BSD lawsuit.)
To me the larger question is whether or not GPLv2 achieves the goal of forcing big companies to contribute back to a project better than a more permissable license does.
As stated in the article, Linux is the notable success story, but anecdotally it seems that the majority of projects with large company contributions are licensed with BSD/Apache/MIT but with contributor agreement attached.
I wonder if anyone has compiled any data on whether GPLv2 does actually encourage contributions more than the more permissive alternatives.
GPLv3 isn't even worth mentioning in this context, great concept, abject failure to thrive IMO.
In the long run MIT code developer becomes irrelevant
After the million dollar company forks it and includes it in their product without even saying hello. And the developer is left with a depression
I think each project, and its conditions, can take advantage of diferent licences, there are very successful projects in all of them
Yeah, the Apache/BSD licensed code will always come out on top, when some big company eats it, and effectively dictates its development with no other fork gaining any traction and with the project effectively becoming enterprise-ified.
This happens to a lesser or greater extent, but it happens.
Yeah. Related: https://hypercritical.co/2013/04/12/code-hard-or-go-home
This article doesn't reckon with cloud providers (etc) eating your project. (2015) indeed.
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
> 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
Do you have any examples of this?
BSD & Co are open source for developers
GPL & Co are open source for users
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
I think people who prefer GPL and I hope for the same outcomes but we have a different (irreconcilable?) philosophical approach to getting there.
In my view code (and all knowledge) wants to be free and a commons of knowledge enriches the whole world. I am opposed to most forms of copyright, patents and intellectual 'property'. Aside: My compromise position to this maximalist view is that I'd accept a 5 year copyright term with an exponentially increasing renewal fee.
For me MIT/BSD/Apache is a way to provide code with minimal encumbrances under the current dominant legal system. GPL is an attempt to free knowledge that relies on the legal system and the threat of men with guns coming to force you to comply. However noble the intentions at the end of the day it is reliant on state force and reduces freedom, it is very good at providing fees for lawyers.
Corporations can't embrace-extend-extinguish open source. This is because the source is always available. Sure they can use that knowledge to build a new, more popular, thing, but the existing source never goes away. It represents an un-enclosable commons.
> Corporations can't embrace-extend-extinguish open source. This is because the source is always available. Sure they can use that knowledge to build a new, more popular, thing, but the existing source never goes away. It represents an un-enclosable commons.
Some counter-examples:
* git is now mostly github
* khtml is now mostly chrome
* linux is now more android and chromeos than linux. Anyhow, the plain kernel is deeply corporate.
You can still fork those project. But it would be mostly meaningless to do so.
But this doesn't really contradict the idea, in my view. Our existing property framework is built around physical goods that experience scarcity. The cost of code duplication is zero and it is (barring catastrophe) indestructible. Today you can browse the git codebase in the same way as 2 decades prior or hence.
All the knowledge in those codebases is preserved for all time, freely available to anyone. They have been built upon in ways that don't necessarily give back but that wasn't a destructive event.
Aside: Though if I remember correctly git and Linux are GPL so they create categories of thought-crime under copyleft if a judge holds your code to be too influenced by them. How influenced is too much? You better have enough money for lawyers to find out.
> code (and all knowledge) wants to be free
What does this sentence actually mean? Every time I've heard of it it is just stated as an obvious fact with no explanation, or it seems to just mean "I want knowledge to be free".
I had prefixed that with "in my view" but in a purely literal sense you're right. Code and knowledge are inanimate objects, they don't 'want' anything. The statement is influenced by my belief, it is merely a common turn of phrase.
To expand a bit more, code is freely, instantly, trivially duplicated, shared and remixed[1]. Much like knowledge there is no scarcity for these artifacts without legally mandated, police enforced, artificial scarcity. If the full source code for anything (Windows 11, EPIC Systems, whatever) was leaked tomorrow that would be a non-destructive event for both the code and knowledge involved. People work around this with trade secrets and intellectual property law but the 'entropic' norm is for these things to become more available, not less.
[1]: Since we're being literal there is of course some energy and time cost to the listed actions.
Some situation being the "entropic norm" that things tend to without intervention is not a good reason to prefer it. If we allowed everything that costs nonzero effort for the state to prohibit, we wouldn't have a civilization at all -- the ultimate "entropic norm" is pure anarchy.
So rather than arguing from these philosophical principles I think it makes more sense to answer a pragmatic and very concrete question: is the world would be better off, or worse, for having intellectual property protections? I think it's clearly better because the existence of these protections encourages people to spend time and effort making creative works (including software). That said; I think software patents are counter-productive, as are extremely long copyright protections for software. But I think that for pragmatic reasons, not abstract ones that seem to fall apart when you examine them closely.
Ultimately you end up in an abstract or values based discussion either way though.
Your question, is the world better off, is impossible to answer in a manner that isn't based in conjecture I feel. Would people not feel the urge to create with a 20 year copyright term? 7 years? 90? zero? Aren't some of the most valuable pieces of software in terms of social good open source? What drives the creation of those?
The closest we have to a counterfactual of the current US based intellectual property hegemony is probably China, who are renowned for their lack of scruples in this matter. Isn't some part of their supercharged technical progress based off willingness to ignore IP? How much? Is California's ban on non competes partially responsible for it's innovative tech sector?
These are all fuzzy questions that are difficult to answer and you end up approaching them with values judgements in mind.
So to restate mine without that controversial phrase; the more people that can access and share information and knowledge the more we unlock the possibility of progress and improvement for the greatest number of people.
Well, that is a more coherent argument than “information wants to be free”. I disagree with your conclusion, but I’ll at least admit that we’ve now reframed the debate in terms I find meaningful: it depends on one’s subjective judgment of the relative importance of two competing interests: on the one hand, the tendency of state-enforced monopolies to encourage producing creative works for profit motives, and on the other hand, the tendency of free information to encourage faster progress.
How do things like redis, Elasticsearch, or Terraform fit into this theory?
Bro quite literally does not understand the stated practical reasons projects use different licenses, makes up rationales for "exceptions" to suit his theory.
This article is a decade old. I wonder if the author still agrees with it given how the software and corporate landscape has changed over the past ten years.
While I have always used maximally permissive licenses on my own open source software, I've been rethinking that stance in the past couple of years. I'm not sure where I stand now, but I don't fully agree with this post.
In particular, perhaps my number one fear about the world at large is that the untethered effects of economies of scale are clearly leading to a net transfer of power into the hands of fewer and fewer corporate leaders.
Permissive licenses are arguably agnostic to that effect: anyone can use the software, corporation or not. But given that large corporations already have significant economies of scale, the emergent effect is that a corporation can extract more value out of a piece of open source software than you or I can. If your goal is to discourage a handful of oligarchs eating the world, a permissive license may be opposed to that.
It's sort of like breeding fish and dropping them in a lake. Sure, anyone can then grab their rod and reel and catch a few, so you aren't privileging the commercial fisheries industry by doing so. But once the trawler shows up, they're going to harvest a hell of a lot more fish than the dude with a bamboo rod.
You may be thinking this analogy doesn't work because software isn't like fish. Copying a piece of software doesn't remove a fish from the lake for others to catch. But think about this at one level of abstraction higher.
Copying software accomplishes nothing. It's just bits sitting on a disk. It's software being used by humans that matters. When a corporation takes a piece of open source software and puts it in front of users, time a user spends using that corporation's code is time not spent doing anything else.
While software itself isn't a consumptive good, human attention is.
Notice how all of the biggest, fastest growing corporations understand this. Attention is the ultimate economic commodity. Any company who can mine it effectively wins and any company that fails loses. This is why in the past decade we've seen seemingly weird business moves like Apple producing movies, NVIDIA doing game streaming, Amazon shipping games, Walmart selling video streaming, etc.
We are shambling towards a post-material world where the most valuable good, the thing that produces the most value, is human attention. And, unfortunately, a few people figured this out sooner than the rest of us and a gobbling up all of that mental real estate and leaving nothing for anyone else.
All large FLOSS programs are GPL licensed.
Even with all the Rustaceans rewriting in Rust while abandoning the GPL, their flagship - Servo - is GPL licensed.
There is an aversion to CLAs among those donating their time, and with that an aversion to permissive licenses.
Im sure both will be around for a long time, but in the very long term GPL wins.
Servo is MPL not GPL licensed.
And even even that's a bit of a problem for the Servo project, as it makes it hard to move code between Servo crates and other Rust ecosystem crates (which are typically MIT/Apache2.0), which means that Servo is it's own "island" somewhat disconnected from the rest of the Rust ecosystem.
(there's nothing inherently wrong with the MPL, but it being a different and incompatible license to the rest of the ecosystem does cause problems)
Factually not true.
Clang/LLVM: permissive
Rustc: permissive
Firefox: MPL
Chromium: permissive
Postgres: permissive
LibreOffice: MPL
CPython: permissive
and so on...
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