Closure: Is Open Source Licensing Suddenly Unsustainable?
We’ve put off the discussion for perhaps too long: To whom does open source software truly belong? Legally speaking, it’s the intellectual property of its original creator. Any rights the software development community may have to that software are granted by that creator, by way of the software’s license.
Does such a grant stop the creator from ever claiming an exclusive right to the idea behind the software? Perhaps more importantly, does it preclude that creator from exclusive ownership of the market that naturally forms around the use and exploitation of that software?
Similar questions, posed from the opposite side of the argument, are equally valid: Assuming the only way a startup software vendor can make headway in a new and untried market is through open source licensing, is the community of developers who build on that innovation equally entitled to the fruits of that innovation?
Can that same community effectively run away with that innovation and transplant it somewhere else, on a platform operated by someone else? And when it does so, does the creator have a legitimate, actionable grievance around losing its customers?
What brings these questions to the forefront now is the rift between Terraform’s contributing developers and its creator and vendor, HashiCorp. In August, HashiCorp announced it was switching its licensing model for Terraform and other products from the Mozilla Public License 2.0 — a very liberal, loosely worded, permissive license — to MariaDB’s stark, brief, insistent terms of Business Source License 1.1.
HashiCorp CEO Dave McJannet on stage at HashiConf 2023.
Business Source License
BUSL is short enough to be written on a napkin. Its first sentence is the one that counts: “The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work.” The key word there is non-production. It can and should be interpreted to mean this: You cannot commercially benefit from your contribution to our product, says the licensor, unless we say you can in writing, and only under our terms. (Both HashiCorp and database maker MariaDB declined comment for this article.)
Yet this move from HashiCorp — whose shares became publicly traded on the Nasdaq exchange in December 2021 — is certainly not the first shift away from open licensing terms, and probably far from the last. Recently we’ve seen:
- Red Hat’s move to restrict the availability of code for its RHEL to commercial customers only.
- MongoDB’s 2018 introduction of its Server Side Public License (SSPL), a “source-available” permit that stipulates anyone contributing to the code must make publicly available everything anyone would need to make that code operable.
- Redis’ move to restrict use of the code specifically for add-on modules for its in-memory cache and database, alleging in a since-altered web post (without directly referring to AWS ElastiCache) that “cloud providers” seek to profit from repackaged, proprietary managed services.
There’s a deeper issue here: Should the originator of a software product — even one licensed under very permissive terms — be granted or permitted exclusive rights to own and operate the market or ecosystem that forms around that product?
If so, it raises the question of whether an open source license can be leveraged, especially with managed services as its fulcrum, to do the very thing open source intended to avoid: enable vendor lock-in. But if not, developers may have the opportunity to build their own market around a product at any time. They could also reserve the right to do so as a bargaining tool.
Such leverage could be used to keep the licensor in line, in case it threatens to change its terms. It could also execute that option if the licensor should try to capitalize on the ecosystem that forms around any standards its software should create.
Recently we’ve also seen:
- SUSE’s move last July to fork the most recent publicly available RHEL code, to build a new distribution that, unlike recent builds of Red Hat’s CentOS, would be compatible with RHEL.
- Amazon Web Services’ 2021 move to produce a fork of Elasticsearch called OpenSearch, ostensibly in response to Elasticsearch imposing new terms AWS said would restrict its ability to offer search on its cloud platform, as a service.
- The repeated forking of Node.js by community members disgruntled by what they perceived as unsanctioned modifications to its licensing terms.
Perhaps the most prominent example of the rug being pulled out from under an emerging ecosystem took place in 2015. That’s when Google effectively transplanted the burgeoning container ecosystem from Docker to Kubernetes. It all took place so swiftly and neatly, and the resulting market transformation was so complete, that market analysts at the time couldn’t wrap their heads around what had happened.
If openness is relative, then benevolence has a limit. How much openness can an organization be expected to grant to the development community, without its assets becoming devalued in the eyes of investors? Without the ability to control who should profit from the use of a technology, what’s the point of having invented the thing in the first place?
Non-production
HashiCorp’s position on this subject was already crystal clear. In an October 2022 interview with The New Stack’s Alex Williams, HashiCorp CEO David McJannet said his company set up its Terraform Console — the interpreter for its Infrastructure as Code language — “to make our projects open source.
“But to be clear,” McJannet declared, “they are 100% controlled by HashiCorp.”
Were they? The immediate response from the broad community of Terraform developers was to break camp from HashiCorp, take the most recent open source-licensed Terraform, build a new platform around it, dub that platform OpenTofu, and donate it to the Linux Foundation. Perhaps more importantly, these developers are moving their Terraform-supporting products and projects with them to OpenTofu, effectively relocating a significant chunk of the Terraform ecosystem to a completely new platform.
“Companies that build their infrastructure deployments in Infrastructure as Code,” remarked Pawel Hytry, one of OpenTofu’s principal contributing developers, speaking with The New Stack, “work under the premise [that] it would stay open source. This means, with full confidence, they took years to build their infrastructure based on this framework.
“The premise was broken,” Hytry continued. “In my eyes, what that means for the broader ecosystem, is that if the premise is broken, there will always be an open source alternative.”
“I think that this could be a real turning point,” remarked Clark Asay, who holds the Hugh W. Colton professorship within the Brigham Young University law faculty.
“Obviously, the open source software movement has been significantly commercialized over the years… There have been pretty significant rumblings — negative dynamics developing between the volunteer communities surrounding particular projects, and the organizations that are leading them, that have acquired them, or that are directing them. These types of events could push software development in a completely different direction going forward, than what has been happening for the last two to three decades.”
Is This Legal?
Did HashiCorp actually break any laws by switching to a more restrictive license from an open source?
Since the founding of the United States, there has been legal precedent establishing that the creator of an idea or method has a right to claim exclusivity over how it’s used. But once such a method has been designated as in the public domain, no one may legally claim it as original.
As everyone knows, open source software is not in the public domain. Its originator retains the right to grant open availability through licensing. Technically, this should mean that the open source state of a piece of software can never be presumed perpetual. However, if its license is so worded that its assignee assumes its duration is unlimited, imposing new limitations after that fact may be considered a violation of the original license terms and assertions.
In other words, no law can guarantee the relative openness of how a work of software is distributed. But it may be illegal to violate the terms under which that software was originally made available. In the broad sense, when a vendor moves from a permissive license to a restrictive one that contradicts the terms of the permissive one, is that legal?
“It isn’t necessarily legal,” responded Richard Fontana, Red Hat’s senior commercial counsel, and the co-author of General Public License version 3. “It depends on the circumstances.”
A sole copyright holder on a work of software, none of whose components were licensed to it by others, has a variety of licensing options, Fontana explained.
Moving to a proprietary licensing model from an open source model is one option. But a typical open source license such as GPLv3 is perpetual and irrevocable. There may be limits to the conditions such a license may impose, but as Fontana noted, “There’s sort of a community-endorsed limit on what those conditions can be.
“As long as you abide by those conditions, your license is perpetual,” continued Fontana, speaking with The New Stack. “So a licensor of open source software cannot take away a license that they’ve granted. But, if they have the rights to do so, they could decide, for modifications going forward, or new changes or additions to the project or code base, to use a different license.”
Without referring to any specific situation or scenario, Fontana added, it’s entirely possible that a hypothetical licensor may be determined not to have the right to impose restrictions on licensing terms that had been open. One reason may be that the code base may have accumulated contributions from outside its own company or domain, that are themselves being licensed to the licensor.
“I think companies that take this sort of step tend to be careful about it,” said Fontana. “But I do see, in the community when these things happen, people do raise that question: Did they actually have the right to do this? Sometimes the questions are pretty serious.”
“Yes, it would be legal,” responded BYU’s Asay to the same question posed to Fontana, “but I’ll just add a couple of caveats.
“People have come together and collaborated for perhaps years, in some cases, dedicating significant time and resources to these projects, largely based on these norms and trust between members that everyone is, to some extent, on the same page,” Asay told The New Stack. “But strictly based on copyright law, as long as the organization is considered the author, joint author, or one of multiple authors of that copyrighted material, then they can license it under one set of very permissive terms, and then down the road choose very restrictive terms.”
Asay (whose brother Matt, incidentally, has been a New Stack contributor) paints a picture of a relationship between originator and contributor where the delineation between those roles may appear to blur over time, at least to outside observers and certain journalists, but usually not from the perspective of the law.
The initial breach that happens, when it does happen, between the originator and licensee, is one of trust.
However, in Asay’s view, it is not inconceivable that the dividing lines could blur enough for both parties to be considered de facto joint authors. There may be legal precedent for outside contributors to be judged or determined to have supplied a majority of the content for a body of work.
That precedent, like so much of what determines our fate these days, could come from outside our native sphere of influence: a 2000 decision by the US Ninth Circuit Court of Appeals in a suit filed by documentary film collaborator Jefri Aalmuhammed against its principal producer and director, Spike Lee [PDF]. Aalmuhammed argued he had become a de facto “co-author” of the film Malcolm X with Lee, by virtue of how much of its content he was directly responsible for making himself. As such, he contended he was entitled to a share of the film’s profits. (The Copyright Act of 1976 fails to define “author” explicitly, yet subsequent case law manages to boil down producership, directorship, and even editorship down to “authorship.”)
Pleasing perhaps no one at all, the Ninth Circuit’s decision established a three-point test for determining whether someone qualifies as the co-author of a work, in the absence of an explicit contract:
- The degree of control that person or entity exercises over the work as a whole;
- Some token of representation of all parties’ intent to work together jointly — some material reason for assuming trust exists; and,
- The lack of a formula for appraising just how much each party contributes to the work, which would otherwise determine someone not to be a co-author.
Prof. Asay suggests it may be an open question, on a case-by-case basis, whether developers acting jointly or individually constitute co-authors of open source software. A license is not a contract, so if it refrains from stating a developer is not a co-author, the question may yet be determined. And if the open source-licensed product did not sell for a price or generate revenue, then the question of how the parties split the proceeds may be moot.
In the end, the issue may boil down to who benefits the most from the software’s existence. Resolving that dilemma may require a decision one may rather not submit to today’s highest courts: Is the platform upon which the market for a work is predicated, part of the work itself? Put another way, does an ecosystem consume, and thus embody, the thing that gave rise to it?
“A Central, Shared Service”
“Terraform was built with an expectation that it is, and will remain, open source,” explained OpenTofu’s Pawel Hytry. “This was the premise: We have community, we’re all building this together. Naturally, the driver is HashiCorp, but you also have other contributors. And that meant companies that build their infrastructure deployments in Infrastructure as Code work under the premise that it would stay open source, which means that with full confidence, they took years to build and develop their infrastructure base on this framework.”
Hytry’s main line of work is as CEO of Spacelift, the maker of an Infrastructure as Code policy agent and management platform designed to work with Terraform, but also with Red Hat Ansible, Pulumi, and now OpenTofu, among others. HashiCorp put Terraform on the map at a time it was already well known for having produced cluster management platform Vagrant. But it’s arguable that Spacelift, and other products in a similar orbit, made Terraform visible and gave it legitimacy.
There was a time when HashiCorp might have made the same argument. A year and a half ago, in this very publication, HashiCorp was held up as the model for building a “nurtured community,” as contributor Emily Omier put it, as opposed to assembling a group with a more transactional relationship with the company.
Now, according to Hytry, the terms for an organization wishing to be an official provider of configuration modules to be included in HashiCorp’s Terraform Registry, must commit in advance to producing modules that are exclusive to Terraform. That’s a change of terms that may have come as a surprise to providers that already believed their relationships with HashiCorp were outlined by the Mozilla Public License.
“So we just built our own registry that is open,” Hytry continued. “It’s a bit of playing cat-and-mouse… None of the big cloud providers would ever agree that someone will dictate that their providers, their connectors, can be used to create a monopoly.”
The OpenTofu Registry of infrastructure definitions, or “providers,” currently appears on GitHub, although a message states GitHub is a temporary host. For now, it may be the provisional home of an ecosystem in transition.
If you weren’t familiar with the situation surrounding providers, the phrases McJannet used in his Day 1 keynote to HashiConf attendees on Oct. 10 could be interpreted entirely differently. There, he explained the role of what he continued to call “open source” in the commercial product lifecycle of Terraform. Behind him, a slide divided that lifecycle into three stages, the latter two of which represented the commercial part of the lifecycle.
When customers are first being signed on, he explained, there’s a roughly six-month period when they’re struggling to find their way, their platform teams are overwhelmed by the chaos, and their security models are up in the air. “It is during that period,” said McJannet, “that our open source products are used — probably more so than even the cloud native products, in many cases, because of the surface area of integration that’s been accomplished that’s helped standardize some of those core concepts.
“Then invariably, someone has to bring it under control,” he continued. “A core team is assigned to bring some order to it.” With order, he went on, comes a more consolidated, manageable, transactional working arrangement with customers. That core team, or platform team, is what the CEO described as the natural culmination of a company having adopted Terraform.
“This has always underpinned our product philosophy,” declared McJannet. “In case it wasn’t clear, our open source products have always been designed to solve that ‘V.1’ problem for the user, and our commercial products — because the Global 2000 asked us to do this a very, very long time ago — serve the needs of running those things as a central, shared service for the company.”
Is This Ethical?
“There are these different systems of ethics that I see coming into play, when we’re talking about open source software,” responded Red Hat’s Richard Fontana to this question. “At one level, if you have the right to change the license of a project from a very permissive open source license to something that is not open source — a more restrictive, non-open source license — on some level, you could say that’s baseline ethical. We have a legal system in place that enables certain kinds of behavior, and that’s within the rules.”
But in an open source context, Fontana asserted, it’s more complicated.
“Often I hear the phrase ‘bait-and-switch’ being used when some of these controversial license changes occur. And I think that gets at one possible ethical problem.”
Fontana sees an emerging pattern, which looks quite compatible with McJannet’s conference slide: Upstart companies assert a very permissive open source license — more so than GPLv3, more like MPL — up to the point where they’ve successfully built a development community. “If you hadn’t used an open source license to begin with,” he said, “you probably wouldn’t have been so successful in building that community around the project… if you had used a license with restrictions that would have made it not open source.”
Maybe it takes a few years for the vendor to build up community goodwill and positive expectations. Then, in a perfectly legal move, the vendor changes the license to a non-open source license. “I think there is an ethical question there,” said Fontana, “and I think it’s a difficult one. Part of the issue is, did you give the community enough notice? Did you give them an opportunity to provide feedback on the problem that you saw, that led you to want to make that license change? I do think there is a problem in spending a long period of time, building up expectations around a project being open source, and then switching to a different model.”
The argument could be asserted that McJannet gave such a notice — for instance, in his crystal-clear interview with Alex Williams. Can a clue deduced from an interview be interpreted as “notice?” Or must such a thing be in writing, on legal stationery? That’s the kind of legal question you’d expect a judge to resolve. Are we ready to start talking about judges?
“I think the open source community has largely operated on norms and trust,” remarked Clark Asay, “and accepted definitions and understandings. But once that trust starts breaking down, you do need a bit of an arbiter — someone or something to define the rules of the game. Previously, the game was played based on these norms. If those norms are going away, then you need something else to replace them. What’s going to replace them [could be] the defaults in copyright law and patent law — and some of those will be pretty undefined, because open source has not been terribly litigious over the years. Courts stepping into this realm, and grappling with all these facts, is potentially helpful in providing clear guidelines. That could go awry pretty quickly, too.”
“People want open source, and they want to have the freedom of open source,” said OpenTofu’s Hytry, “And they don’t want to be dependent on other parties. People, users, companies don’t like to be dependent on someone, especially if they broke the initial premise of their framework, or what they built. So open source, in the end, will win, no matter how big the company.”
