Open-source is changing

SUMMARY

It’s important to understand your open-source exposure. Open-source is changing and the normal techniques of dealing with open-source need adaptation.

Find out more about how we can help here.

Open-source has revolutionized the world in many ways and benefited us all. It is now a given that people use open-source. However, the world of open-source is changing, particularly if you have a Software as a Service offering. The conventions on how you typically dealt with open-source to protect your IP while leveraging open-source still generally works. However, just like the software world is evolving, open-source is evolving too. This is an area that at one time or another will become important to you and your company, so it is important to understand the landscape.

Find out more about the Open Source consulting services we offer

Open-source enables rapid value creation…….

Open-source Software is everywhere, from your car, to your phone, to your computers. By leveraging industry standard, enterprise grade systems and components, we are all able to build on giants to rapidly solve complex problems. Linux, Apache and Hadoop enable many, many different parts of our daily lives.

Open-source enables you to create business value by assembling components instead of having to create everything from scratch. Imagine how much more expensive it would be to purchase or create your own web server, messaging, or data fabrics? Every engineering decision would require much more deliberation and approval.

The community and mindshare effect of open-source is the most amazing part of the open-source revolution. People are free to contribute to projects they feel passionate about, cross company collaborations spread cost, and cutting edge features are available quickly. Open-source solutions are often considered superior on quality and cost perceptions compared to commercial offerings.

…….When used the right way and avoiding the pitfalls

As a tool to create value for customers and companies, open-source is amazing. But, like any tool, it needs to be used the right way. If you don’t use open-source the right way, it can hurt you, just like using a drill the wrong way can hurt you. For most companies, open-source is a part of a larger product or service. Your proprietary code brings everything together to create the overall experience and platform for your customers. This proprietary code and know how is one of your organization’s key assets, and you wish to keep it confidential.

If you have used open-source software the right way, then you can enjoy the benefits of the hard work you and your team have undertaken. If used the wrong way, then you may need to publish your confidential source code to comply with the obligations of the open-source components you have licensed and used.

The common challenges that need rectification if you use open-source incorrectly are:

  1. If you change or modify a component, you are required to publish those changes back to the community – even if this happens to be your core intellectual property.
  2. You need to publish your proprietary code to comply with the license. Licenses like the GNU Public License (GPL) require you to publish source code if you use GPL code. If this is not done correctly, your entire offering can become open-source, severely reducing its value.
  3. Free is not always free. Some projects may be open-source for non-commercial use only, or have restrictive terms that can only be relaxed by purchasing a commercial version of the software.
  4. License terms change. You may have diligently selected a permissively licensed component, but find that the project changes its terms, to a more restrictive license, requiring you to publish source code, or pay license fees. In this case, you have difficult choices to make.
    • Do you pay the license fee and continue to use the component (with associated increase in your costs)?
    • Do you switch to an alternative component?
    • Do you continue to use the older version with permissive licensing, take on its maintenance and hope the community continues to maintain it as well?

Find out more about the Open Source consulting services we offer

Different kinds of Open-source licenses

To help set the scene for the complexity of the open-source landscape, the main impact of how you can use an open-source component is its license. These licenses exist on a spectrum of permissiveness and restrictive. Permissive licenses, like the Apache, BSD and Apache licenses let you use a component however you wish at the binary and source level – without needing to publish modifications. At the other end of the scale, licenses like the GNU Public License, GNU Affero General Public License require you to publish your source code if you use these components, even if they are unmodified.

It is this spectrum of licenses that makes using the right components the right way very important.

The traditional way to use Open-source the right way

The challenges outlined earlier have been faced by people using open-source in proprietary products successfully for many years in different ways, without incurring reciprocal license obligations (such as those of the GPL where you need to publish your proprietary code if you use GPL licensed components). The key approaches include:

  1. Use Open-source at the binary level. Reciprocal licensing obligations, particularly in the GNU public licenses were created when software was primarily distributed to customers – think of desktop software or that installed on your phone. Process boundaries are the key dividing line for when you need to distribute source. If you use an open-source component as a binary, with none of your source code, then you don’t trigger obligations.
  2. Use reciprocal licensed components in non-critical areas. Using reciprocal licensed in non critical areas such as a build system or testing framework does not impact the value of intellectual property, and makes it easy to contribute changes back to the Open-Source community.
  3. Architect and embrace reciprocal licensing correctly. Use reciprocal code in the right places, within the right process boundaries and separation can protect intellectual property, allow contributions back to the community, leverage the community’s work and promote yourself as a good corporate citizen from an open-source perspective.
  4. Pay for the commercially licensed version. This is often the simplest approach, as there are no technical roadblocks, but increased licensing costs over time.
  5. Provide a Software-as-a-Service offering. The rise of SaaS has in many ways negated the need to follow the reciprocal licensing obligations of most open-source software. When you run as SaaS, software is not distributed to users. The software runs centrally in an environment run by a company, and a web interface is provided. In this situation, the key trigger of reciprocal license obligations is not met. So, it is possible to use components such as MySQL without triggering GPL obligations where you have to publish your source code.

