Even though open source software is firmly in the mainstream, used widely by businesses, governments, and everyone who owns a cell phone or computer, the question repeatedly arises: “Is open source software safe?” Broadly speaking, the answer is a resounding yes. But it’s worth examining what we mean by “safe,” contrasting open source software with proprietary software, and discussing when you should use caution.
Defining “safe” for software
Let’s start by defining what we mean by “safe” because it’s a non-specific term that might mean different things to different people.
Safe, here, encompasses security, stability, sustainability, and compliance.
Specifically, does open source software meet a reasonable security expectation comparable to or better than proprietary software? Is open source software as stable as other software? Is it sustainable, that is – will the software continue to be developed and maintained long-term, predictably, so you can depend on it? And, finally, does open source software carry any risks around legal compliance?
Finally, let’s clarify what we’re discussing with the phrase “open source software.” Anybody can slap an open source license on some software and put it online. Our bar is higher than that. We’re not addressing hobby projects or those that don’t have an active community.
When discussing open source software, we’re talking about ongoing projects with a healthy community and substantial adoption. We will talk about how to assess that when choosing a project.
Let’s start with the big one, security.
Is open source software secure?
When a project’s source code is available to all, the question of security isn’t far behind. How can something be secure if anyone can examine the code and look for security flaws?
Would-be attackers can comb through source code to find security flaws. Sometimes they do! But it also allows “white hat” types to examine open source projects to try to find and fix vulnerabilities before attackers find them and use them. It allows organizations to identify potential vulnerabilities, report them, and apply fixes without depending on a single vendor.
The relative security of open source software has been examined repeatedly by researchers since the early 2000s. Open source software contains no more flaws on average than proprietary software. In some cases, it may have fewer vulnerabilities.
Security through obscurity – expecting software to be more secure if attackers can’t see the source code – doesn’t work. Attackers find and exploit vulnerabilities in proprietary software all the time. The Log4Shell vulnerability in Apache Log4j’s software made big headlines in 2021, but it wasn’t alone. Consider ProxyShell – a set of vulnerabilities in Microsoft Exchange that could result in Remote Code Execution (RCE).
That’s just one example. You can peruse Microsoft’s acknowledgments of security reports for a long list of vulnerabilities discovered by various researchers who found vulnerabilities in its software without access to source code.
So, is open source software secure? In absolute terms, no software should be considered free of vulnerabilities. But, in relative terms, we’d say yes. Open source software is secure relative to proprietary software – and in some instances, we’d say more secure than proprietary software.
In all instances, open source software allows anyone to examine the software and attempt to provide fixes if they discover a vulnerability. Open source software does not depend on a single vendor that controls the software entirely.
Is open source software stable?
Users may also wonder if open source software is stable, whether it’s safe to use open source software in production environments, and that sort of thing.
Again, the answer is yes, but with a few caveats worth calling out. Let’s start with some prime examples of open source software being used where stability is crucial.
Open source software powers the Internet. Linux, for example, is the most widely used operating system to run services you use daily. All the major cloud providers use Linux, your cell phone company is likely using Linux to deliver phone calls, it’s used by streaming services, social media companies, and so forth. If you’re an Android user, it’s in your phone.
That’s just the most obvious example. Open source databases, like MySQL and PostgreSQL, are among the most widely used and popular databases for workloads large and small.
There’s also WordPress and Drupal, content management systems (CMSes) that power millions of websites worldwide. (WordPress, in fact, powers this blog and uses a MySQL database to store its content.)
On the smaller side, you have tools like curl and SQLite embedded in millions of devices for various uses. Open source has even gone to Mars.
Caveats of open source software
One could write a book on the successful use of open source and how well it stacks up, stability-wise, next to proprietary software. What are the caveats?
You need to evaluate open source software the same way you’d evaluate any software. Look at how it’s produced, and the health of its community or vendor, and put it to the test in a proof-of-concept (POC) or otherwise evaluate it to verify it suits your needs.
The health of the community is a broad topic, I won’t try to explore it here fully. But, in short, check out the history of the project. See how many contributors it has, whether it has vendors who support it if you need support, and make sure it’s still being maintained.
If you examine Linux, MySQL, PostgreSQL, Kubernetes, WordPress, Apache Kafka, and thousands of other projects, you’ll find projects with long histories, widespread adoption, and vendors who will provide support above and beyond just supplying the software.
That brings us to sustainability.
Is open source software sustainable?
Sustainable is a phrase used a lot to describe environmentally friendly concerns. But when we say “sustainable” here, we’re talking about whether the development process that produces the software is sustainable. To put it another way: Can we depend on that software to be here tomorrow, next month, or next year? Even longer?
This question isn’t unique to open source software! The same forces that cause software companies to go out of business or cancel projects can impact open source.
Proprietary software goes away all the time, particularly in the age of Software-as-a-Service. Consider all the projects in Google’s graveyard, like Google Reader, Stadia, G+, and too many messaging apps to even try to recount.
Maintainers aren’t suppliers
However, open source has an added wrinkle, and we want to discuss it head-on. Open source projects are often powered by maintainers who aren’t paid directly to work on those projects.
Maintainers are not the same thing as suppliers and vendors. An open source project is not necessarily the same thing as a product.
For example, many of the Apache Software Foundation (ASF) projects have contributors from many different companies. Some may be paid to work on the project full time, and others may contribute as part of their day job where the software is used in their work, but they have other responsibilities.
So if you evaluate an open source project to use in your business, you need to do some due diligence about the project’s health to verify that it has the longevity you want. Again, this is similar to doing due diligence on a software vendor.
How to evaluate open source projects
You can feel confident that Microsoft will be around in 10 years and still support Windows and SQL Server. Likewise, Linux and PostgreSQL will almost certainly be around in 10 years. Apple is unlikely to go out of business and drop iOS anytime soon. WordPress has been chugging along for years and years and powers a huge chunk of the Internet, and it’ll still be used for blogs well into the future.
Open source data management software survey
On the other hand, you can look at a lot of proprietary software that has hit end of life when its vendor was acquired or management changed. Microsoft killed off VisualBasic while it was still popular, for example. Twitter snapped up Vine and then shuttered. Adobe has (largely) retired Flash, though you’ll find few people to mourn Flash and quite a few who were happy to see it go.
Open source software can reach its end of life too. The ASF, for example, has its “Attic” – a process and home for ASF projects that have become obsolete or failed to maintain a large enough community of maintainers.
How can you know if an open source project will be around for the long haul and receive updates?
A good rule of thumb? Look for widely adopted open source software with a good track record, and it’s even better if multiple vendors work on and support the software.
If it can be picked up and developed by multiple vendors, it’s a much safer bet. MySQL and PostgreSQL, for example, are great examples of projects with product equivalents with support options equivalent to proprietary software without the downsides of being proprietary.
What about open source software compliance?
Finally, the question on many people’s minds is whether open source software is safe from a compliance perspective. That is, does open source software introduce any legal requirements?
I’m not a lawyer, nor do I play one on TV, so this isn’t to be confused with legal advice. If you need a genuine legal opinion, you’ll definitely want to consult a lawyer – the same as if you wanted legal advice on an End User License Agreement (EULA) with proprietary software.
That said – licenses that meet the Open Source Definition (OSD) from the Open Source Initiative (OSI) have conditions triggered on distribution rather than use. If you install and run the software but don’t distribute it, then you don’t have any requirements to meet. Distribution is when you need to verify compliance.
What is open source distribution?
What is distribution? If your organization conveys software to other entities, that generally counts as distribution. For example, if your organization makes an electronic device with embedded software under open source licenses and sells them to customers, that’s distribution. Depending on the license, you may need to include a notice about the software, or you may need to make the source code available to customers on request.
At least one open source license, the Affero GNU Public License (AGPL), extends the distribution concept to include interaction over a network. So, if you’re using AGPL’ed software in a SaaS offering, that may require you to distribute the source code or provide a mechanism for distributing the source code to users of that SaaS.
So, if your organization ships software under open source licenses, then you need to have a plan to comply with the license requirements. If you simply use open source software, maybe you have a bunch of servers running Linux and an open source database like MySQL, but don’t distribute the software? Then you don’t have any special requirements to worry about.
The most popular open source licenses
The OSI has approved quite a few licenses as OSD-compliant, but in practice, you’ll see only a handful of them in use. Most open source software uses one of four or five permissive licenses (Apache 2.0, MIT, BSD 2, or BSD 3 being most likely) or one of the reciprocal GPL variants.
These licenses are well-understood. You can find ample guidance on working with them.
The Ultimate Guide to Open Source Databases
EULAs, on the other hand, are non-standard and ever-changing. If you use Apple software, for instance, you’re probably familiar with having to agree to EULA changes every time you update your software. If you use proprietary enterprise software, it probably has restrictions and compliance requirements to keep track of as you deploy it.
The good news about EULAs is that you don’t have to worry about modification or distribution – because you’re not allowed to do that, you don’t need to ask what to do if you make a modification and want to distribute it. Problem solved!
So… is it safe?
The real answer is, of course, the disappointing but realistic “it depends.” Open source software is not inherently unsafe or less safe than proprietary software.
Percona Database Software Solutions
