Open source license issues stymie enterprise contributions

Business licenses look to protect open core firms

In late 2018 and early 2019, awareness began to grow about the risks of relying on open core software vendors, whose revenue depended on value-add features and enterprise-level support for otherwise freely available software products. Red Hat built a business worth billions on that model, but in the decades since it was founded in 1993, open source software became ubiquitous among enterprises.

Enterprise developers gained the skills to modify and support it themselves and major cloud providers began to offer their own highly successful versions of the same core code. And where Red Hat had success, other businesses built around open source components, such as Docker Inc., struggled to create long-term revenue streams, in part because their core product was free and they faced opposition from partners in some of their attempts to create proprietary value.

Concerns about open core business longevity, especially as major cloud providers such as AWS launched their own versions of open source products such as Elasticsearch without cutting in their original creators, prompted vendors such as MariaDB Corp., MongoDB and Redis Labs to adopt new versions of open source licenses in 2018 and 2019. These licenses were known by multiple names -- business source license from MariaDB, SSPL from Mongo, and source available license from Redis, but all sought to protect these companies' open source IP from poaching by potential competitors.

MongoDB's SSPL was submitted to the Open Source Initiative (OSI), a nonprofit group that maintains the widely referenced Open Source Definition (OSD), in October 2018, under the OSI's license-review process. Had it been formally considered by OSI, SSPL might have challenged the nature of the OSD itself, but MongoDB withdrew the submission in early 2019.

"I understand what happened; the companies that said, 'We provide tools that allow other companies to make billions of dollars and we don't get anything' -- I am sympathetic to their position," said Italo Vignoli, affiliate member of the OSI board of directors and PR director for the LibreOffice project in Italy. "But I don't think that it is by changing the open source license that you solve the issue."

Kevin Fleming

Bloomberg's Fleming also understands the reasons behind these open source license changes, but said they still prevent his company's developers from contributing to projects that adopt them, often to the frustration of developers who had previously contributed.

"We don't give away our IP to commercial entities -- we only give it away to open source projects, that are then going to turn around and freely share it with the rest of the world," he said. "You're not going to go to Oracle and say, 'Hey, can you give us the source code for the Oracle database, we want to spend an extra two months adding a new feature and then give it to you for free?'"

While these open source license changes have caused upheaval in the last year to 18 months, some open source experts believe that their popularity is fading and may eventually disappear.

"Yugabyte, Vitess and other newer distributed database startups, they've all gone fully open," said Chris Aniszczyk, COO & CTO at the Cloud Native Computing Foundation (CNCF), which incubates the Vitess project. "Competitors [to MongoDB, MariaDB and Redis] are actually going more permissive, and over time, they may have to change their [business source] strategy."

Ethical source challenges open source definition

Most of the furor over open core business licenses has died down in the last six months, but debate still rages about the ethics of technology and whether the open source community can codify and enforce ethical consensus through licenses.

Introduced in 2019, the Hippocratic License is an attempt to do both those things. Named after the Hippocratic Oath taken by medical professionals that states, "First, do no harm," software projects licensed under Hippocratic language specifically prohibit any use that violates the United Nations' Universal Declaration of Human Rights.

Ehmke, the Hippocratic License's author, also seeks to have it approved by OSI, and came in fifth in the OSI Board of Directors election in March with 82 votes. Only the top two vote-getters were elected, but Ehmke said she intends to continue the fight to get the Hippocratic License approved under the OSD.

Ehmke argued that the restrictions in the Hippocratic License do not violate the OSD's prohibition on discrimination against any group or field of endeavor, since they apply to specific activities, rather than groups of people or fields of work.

"Human rights abuses are not 'a field of endeavor,'" she said. "If elected I would have worked very hard to update the OSD, which was created in 1998 -- it's a very different world now."

Bloomberg's Fleming watched the OSI Board elections with keen interest, concerned that the election of candidates such as Ehmke would signal that the OSI community was willing to consider formally adding ethical source language to the OSD.

"None of us are saying that we want to violate anyone's human rights or that any of our customers want to violate human rights," Fleming said. "But if we were to build into the license agreement for software that we sell to banks something that said, 'By the way, you have to agree that you will never do anything that the U.N. would classify as a human rights violation,' they would never use our software -- legally, they can't take that risk."

Ehmke sees nothing wrong with that.

"I don't want my software used by a bank that is scared of making that guarantee, and I really wonder why he would want to do business with them," she countered.

Tobie Langel

The winning candidates in the individual OSI Board elections, Megan Byrd-Sanicki of Google and Josh Simmons of Salesforce, whose publicly posted platforms included no mention of the Hippocratic License, declined to comment for this story. Tobie Langel, principal at UnlockOpen, an independent open source strategy consulting firm in Geneva, was also a candidate this year. He was not elected this round, but said he intends to keep advocating for ethical source within the open source community.

"Open source, from its origins, is a movement that is essentially built around ethical notions," he said. "The idea is to allow people to have agency and power over the software that they use to accomplish the tasks that they want to do."

However, OSI affiliate board seat winner Vignoli said he does not believe that such licenses fit the OSD.

Open source, from its origins, is a movement that is essentially built around ethical notions. The idea is to allow people to have agency and power over the software that they use to accomplish the tasks that they want to do.

"It's not software that is going to stop people with bad intentions," he said. "In some cases, they think they're ethical, and in others, they don't give a damn about not being ethical, so they would use the software anyway."

