Open Source is one of the key drivers of FinTech innovation, but it comes with a number of risks though and an effective Open Source Software Compliance framework is a must for all companies employing OSS. Here is why.
Open Source Software is one of the key drivers of FinTech innovation and estimates from a Gartner report claimed that open source is part of mission-critical software in 95 percent of global enterprises. And the future is bright: revenue of open source services is projected to breach the $20billion barrier next year.
In light of all the enthusiasm for open source programs it’s also important to stress the need for a few compliance considerations to avoid some common pitfalls.
What’s Open Source?
Let’s have a quick look at the basics though and clarify a few things. First of all, what’s open source? Everyone has an idea but it can generally be boiled down to something people can modify and share because its design is publicly accessible. OpenSource.com describes it though as a broader set of value in particular in the context of software development. Therefore, “open source projects, products, or initiatives embrace and celebrate principles of open exchange, collaborative participation, rapid prototyping, transparency, meritocracy, and community-oriented development”.
Pros & Cons
And then there are of course a number of reasons why open source is so popular and fundamental for FinTech innovation. Open source is more flexible and agile as it usually offers multiple ways to solve problems. It’s development is faster and accesses to a larger community working on the same software, thus is not necessarily limited by enterprise resources. The fact that it draws from outside resources is one of the reasons that make it also more cost effective. Others are that it allows for various stages of application and shares maintenance costs across different parties.
However, there are also a number of downsides to the use of open source: because many of its benefits are based on its community, it can also be rather dependent on the input of community developers. Not only does that mean that they will drive the direction development will be going and leaves little chance to influence this process, it could also result in the complete drying up of external resources if there is no longer interest to continue development in the community. Typically, open source software is not necessarily the most user-friendly as it is often a mere afterthought. And then there is the most obvious aspect: as it is open and accessible to many, it opens the door to malicious users who can exploit any vulnerabilities.
Risk Management
Hence, this and other considerations make it necessary to consider some fundamentals that it doesn’t all end in tears. Generally, we can identify three areas that we need to focus on for effective risk mitigation: the origin and licence of used software; respective license obligations; and the fulfilment of these obligations.
As a result, any company using open source software needs to ensure compliance with both license obligations and contractual obligations towards third party providers, and protection of copyrights of third parties as well as the protection of a firm’s own intellectual property and that of their clients and partners.
To do that an efficient open source compliance program needs to be built on comprehensive policies and processes as well as adequate training and proficient tools to monitor and enforce this framework.
In practical terms
Let’s demonstrate the issues in more practical terms using three common shortcomings with regard to licences, intellectual property and the compliance processes.
For instance, a common issue in terms of licencing is the failure to publish the source code. Diligently documenting the use of source code and checking for any required publication can easily avoid this. This in turn though requires that an adequate training regime is in place, so that the importance of this aspect becomes an automated addition to the process itself.
When we refer to intellectual property issues, we mean the infringement of proprietary, third party, or open source code by using source code that comes from incompatible or conflicting licenses. It is the good old copy & paste issue where developers for instance add open source code into proprietary or 3rd party source code via copy and paste into proprietary or 3rd party software or the other way round. It is estimated that almost 2/3 of all data breaches can be linked to third-party vendors and overcoming third party risk, for instance, is one of the key obstacles for RegTech firms. If I employ an effective scanning tool, I can identify all open source code, its origin and the respective licences. Again, this should be accompanied by sufficient training to make developers aware of such compliance issues at an early stage.
On the other hand, to use a common failure of compliance processes, we can simply look at the failure to submit a request to use open source. Open Source is often confused with no questions asked. Instead, permissions may be required and a comprehensive compliance process should consist of recurring scans of the software platform to detect any undeclared open source code, regular training of software developers on a firm’s open source policies and processes, and regular reviews of the framework.
Serious consequences
While this may seem burdensome and possibly even at times exaggerated, it’s useful to remind ourselves of the consequences of the failures described in the scenarios above which can range from delay in the deployment or interruption of use of a software solution to reputational damage to considerable fines in the case of violation of contractual obligations.