After a few inquiries about this topic, I thought I would share some suggestions for best practices for SaaS vendors. Open source compliance for SaaS vendors is not difficult, but there are a few important nuances to keep in mind.
As a baseline, SaaS is not a high-risk business model for open source compliance. That is because most open source licenses do not have any conditions for SaaS server-side use. Generally, running software that powers a SaaS offering is not distribution, and most compliance conditions in open source licenses are triggered by distribution. (For more on that topic, see here.)
But that doesn’t mean SaaS vendors can simply abdicate responsibility for open source compliance processes. Here are a few reasons why SaaS vendors need to pay attention to open source compliance.
Client Side Software
While most software in a SaaS platform runs on the vendor’s servers, some software always runs on the user’s computer. This is sometimes called “client-side” software, because it runs on the client computer (the user’s computer) instead of the server computer. This software is pushed out to the client computer by the server, but it actually executes locally.
The best way to understand this is to look at the software. If you are using the Chrome Browser, for example, you can press Control-U or right click and chose “view page source.” There, you will see a lot of software code. Right now, as I am writing this in WordPress, the code for this authoring page is about 3,000 lines. But most of the software enabling me to write my blog is running on the WordPress.com server.
Client side code is particularly helpful for tasks like validating an entry in a form (such as a date or address) or executing simple logic on a web page (such as asking for more data if the user gives certain answers to questions). These small tasks need not ping the server and slow down processing.
One interesting thing about this client code is that it is almost always “high level” code or “scripting language” code delivered in source code format. Mostly, it consists of HTML (the scripting language for web pages), Javascript (a procedural language particularly useful for web pages) and CSS (a formatting language for web pages).
The great thing about scripting code is that it is already in source code form, so even if it is provided under a copyleft license like LGPL,(1) there is usually no need to offer additional source code.
The hidden issue, however, is that programmers usually strip licensing notices out of HTML/CSS/Javascript before sending it to the client device. That is done so the page will load faster.
So, the challenge is how to deliver notices for that code. Keep in mind that whenever you distribute software under a copyleft license like LGPL, you must not only make source code available, but you must also deliver a copy of the license. So the question is: where do you put those notices? That can be a head scratcher. One approach is to include, on the dashboard for your SaaS system, a page with the notices and links to the licenses.
But is that compliant? Clearly, most open source licenses were not written for client code. So it can be unclear where to place the notices in order to comply with the license terms. In fact, most open source notice provisions were written long before the advent of the web, and they assume that notices will be delivered in an installation folder — which only works for software in standard computing environments like Linux or Windows.
For example, the license notice requirement for LGPL 2.1 says you must “distribute a copy of this License along with the Library” and MIT requires that “this permission notice shall be included in all copies or substantial portions of the Software.” So, it seems at least plausible that notices on a separate web page are sufficient, but every license has its own language to describe where notices must be delivered.
One more nuance here: Programmers also often modify client side code in production environments to strip out “white space.” So, for example:
| <script id=’wp-media-utils-js-translations’> | |
| ( function( domain, translations ) { | |
| var localeData = translations.locale_data[ domain ] || translations.locale_data.messages; | |
| localeData[“”].domain = domain; | |
| wp.i18n.setLocaleData( localeData, domain ); | |
| } )( “default”, { “locale_data”: { “messages”: { “”: {} } } } ); | |
| </script> |
Would become the far less readable:
<scriptid=’wp-media-utils-js-translations’>(function(domain,translations){varlocaleData=translations.locale_data[domain]||translations.locale_data.messages;localeData[“”].domain=domain;wp.i18n.setLocaleData(localeData,domain);})(“default”,{“locale_data”:{“messages”:{“”:{}}}});</script>
But when you right click and view the code, or when you view it in nearly any development tool, the tool automatically inserts white space for readability. So this is generally not considered a compliance problem. The user has perfectly feasible access to the software in the “the preferred form of the work for making modifications,” which is what LGPL requires. (See definition of Source Code here.)
Network Copyleft and Similar Licenses
Another potential issue for open source compliance in SaaS is network copyleft licenses. A handful of licenses still have compliance conditions in the absence of distribution. This issue applies to server-side code. The most common of these licenses is AGPL, which says:
“13. Remote Network Interaction…if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.”
AGPL Section 13, sometimes called the “Network Copyleft” provision
This means that if you use the software in such a way that a user can interact with it over a network, and you modify the software, you must make your modified source code available. In a way, this treats SaaS similar to distribution under GPL. And while there are still no source code sharing conditions if you don’t modify the software, it can be hard to keep track and trigger a new compliance review if the software is modified in the future. So most companies are extremely hesitant about using AGPL software in a SaaS platform.
AGPL is not the only network open source license out there, only the most common. Some others, for example are:
- Server Side Public License
- Open Software License
- Non-Profit Open Source License
- Artistic 2.0
- Apple Public Source License
- RealNetworks Public Source License
- Reciprocal Public License
- Honest Public License
- Academic Free License [Note: this license is permissive. The others are copyleft.]
Most of these licenses are rarely used, and when they are, some — notably Artistic 2.0 — are dual licensed under GPL, meaning their network requirements are easy to avoid.
Most companies that have open source compliance policies “red light” these licenses and will not use them in SaaS development. So that means, at a minimum, you must still keep track of license terms and apply your compliance polices to SaaS software.
Distribution is Inevitable
Finally, an important reason to keep an eye on open source compliance, for server side code in a SaaS platform, is that SaaS code almost always gets distributed–someday. While the thrust of software sales today is toward cloud deployment, there are many reasons the deployment of software regresses to on-premises distribution. For example:
- Your company sells off the division that sells the SaaS.
- Your customer requires a local copy on its own server:
- Due to regulatory requirements (e.g. in highly regulated businesses like finance or health)
- Because of security concerns
- To avoid privacy issues arising from cross-border data movement
- Because AWS does not maintain a local hub
- Your company productizes an internal SaaS tool.
…and so forth.
Because any of these things could happen, you should ensure that you can distribute the software in a compliant manner, when you need to. So, you should avoid integrating GPL (or AGPL) and proprietary code in a way that could not be distributed in compliance with the open source license. This, in turn, means avoiding the use of GPL libraries (like MySQL)–or at least having a replacement at hand.
No Customer Risk
One question that sometimes comes up in commercial negotiations for SaaS vendors is whether a customer of a SaaS vendor can be “infected” by open source code. In short, the answer is no.
A pure end user of code cannot incur liability for violating an open source license. Open source licenses can be violated only by re-distributing software — or in the case of network licenses like AGPL, by modifying it and making it available to others as a service. In fact, GPL2 specifically says “Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted.”
In contrast, if the vendor is distributing software to a customer for the customer to provide its own SaaS to others, customary open source diligence is appropriate. But this isn’t a SaaS deal, of course. It’s a distribution deal.
So, end user customers of SaaS need not conduct diligence into open source licensing issues. If, for example, the SaaS vendor is using modified AGPL code to provide its service to the customer, then the customer may have a right to receive source code from the vendor. But that is a benefit, not a problem. In other words, the purpose of due diligence is to reduce the user’s risk, so even AGPL is not the user’s issue.
An update: take a look at Kyle Mitchell’s follow up on this post. Client side Javascript code doesn’t have a binary form, exactly, but when deployed in actual practice, it is not exactly source code, either. It can take intermediate forms that would not be considered source code, for purposes of licenses like GPL. Point your engineers to that post!