These approaches are commonly used throughout the industry to ensure that a company can use open-source and get all of the benefits, while minimizing the impact of the obligations. This has worked well for the rise of the SaaS era, as the major licensing regimes were designed for a desktop world.

Find out more about the Open Source consulting services we offer

The SaaS defence is weakening

Creating a SaaS has worked well for a long time when navigating the world of using open-source software. However, the world is changing, and it is becoming more difficult to use open-source software in a SaaS, and not triggering reciprocal licensing terms.

The GNU Affero Public license was an initial license that started to take into account providing software over a network and let others use it, you needed to provide source code.

A term that is used now is saying a product is “Source Available”. This means that the source is available for use and download, but it is not recognised as open-source. There are different obligations compared to traditional Open-source. The most dramatic license change in recent years has been the advent of the Server Side Public License (SSPL). This is a license that explicitly recognises SaaS offerings and ensures that a SaaS needs to publish all of its source code. This is the relevant text from https://www.mongodb.com/licensing/server-side-public-license

“13. Offering the Program as a Service.

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.”

This is a very sweeping clause that means if you use such a component in your SaaS, then the whole thing needs to be open-sourced, which is a drastic change for the open-source landscape. Interestingly, the SSPL is not considered an open-source license by the Open-source Initiative (OSI), and is considered a “source available” license.

The main open-source components impacted by such approaches to licensing are MongoDB and Elastic, which both changed their licenses to be SSPL oriented. There are options to purchase commercial licenses with the appropriate flexibility you may require. These are good examples of where the landscape changed, and how creating a SaaS is no longer the simplest way to comply with open-source licensing in a proprietary code base.

Over time, there are likely to be more and more “source available” components out there, which may impact how you build your own software.

Find out more about the Open Source consulting services we offer

Protecting and structuring your software investment in an Open-source world

If this article has shown anything, it is that using open-source software requires careful consideration and ongoing oversight to make sure you stay on top of your dependencies.  There are quite a few things you need to consider, beyond the licensing implications, which we have covered here.

  1. How well maintained is the open-source you use? Are the packages current and maintained? When was the last release? Are you using an orphaned piece of software that nobody is using anymore?
  2. Are you using current versions? Do you include a specific component version and then leave it until compelled to upgrade? This is one of those perennial tech debt tensions to consider in a code base. If you don’t keep current, then you run the risk of security issues and bugs creeping into your code base. However, you need the team bandwidth to make it happen. If you fall too far behind, then it can become more complex to get up to date.

Consider the example of the Express web server, highlighted in the following diagram. This component has a wide range of dependencies – each of which needs to be considered for license, maintenance and currency. And this is just one of many components in a typical system.

When to look at your Open-source exposure

Understanding the open-source you are using is something you should essentially have a handle on throughout your software / company lifecycle. However, it is something that companies often look for an understanding of in a few key situations:

  1. When you are starting out. In the early days of a project, a variety of open-source components are often selected as part of the architecture and key components. This extends as more code is added and developed. Make sure that the choices made here are compatible with what your business goals are. Otherwise, it can be very expensive to fix later on.
  2. When you are going to do a new release. This is more focused on mobile apps and when distributing software to customers. When software is shipped, make sure you have an understanding of what you include, to avoid any unnecessary reciprocal license obligations, or you have an appropriate process for handling them. If you are providing a SaaS, then you are likely doing much more frequent releases triggered by your DevOps pipeline.
  3. When you are about to get bought / acquired, or when certain large customers come on board. During this stage, a potential acquirer or customer wants to know that what they are getting is appropriately licensed. If there are any key license dependencies these will be identified here, and expect that you may have to undertake a variety of remediation activities to make sure the licensing is acceptable.
  4. When you are preparing yourself for sale. This is the other side of when you are about to be acquired. This is when you make sure that your “house is in order” and open-source dependencies are appropriate.

You may not know when a buyer comes along, so the recommended approach is to undertake periodic reviews, either on new releases, or once or twice a year.

Find out more about the Open Source consulting services we offer

How do you make sure you are using open-source appropriately?

This is where Thought Source come in, one of our newest offerings is to provide an analysis of how open-source is used within your software, the health of your open-source estate and what you need to do to resolve any issues.

We often undertake this in addition to a due diligence or technology review activity. This means we understand how open-source fits within your broader technology strategy, an understanding of your team and the structure of your technology and software. By providing this holistic analysis, you can get insights into where to take your technology going forward, and addressing any pressing issues you need to handle.

For more details about how we do our open-source reviews, especially in the context of a broader review, have a look at the relevant pages of our services – https://www.thoughtsourceconsulting.com/open-source-review and https://www.thoughtsourceconsulting.com/technology-capability-review