Software Integrity

 

Are SaaS companies immune to open source risk?

Are SaaS companies immune to open source risk?

The brief answer to the question in of whether SaaS companies are immune to open source risk is “no.” While there’s a grain of truth with respect to the use of the GPL licensed components, SaaS companies are not immune to legal risks. And there are other elements of open source risk to which SaaS companies are actually more exposed than non-SaaS vendors.

Risk #1 – Legal risk for SaaS companies

The GPL licenses are the most common open source licenses and generally the most problematic for companies developing software. SaaS companies are more free to use GPL licensed-code because the obligations of the GPL are triggered upon software distribution and SaaS software by nature is not distributed.

However, SaaS companies still need to be concerned about software licensing. First, there are a number of licenses, most notably the AGPL, that are (according to the AGPL preamble) “specifically designed to ensure cooperation with the community in the case of network server software.” In essence, the obligation to make source code available is triggered not just by distribution but also by allowing use over a network. These licenses are much less common than the GPL, but are still out there and are designed to plug what has been considered a loophole in the GPL.

The other “license type” that SaaS companies should watch out for is no license. In the vast majority of audits we perform we find code that has been appropriated from the Internet, but with no clear license. The default of copyright law is that if it’s not your software and you don’t have permission (i.e. a license) you don’t have the right to use it. Therefore, there is risk in doing so.

Lastly, most companies with SaaS offerings also distribute software. A very common architecture these days is a mobile client front end with hosted back end. The client software is distributed and therefore beholden to GPL obligations. More subtly, many SaaS applications use client-side JavaScript code—if you see any kind of animation or slick graphic interaction in your browser, it’s probably JavaScript. It’s not apparent to the user, but the slick graphics are enabled by the code being downloaded to and actually executed on your computer. Most lawyers consider that distribution. Most companies that host applications need also to pay attention to the GPL for those parts of their software that they distribute.

Risks #2 and #3 – Security and operational risks

If SaaS companies are less concerned about legal risk, the Internet accessibility of their offerings makes them more concerned about security. Open source components overall are no less secure than other forms of software, but last year over 4,000 new vulnerabilities in open source were publically reported. And the Open Web Applications Security Project (OWASP) counts “Using Components with Known Vulnerabilities” in its top 10 list of risks. Many companies are using open source components with known security problems.

Security is related to the operational risk of getting behind on versions. Using old versions of components exposes an organization to known vulnerability problems. The good news with open source is that once a vulnerability is identified in an active open source project, “antibodies” in the community usually swarm in and quickly patch it. However, if you are not tracking what components your developers are using, it’s nearly impossible to keep up with the latest version. Apple and Microsoft remind me weekly that I should be installing security patches on my laptop, but there’s no entity to provide such a reminder for most open source components.

So, there are risks even with “active” open source projects. There are worse risks in using components that don’t have an active community around them, maybe started by two guys in a garage who have since lost interest. A seasoned technical advisor to acquirers recently told me, “The biggest problems I see are with ‘dead code.’” He meant components with no active community, the users of which are essentially on their own to find and fix problems.

Risk #4 – Strategic risk

If you build an application to be accessed only as SaaS, don’t plan to distribute it. I once managed a product portfolio that included a SaaS service. Two large overseas telcos approached me interested in hosting the software themselves and willing to pay big bucks for it. My excitement was quickly deflated when the savvy engineering manager who built the product schooled me on the GPL license and how dependent our architecture was on GPL-licensed code. No big bucks, rather a big bummer.

Ventures that might be looking for an M&A exit in the future should consider how dependent they want their applications to be on GPL. You might have a vibrant SaaS business, but potential buyers may be interested in also offering an on-premises version. (IBM, for example, seems to look for this routinely.) The more dependent your offering is on GPL-licensed code, the harder it will be to make it distributable. There may be good reason to use GPL components, but do so consciously and be aware of the strategic limitations.

On net, using open source is a huge positive and, as Mark Driver at Gartner once said, not using open source puts a company at a “competitive disadvantage.” It is the case that with respect to legal risk, SaaS companies have a bit more latitude. However, SaaS companies are far from “immune” and certainly need to manage the range of risks that may come with using open source for those who do not know their code.

2018 Open Source Security and Risk Analysis report shows vulnerability and license risk continues to grow. Read the report.

 

More by this author