Many people treat open-source software as merely a license. Whenever people tell me that, I ask them what prevents the project from changing license, and who can pull off such a change.
And then I tell them stories of people using open-source tools that turned to the dark side.
In this article, I analyze three case studies from the past couple of years to illustrate the potential hazards. Then, I’ll conclude with my checklist for vetting and using open source wisely to keep your software and business safe.
Going Non-OSS: Elasticsearch Case Study
I still remember that day, back in January 2021, as everyone was getting back from the new year vacations, when Elastic’s announcement hit us and the rest of the community: Elasticsearch’s project was to be relicensed from Apache2 to a non-open-source license (SSPL and Elastic License), also known as a “fauxpen” source license.
What’s worse, the licensing was due in the upcoming minor release, which was just a few weeks away. Elastic NV explained it did that to fend off competitors leveraging the OSS without contributing back.
Elasticsearch is a decade-old text-search database owned by Elastic NV with very high adoption for enterprise search and for log analytics. Elasticsearch is a core component in many systems, as databases often do, so you can imagine what such a change stirred up in the community.
Going Copyleft: Grafana Case Study
Elasticsearch is an example of an open-source project moving to a non-OSS license, i.e. one that’s not approved by the Open Source Initiative (OSI). But as we said, OSS isn’t just about open-source licensing. Things can happen even within the OSI licensing realm. For example, open source can turn copyleft.
Grafana is a very popular open-source tool for metrics dashboarding and monitoring. Grafana Labs is the vendor backing Grafana project, which was Apache2 licensed. And then came the announcement.
In April 2021, Grafana Labs announced that it was relicensing Grafana from Apache2 to GNU AGPLv3. Grafana Labs reasoned the relicensing with the need to balance open source with their monetization strategy.
AGPLv3 is an OSI-approved open-source license, so all’s well right? Not exactly. People discovered one day that the OSS tool they used was suddenly an infectious OSS. Without going too deep into legal talk (I’m not a lawyer), using AGPLv3 software with modifications requires that anything it links to must also be licensed under that same license, which means it spreads virally, as copyleft licenses do.
This got many companies and even open-source organizations to ban use of AGPLv3 software in their stack. As Google puts it, “the risks heavily overweigh the benefits.”
Going Rogue: Colors & Faker Case Study
We’ve seen that vendors owning an open source can be problematic. But issues can arise not just with vendors. The majority of projects on GitHub are in fact maintained by individuals, oftentimes only one or two maintainers, who do that out of their own passion without getting paid. And issues can occur even with these passionate individuals.
Colors and Faker are two very popular packages for JavaScript development, with millions of downloads a week from npm. They use the very permissive MIT OSS license and are single handedly maintained by a dedicated individual named Marak Squires. And then he decided to pull the plug.
On January 5th, 2022, Marak deleted the source code of Faker and published the empty package to npm. Then on January 8th Marak published a new version of Colors with an intentionally malicious infinite loop that effectively created Denial of Service to any application using it. The rogue releases broke many tools, including Amazon’s AWS Cloud Development Kit (aws-cdk). Marak explained his action in his post “monetizing open source is problematic.”
Checklist for Using and Vetting Open Source Wisely
If you’re using an open-source tool, or are in the process of vetting a new tool or framework, here’s a useful checklist:
- Which open-source license does it use? Don’t confuse “source-available” (i.e. fauxpen source) licenses with “open source” ones (as approved by the OSI). And even within the OSI realm, not all OSS licenses are born equal.
- Who’s behind the open source? A one-man show means a single point of failure. If you choose a vendor-owned open source, be aware that could become problematic. Foundational open source is the most solid (though not bulletproof) option.
- What is the governance policy? This includes things such as how it ensures no single entity grabs control, what’s the promotion path for contributors/maintainers, who can review/approve PRs and similar aspects.
- Manage your third-party licensing exposure, just like you manage your third-party security exposure. Prefer least restrictive licenses and look for license contamination (such as AGPL license used inside Apache2 codebase).
- Include license compliance checks in your automation. Beware of auto-updating third party tools and libraries in your CI/CD pipeline without safeguards.
Open source is great. Use it! The purpose of the above case studies is not to intimidate you, but to make you aware of the considerations, and to help you use open source wisely.