Linus Torvalds credits the GNU General Public License version 2 (GPLv2) with helping Linux resist technical fragmentation—not with causing its success by itself. In a 2016 conversation, he argued that the license’s give-back expectation made it harder for companies to take improvements in separate directions without contributing them to the shared kernel.
What Torvalds said about GPL and Linux
At LinuxCon North America in Toronto in August 2016, Torvalds discussed the license with Dirk Hohndel. CIO published an edited account of their conversation on 27 August 2016. Torvalds said he had worried Linux might fragment as Unix had, and credited GPLv2’s reciprocal terms with helping keep fragmentation technically unviable.
“I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back, which meant that the fragmentation has never been something that has been viable from a technical standpoint.”
The key qualification is in his wording: GPL was one defining factor. His claim is an explanation of how reciprocity could support a shared kernel, not proof that the license alone made Linux successful.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11How the give-back dynamic can limit technical fragmentation
In Torvalds’s explanation, companies can adapt Linux for different needs, but sharing changes back with the upstream project allows those improvements to become part of the common kernel. If useful work stays separate, its maintainers must carry and update a private set of changes. Over time, that can make a distinct fork costly to maintain. When changes return upstream, multiple users can benefit from one evolving codebase rather than each sustaining a divergent version.
This describes an incentive and a possible technical effect, not a guarantee that every modification is shared or that forks cannot exist. Torvalds also acknowledged that market differences could still lead companies to want separate versions.
The SGI example was Torvalds’s recollection
To illustrate the process, Torvalds recalled SGI pushing Linux toward machines with 1,000 cores when the standard kernel was not ready. He said he suggested that SGI make a specialized version, but that the company continued moving work back into the common kernel. Later improvements addressed the original limitations and reduced the need for separate changes. This is Torvalds’s anecdote, not an independently measured case study.
Why Torvalds chose the GPL
In a 1998 interview, Torvalds recalled changing Linux’s license to the GPL in the first half of 1992—“March or April, I think.” He said the previous license effectively prohibited commercial distribution. He preferred the GPL because he wanted contributors’ future improvements to remain available to the community.
Rank #3
The relevant license is GPL version 2. The Free Software Foundation’s 2005 background essay identifies Torvalds’s adoption of GPLv2 for Linux, and his 2016 comments specifically praised that version. His argument here should not be read as a claim about GPLv3.
GPLv2 is a project choice, not a universal winner
Torvalds has also said GPL is not inherently better than BSD-style licensing; the right choice depends on what a project wants to accomplish. In the 2016 account, he described reciprocity as a way to reassure outside contributors that a company could not simply take shared code private, while recognizing that permissive and proprietary approaches may serve different goals.
For a project weighing licenses, relevant questions include whether modified code must be shared under particular distribution conditions, what the project’s community and commercialization goals are, and what contributors expect. Those are broad considerations, not a compliance guide: precise obligations depend on the license text and circumstances, so consult current legal guidance when making a licensing decision.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why the license is only part of Linux’s history
The Linux Foundation’s retrospective puts kernel growth in a broader setting that includes userspace tools and the technical, administrative, and legal infrastructure needed by a growing contributor community. That context matters: a license can shape how code is shared, but it does not by itself supply the tools, coordination, or surrounding software that make a project useful and sustainable.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Best Value
Git offers a related example of development infrastructure. In a 2015 Linux Foundation interview, Torvalds described creating it because the kernel’s distributed development needs were not met by the source-control tools available to him. Git helps explain how the project’s workflow evolved; it is separate context, not evidence that GPL caused Linux’s success.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
