The GNU General Public License, or GPL, played a key role in the development of free and open source software. Today, however, many programmers and companies are passing on the GPL in favor of alternative open source licenses. Are they relegating the GPL to the past? <\/p>\n
The GPL is designed to ensure that the source code of a program will always be available. It also requires that programmers who make changes to a GPL-licesned program and release that program publicly share the source code of their modifications. <\/p>\n
When it originated in the 1980s, the GPL was a huge innovation. It wasn't the first software license that protected source code, but it was the first to do it in a legally sophisticated way. <\/p>\n
The GPL also said nothing about preventing programmers from charging money for software. That was important because many other early free software licenses -- such as the one that protected the trn program, and the original license of the Linux kernel -- required that developers not attempt to profit from a program. <\/p>\n
By allowing programmers to charge money if they wished yet requiring them to keep source code open, the GPL laid the foundations for the thriving commercial open source channel that exists today. <\/p>\n
Along with closely related licenses, like the Lesser General Public License (LGPL) and Affero General Public License (AGPL), the GPL became the legal tool that helped major free and open source software projects to thrive in the 1980s and 1990s. It protected most of the utilities that comprised the GNU operating system, including tools that were widely used outside the GNU project, such as GNU compilers. <\/p>\n
Linus Torvalds adopted the GPL in the fall of 1991 to protect the Linux kernel, which had been governed for the first few months of its existence by a crude license Torvalds had written himself. <\/p>\n
The GPL also protects software like GNOME, a widely used desktop environment for Linux-based computers, and MediaWiki, the software engine that powers Wikipedia. Even Android phones contain a fair amount of GPL-licensed software, particularly because part of the Android codebase is derived from Linux. <\/p>\n
Today, three decades after its birth, the GPL is proving much less popular. <\/p>\n
While the GPL or closely related licenses continue to govern important GNU utilities and the Linux kernel, the developers of most major open source projects that have emerged in recent years have opted for other licenses. <\/p>\n
Hadoop is licensed under an Apache 2.0 license. So is Apache Spark and most of the other big-name big data projects. <\/p>\n
Most parts of Docker's software for creating application containers are licensed under Apache and MIT licenses. All of the major container orchestrators -- Swarm, Kubernetes and Mesos Marathon -- are Apache-licensed as well. <\/p>\n
The key difference between the GPL and Apache and MIT licenses is that the latter licenses are more liberal. They generally allow programmers or companies to make modifications to an open source program without having to share the source code of the updated version. <\/p>\n
There are two main explanations for why the GPL is no longer as popular as it once was. <\/p>\n
The need for commercial support <\/p>\n
The trend away from the GPL is especially salient among open source platforms that are commercially important. Smaller projects, or those with little commercial promise, are more likely to use the GPL. <\/p>\n
This suggests that business calculations are behind the move away from the GPL. Developers (or companies that employ them) who want to benefit from the support and momentum of commercial investment in their open source projects stand a better chance of getting that investment if their code is licensed under a liberal open source license, rather than the GPL. <\/p>\n
This doesn't mean the GPL is not good for business. The commercial success of Linux proves that that is not the case. But perceptions may not align with realities in this respect: Developers or employers think the GPL doesn't work for commercial platforms, so they shy away from it. <\/p>\n
The desire to be \"open,\" without GPL baggage <\/p>\n
Also important is a shift in thinking about open source -- and openness in general -- within the software world. In the GPL's heyday, open source code remained the exception. It was still proving itself. <\/p>\n
But today, being \"open\" is just the thing you're supposed to do. If you want to succeed in the tech world, it's important to cultivate an aura of openness in some way or another. <\/p>\n
Some companies are projects do this by making their APIs open, or complying with community standards. They stop short of open-sourcing their code. <\/p>\n
But in cases where companies want to commit to fully open source code, licenses like Apache 2 allow them to do so without the political and ideological baggage that is associated with the GPL. They get to call themselves open, but they don't have to handle the perceived constraints imposed by the GPL. <\/p>\n
Whatever the reasons behind the change, the GPL's heyday appears to have passed. The GPL is not going anywhere -- there is no reason to think the licensing of projects like Linux will change -- but it is unlikely to play as important a role in the future of free and open source software as it has in the past. <\/p>\n
<\/p>\n