What’s next after GPL and Apache?

At the end of April, I wrote about the idea that usage of the GNU General Public License (GPL) is declining and concluded that although new, commercially initiated open source projects were indeed tending to adopt other licenses, the use of the GPL itself is still growing — especially among projects in its core community of GNU platform development. This article explores why commercial projects pick particular open source licenses and what might happen in the future.

Dual licensing

First, a brief historical recap: During the “open source bubble” of the mid-2000s, driven to build Web-facing solutions on short timescales, many companies used a combination of Linux/Apache HTTPD/MySQL/Perl to prototype and iterate. They were able to do this because open source specifically grants the freedom to use those packages for any purpose — to study them, modify them, and deploy them — all without permission from any entity.

[ Also on InfoWorld: Blogger Simon Phipps expounds on the inherent evil of software patents. | Track the latest trends in open source with InfoWorld’s Technology: Open Source newsletter. ]

The software that resulted worked really well, but when it came time to move to production, most companies asked for legal advice. As always happens when you ask your lawyer for business advice (instead of making business decisions and asking your lawyer to help you achieve them legally), they were told to play safe and buy a proprietary license to MySQL and Red Hat Enterprise Linux. Despite open source licenses offering everyone the freedom to use the software for any purpose, many companies were concerned that the GPL might force them to open up all their internal workings to the world.

A number of software entrepreneurs chose to base their business models on this fear. They selected the GPL for their software projects, not to promote some vision of digital liberty, but rather to exploit the fears of corporate legal advisers about the GPL. Called the dual-license model (referring to the software being available under both an open source license and a proprietary license), it depends on the software developer owning all the copyrights so that they can provide different license terms for paying and nonpaying users, and on the use of the most scary open source license possible in the eyes of inexperienced legal advisers. Today this means use of the AGPL, a variant of the GPL that is also triggered by Web deployment, unlike the GPL itself.

All the same, this approach is in decline. Corporate decision-makers have become more experienced, and their legal advisers have gained greater insight into the GPL. Purchasing decisions have come to revolve much more around the purchase of necessary services related to the software, and the GPL no longer shoos-in the business. Just selling services on open source software is not “sticky” and lacks lock-in — the four software freedoms ensure that anyone can complete on service value.

Open core as a business model As the scare value of the GPL declined, some business ventures switched to another approach. They tended to retain the GPL for the core project, hoping still to scare up a little revenue. However, more and more of them added proprietary layers on top, becoming little better than the proprietary vendors they claimed to replace. By making the features essential to enterprise deployment proprietary, they hoped to force adopters into their revenue funnel.

Moreover, since the proprietary software couldn’t be used by the community, they faced no direct competition from community members offering better value points to their customers. The combination of enterprise compulsion and lock-in was very attractive, and many projects in the late years of the decade moved to this “open core” approach.

For the customer, the problem is that instead of delivering and cultivating software freedom, the open-core business model induces dependency on closed software and lock-in to a vendor. Open-core businesses hope you’ll be willing to trade your freedom for tangible short-term benefits or even just for “shiny.”

They stand to benefit massively from having you locked in; they want to trade your freedom for their profit. While open-core businesses truthfully say they are sustaining open source core software, their actual business has nothing to do with open source. It’s a bait-and-switch, wrapping the same old lock-in under the flag of open source and hoping you won’t notice.

This is not just a philosophical game. “Software freedom” may sound abstract, but it is the system of thinking behind the very practical and tangible benefits that have drawn vast numbers of businesses to use open source. As I’ve written previously, the four freedoms (to use, study, modify and distribute the software without restriction) have created a vast market by enabling cost-savings and flexibility. A business model that cultivates a casual disregard for those liberties while pretending otherwise deserves to be challenged — and it was.

Deployability as differentiation There are still plenty of those businesses around, many doing well. But the trend my previous article explored has steadily subsided as complex enterprise infrastructure has become easier and easier to obtain and deploy. The existence of substantial, mission-ready open source software has left fewer and fewer niches for software companies to differentiate on software alone. In an interesting, baseball-themed post, RedMonk analyst Stephen O’Grady says:

The technology industry is a lot like major league baseball circa 2000: it shares widely held, but fundamentally incorrect, ideas about valuation. Vendors and buyers alike, for example, behave as if software were a competitive advantage, when this is only rarely the case.

The result has been the rise of deployability as differentiation. Companies differentiate by the way they assemble the common open source components everyone uses and on the service they are consequently able to offer. For example, while theoretically anyone could build a cloud-based continuous integration service using Jenkins and a stack of open source software underneath it, CloudBees has been able to successfully trade on the know-how involved in deploying and scaling such a service.

In a world where the software itself is nondifferentiating, it becomes smarter and smarter for vendors to exploit a much-mentioned attribute of open source software: community. The rising trend of the moment is typified by projects from Eclipse to LibreOffice. Although they follow a path that was paved over a decade ago by the Apache Software Foundation, these projects combine the unblinking transparency that Apache brings with a focus on a particular software set, allowing more focused engagement with both developers and corporations. As Mike Milinkovic of Eclipse once said, “The Eclipse community is working on a single technology platform, so every Eclipse project can interoperate with the others at some level.”

Interestingly, neither of the two projects I’ve named use the Apache License for their code. Eclipse uses the Eclipse Public License and LibreOffice uses LGPLv3 — both weak copyleft licenses. Using a weak copyleft license has been optimal because, while it offers the freedom to use the software in combination with other software in any way that is interesting, the project itself remains a code base with an explicit requirement to work in-community and contribute. While for the most part that requirement needs no enforcement, its absence allows well-resourced and politically adept corporations to “game” open source, using both dominant contribution and behind-the-scenes agreements to ensure that the public project is effectively under their control. That sort of high-stakes politics is not desirable.

Peering into the future While the newest open source projects such as OpenStack and OpenShift have chosen to use the Apache License, a non-copyleft or “permissive” open source license with good patent protections, I believe in time we will see the licensing trend for new open source projects targeted at commercial collaboration swing back to the center, away from either the GPL or Apache extremities. Until recently, none of the mainstream “center ground” open source licenses has been optimal. These are the Mozilla Public License (MPL — and its many “vanity name” variants), the Eclipse license, the CDDL (used widely by projects influenced by Sun Microsystems), and of course, the LGPL.

Recently, a new approach has emerged. After a decade of use, the Mozilla Foundation recently updated the MPL to a new version, MPLv2. It delivers the same high degree of patent safety we’ve come to expect, is a file-based weak-copyleft license that avoids causing license relationship issues in combination with other software, and has been well-drafted to be readable and relatively short. Most important, it is explicitly compatible with the GPL, allowing MPLv2 projects to play nicely both with Apache- and GPL-licensed software. It occupies a sweet spot: permissive enough for corporations, copyleft enough for communities, and well-written to boot.

I believe we will see future collaborations use the new version 2 of the Mozilla Public License more and more. We may even see some projects already using weak-copyleft licenses migrate to it — indeed, the Document Foundation, home to LibreOffice, has been discussing the possibility of such a move for LibreOffice. As the timeline for commercial open source licensing progresses, I believe a trend back toward the center will arise, either to the MPLv2 itself or to an even better successor. That’s a positive and unifying direction, and I sincerely hope it happens.

This article, “What’s next after GPL and Apache?,” was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.