The fear of open-source software 

[Average reading time: 5 minutes]

Open-source Software (OSS)

Many IT companies and software developers use components or libraries that are available under an open-source software license. There are many reasons to do so. Yet, there seems to be a widespread fear that the use of open-source software is not suitable for commercial use. In fact, commercial use may very well be restricted by certain OSS licenses, first and foremost by Copyleft licenses such as the GPL 2.0 or GPL 3.0 license. Due to the sheer number of OSS licenses available, it is impossible to state, as a general rule, that every OSS license allows commercial use. Vice versa, this does not mean that commercial use is prohibited as soon as there is a single OSS component, module, or library included in the final software or other IT product. The requirement to license software under an OSS license, known as the 'viral effect',  is generally limited to Copyleft licenses such as the GPL 2.0 or GPL 3.0 license. That is why it still is important to have an OSS compliance system in place.

If you plan to make your software available as cloud solution (SaaS, PaaS or similar solution), OSS Compliance does not become obsolete. Instead, the focus is shifted from restrictions on software distribution to the questions of whether your preferred OSS license is compatible with Software as a Service (SaaS) use and whether you can prohibit competitors from copying your software and providing it as a SaaS solution under its own brand.

OSS Compliance

Open-source software compliance may actually help you to avoid developing a fear of OSS. Such fear could arise when you want to sell your IT business, carve-out parts of it, or commercialize a software product you have developed. In such a scenario, you may be asked by a potential purchaser or investor to show, during a due diligence process or otherwise, that the software you want to sell does not require OSS licensing other than intended by you. Let's say you have developed a photo editing software and want to sell individual copies to end-users. In such a scenario, it would be crucial not to have modules integrated into your software which are licensed under a Copyleft license. Otherwise you you would not only have to disclose the source code of the respective module, but also the rest of your software. That is why a potential purchaser or investor my request a deep scan of your software product which might be done by scan services provided by WhiteSource, BlackDuck, FOSSID, or revenera, among others.

So what does it mean and require to have an OSS compliance system in place? OSS Compliance typically requires some thought on (at least) the following items and reasonable documentation thereof:

• Open-source software policy, including processes and responsibilities
• Training and supervision of employees and contractors
• Process to determine the OSS license applicable for the OSS used and analysis of the obligations based on such OSS license. 
• List of OSS licenses used for a specific software or project 
• Contact person for internal and external requests
• Process to implement the obligations based on the applicable OSS licenses (including provision of LICENSE files and copyright notices)  
• Review of license compatibility and assessment of compliance with Copyleft requirements to the extent such OSS is used
• Process for (external) contributors including contribution agreements 

Some of the items listed above can be done by a member of the dev team (e.g., creating a list of OSS licenses, training other developers), some require the supervision by a member of the management (e.g., approval of the company's OSS policy), and some tasks may even require legal assistance (e.g., drafting a template for a contribution agreement or review of license compatibility).

OSS in SaaS Projects

While it is important for every IT business to have a basic OSS compliance system in place, the focus of open-source software compliance fundamentally shifts from traditional software distribution models to cloud services when it comes to SaaS solutions.

The OSS license used for the software provided as SaaS solution must allow or at least tolerate the use as such SaaS solution or other cloud service. OSS licenses often have different terminology and do not state a specific applicable law. Instead, they aim to be universal - in a world defined by local copyright laws. 

Permissive Licenses

Permissive licenses often allow commercial use and give you the freedom to add license terms to your software if it is a modified version of OSS provided under a permissive license. The downside is that there might be a risk of copycats in certain scenarios. If you provide your software as SaaS solution to a business customer and that company decides to offer a competitive SaaS solution based on your software, the permissive license does not hinder that competitor from building a competitive product based on your software.

Copyleft Licenses

Some older OSS licenses such as the GPL 2.0 link their obligations to the act of distributing software. For SaaS solutions, however,  there is no distribution required. 

The more recent GPL 3.0 differentiates between propagate and convey. The GPL 3.0 defines that "Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well." In contrast, conveying means making or receiving copies. Under the GPL 3.0, the main obligations are only triggered when conveying the software. Providing a SaaS solution usually does not require copying. Instead, it is only required to make it available to the public, which, under the GPL 3.0, is considered propagation and does not trigger the main (Copyleft) obligations of the GPL 3.0.

For both the GPL 2.0 and the GPL 3.0, it seems widely accepted that these licenses do not prohibit (GPL 2.0) or explicitly allow (GPL 3.0) the use of software in a cloud environment, including SaaS, without triggering the Copyleft obligations of the GPL licenses. As a consequence, you would not have to provide the source-code of your software to the public when you make it available to a customer as SaaS.

SaaS specific Copyleft Licenses

Since Affero, Inc. considered the lack of Copyleft in SaaS solutions a gap, the Free Software Foundation granted Affero the right to modify the GPL 2..0 and to create the GNU Affero General Public License (AGPL). The AGPL 3.0 is a license which requires the licensor to provide the source code of modified versions to its users (not to third parties) and to license the modified version under the AGPL 3.0 when the software is provided as SaaS solution.

For companies with a huge codebase/repository like Google, a Copyleft license such as the AGPL might not be the right fit. In particular, Google states:

The license places restrictions on software used over a network which are extremely difficult for Google to comply with. Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is. The risks heavily outweigh the benefits.

Another SaaS specific OSS license is the Server Side Public License (SSPL) created for MongoDB. The SSPL, however, seems similarly unpopular.

Conclusion

While it may sound relieving that SaaS solutions do not entail the same risks as traditional software distribution models, it would be too short-thought to believe that the switch to the cloud makes it unnecessary to review OSS licenses and have a OSS compliance system in place. OSS due diligence is still required, but differently.

So, does it really matter for your IT business? That is a question I cannot answer for each and every IT business in every part of the world, but I hope you can draw your own conclusions for your specific business. If not, or if you have any further questions, feel free to contact me or send me an e-mail (hello@hak.lawyer). 

---

Copyright notice:

Photo by Markus Spiske via Pexels

---