When Your Open Source Turns to the Dark Side

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 Elasticsearch is an example of an open-source project moving to a non-OSS license, i.e. one that’s not approved 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 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 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 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.