Many people see open source software as just a license. Whenever people tell me, I ask them what is preventing the project from changing the license, and who can make such a change.
Then I tell them stories of people using open source tools
In this article, I analyze three case studies from the past few years to illustrate the potential dangers. Then, I’ll wrap up my checklist for reviewing and judicious use of open source to keep your software and business secure.
Going Non-OSS: Elasticsearch Case Study
I remember That day, back in January 2021, when everyone was back from the New Year’s holiday, Elastic’s announcement hit us and the rest of the community: Elasticsearch’s project will be re-licensed from Apache2 to a non-open source license (SSPL and Elastic License ), also known as the “fauxpen” source license.
To make matters worse, the license expires in an upcoming minor release, which is only a few weeks away. Elastic NV explained that this is done to fend off competitors who exploit OSS without giving back.
Elasticsearch is a decade old text search database owned by Elastic NV with very high adoption rates for enterprise search and log analytics. Elasticsearch is a core component in many systems, as databases often do, so you can imagine what a change like this would inspire in the community.
Going Copyleft: Grafana Case Study
Elasticsearch is an example of a Open source projects move to non-OSS licenses, i.e. projects not approved by the Open Source Initiative (OSI). But as we said, OSS is more than an open source license. Things can happen even within the realm of OSI licensing. For example, open source can turn to copyleft.
Grafana is a very popular open source tool for metrics dashboards and monitoring. Grafana Labs is the vendor behind the Grafana project, which is licensed under the Apache2 license. Then there are announcements.
In April 2021, Grafana Labs announced the re-licensing of Grafana from Apache2 to GNU AGPLv3. Grafana Labs believes that relicensing requires balancing open source with their monetization strategy.
AGPLv3 is an OSI approved open source license, so all is well, right? not quite. One day people found that the OSS tool they were using suddenly became a contagious OSS . Without going too deep into legal issues (I’m not a lawyer), using the modified AGPLv3 software requires that anything it links to must also be licensed under the same license, which means it can spread like a virus like copyleft licenses do.
This has made many companies and even open source organizations ban the use of AGPLv3 software in their stacks. As Google puts it, “The risks far outweigh the benefits.”
Going Rogue: Colors & Faker Case Study
We have seen that there can be problems with vendors that have open source. But the problem may not be just with suppliers. Most projects on GitHub are actually maintained by individuals, usually just one or two maintainers who are not paid for their passion. Even these enthusiastic people can have problems.
Colors and Faker are two very popular JavaScript development packages, downloaded millions of times a week from npm. They use the very permissive MIT OSS license and are maintained solely by dedicated people called Marak Squires. Then he decided to pull the plug.
On January 5, 2022, Marak removed Faker’s source code and published the empty package to npm. Then on January 8th, Marak released a new version of Colors with a deliberately malicious infinite loop that effectively caused a denial of service to any application that used it. The rogue version broke many tools, including Amazon’s AWS Cloud Development Kit (aws-cdk). Marak explained his actions in his post “Monetizing open source is problematic.”
Checklist for judicious use and review of open source
If you are using open source tools, or are reviewing a new tool or framework, here is a helpful checklist:
- Which open source license does it use? Don’t confuse the “source-available” (ie fauxpen source) license with the “open source” license (approved by OSI). Even within the realm of OSI, not all OSS licenses are created equal.
- Who is behind open source? A one-man show means a single point of failure. If you choose vendor-owned open source, be aware that this can be problematic. Basic open source is the most reliable (though not bulletproof) option.
- Manage your 3rd party license exposure just like you manage 3rd party security risks. Prefer the least restrictive license and look for license pollution (such as the AGPL license used in the Apache2 codebase).
- Include license compliance checks in your automation. Beware of automatically updating third-party tools and libraries in your CI/CD pipeline without safeguards.
What is the governance policy? This includes things like how to ensure that no single entity has control, what is the progression path for contributors/maintainers, who can review/approve PRs and similar.
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 caveats and to help you use open source wisely.