This is where, Ehmke argued, the creator of the software would make that determination and be empowered to stop a bad actor through the Hippocratic License. But Bloomberg's Fleming worries that the activities prohibited by the license are too broad and subjective to be consistently enforced.

"We just can't agree to those terms," he said. "No one knows what they actually mean, and they're not something that a court could even decide -- it would be on a case-by-case basis."

For Bloomberg, a project's switch to a Hippocratic license, as version 5.1 of a popular Ruby gem called VCR did last year, does little to advance technology ethics, and only creates disruption for developers.

"I immediately had to reach out to all of our teams that I could think of that might use [VCR] and say, 'When you run your builds, if you request a version of VCR that is version 5.1 or higher, it's going to be denied," Fleming said.

Beyond open source licenses: Copyright agreements

Even standard open source licenses often come with various types of copyright stipulations that can also stymie enterprise contributions, depending on how they are worded.

The world of contributor license agreements (CLAs) is an alphabet soup of acronyms, including the individual contributor license agreement (ICLA), corporate contributor license agreement (CCLA), the Software Grant Agreement (SGA) and developer certificate of origin (DCO). All certify in different ways that a contributor to an open source project has the legal right to donate their code, and that the code will not be subject to copyright dispute later.

Even experienced legal departments can experience confusion when dealing with the different forms of CLAs used by the various open source software foundations, as well as the governance rules that determine when and how they are used.

Roman Shaposhnik

For Walmart Labs, this confusion surfaced during a discussion on an Apache Software Foundation (ASF) mailing list in April 2019. The company took over code repositories associated with Takari, an Apache Maven plugin now being integrated into the main Maven project. At the time, Walmart Labs counsel said she was confused about why the foundation had asked her company to sign a separate SGA for the code.

"Since the two Takari projects are already open sourced under the Apache 2.0 license, ASF in theory already has all the legal rights it needs to the code," Walmart senior associate counsel Sue Xia wrote on the mailing list thread. "I do not understand why this additional Grant is needed." Xia did not respond to requests for comment on the matter this spring, and ASF officials declined to comment on the specific case. But generally, according to Roman Shaposhnik, vice president of legal affairs at ASF, SGAs are used when a large body of code is being donated to the foundation. "This is the Foundation's policy," he added. "It has nothing to do with the Apache Software License."

Other open source foundations, such as The Linux Foundation, may accept code under an Apache Software License with different governance requirements, according to Shaposhnik.

Further muddying the waters for would-be enterprise contributors is a broader ongoing debate about the merits of CLAs that stretches back years in the open source community. Some companies, such as Red Hat, take a strong stance against their use.

[SGAs and CLAs] impose friction in the contribution process that probably is not necessary from a legal risk perspective.

"[SGAs and CLAs] impose friction in the contribution process that probably is not necessary from a legal risk perspective, because the risk is really very, very low in all of this," said Richard Fontana, senior commercial counsel at IBM's Red Hat.

Elsewhere, Fontana has argued specifically against the use of CLAs, instead favoring DCOs to address copyright concerns.

ASF's Shaposhnik agreed there has been little litigation to date on open source licensing and copyright issues, but that does not eliminate potential future risks. Asking for CCLAs on top of ICLAs is a "belt and suspenders approach" from a legal standpoint, Shaposhnik acknowledged.  But the ASF still views its various copyright agreements as necessary to mitigate potential risks, legal and otherwise, when it accepts code donations from commercial entities.  

"If we see just a few contributions here and there, just a few trickles, there's not much to negotiate. If we see a flood of contributions ... that would be a pretty significant body of code to keep hostage if it turns out maybe the individual didn't have the right to contribute it," he said. "We want that initial guarantee that we will not be wasting our time and the time of our communities working on a project, only to have the corporation come back like, 'Yeah, you know what, we've decided not to open source [it]."

Enterprises must align legal and IT, but with few precedents

Ultimately, IT pros contributing code to open source projects must defer to the legal expertise of their corporate counsel. But enterprise legal departments are still working with few legal precedents and past case law regarding open source licenses and copyrights.

One high-profile software copyright case now waiting to be heard in the U.S. Supreme Court is "Google LLC v. Oracle America Inc. ," but that concerns the copyrightability of APIs, rather than anything to do with open source licenses. Previously, a federal appeals court ruled in favor of Oracle that its Java Enterprise Edition API is protectable by copyright, but that decision could be overturned by the Supreme Court when it hears the case this fall.

While many in the open source community are following the case and considering its possible ramifications for their projects, it won't be enough to establish precedent on its own, according to Red Hat's Fontana.

"It's clear to lawmakers and the people involved in the legal system that copyrightability of APIs is actually a bad result for the industry, but as far as I can tell, they're continuing with the assumption that we've had for many years that APIs are, from a copyright perspective, in the public domain," he said.

Meanwhile, the paucity of legal references contributes to the friction enterprises encounter as they become open source contributors. For now, corporate legal departments must draw on open source community consensus instead. Various open source foundations, including The Linux Foundation and Free Software Foundation Europe, look to foster such discussions among corporate legal professionals exploring open source licenses. But these won't take the place of court rulings in the long run.

"They say you have to tolerate uncertainty if you're going to be a lawyer, but I think a lot of lawyers, especially coming from more conservative industries, have trouble with that," Fontana said. "And they will probably welcome additional guidance from the court system on open source licensing."