Many of today’s most exciting new technologies are powered by open source software (OSS). With everything from the Android operating system to the WhatsApp messaging app built using OSS, it has become the fastest way to launch products and replace legacy tech.
But should every enterprise simply pick up the OSS of its choice and start using it? In this article, we discuss the benefits of open source for enterprises and outline some of the considerations that you should discuss with your legal and procurement teams before adopting OSS in your organisation.
With some 80% of IT departments reporting plans to increase their use of OSS in 2021 , just what is so compelling about the open source approach? Security is often cited as one of the key reasons enterprises adopt OSS, and it is true that exposing the codebase publicly for the entire community to access and test is an excellent way to keep the technology secure and maintain long-term trust with end users.
Another key benefit of OSS is transparency. Users have full visibility of the codebase and the discussions around how different features and bugs were addressed. Unlike proprietary code produced behind closed doors, OSS comes with no nasty surprises.
The same community that keeps OSS secure also ensures that the solutions introduced via OSS are enhanced faster, more consistently and more effectively than any individual team could achieve on its own with a proprietary solution.
Vendor lock-in is less of a risk because if you are not happy, you can switch, enabling the kind of business agility that makes digital advantage easier to achieve.
Overall, OSS offers access to secure, reliable software that can be customised to suit specific needs at a relatively low cost. OSS should not be confused with freeware, but the fact that it involves no licensing fees is one of the many persuasive grounds for embracing it.
Delivering generally superior quality outcomes to the proprietary equivalent, OSS offers the kind of community-driven upstream innovation and enterprise-level support that cannot be overlooked, and it can be instrumental in attracting talent to your organisation. However, some companies are reluctant to adopt OSS because of perceived risks and fears around intellectual property (IP) rights and licensing obligations.
It is true that OSS is licensed in a non-standard manner — but that does not mean it comes with no IP protection. OSS copyrights usually require the licensee to ensure that any redistribution of the software is done on the original terms — generally, in complete form, with source code and with few, if any, restrictions.
Developers distribute their work under an OSI-compliant licence , which is what enables the community to continue developing the software. According to the Open Source Initiative , an open source license should meet the following criteria:
With more than 100 approved open source licences available, the process of licence compliance can be daunting, but most OSS licenses fall into the category of either permissive or restrictive (also known as reciprocal, viral or copyleft) licences.
Permissive licences such as the Apache 2.0 and MIT allow licensees to freely modify, adapt and combine the OSS code with proprietary code, whereas restrictive licenses, including the GPL and AGPL , require licensees to re-license their specific developments under the original licence and also make the modified source code available.
If you are including OSS with a restrictive licence alongside proprietary software for which the source code is meant to be publicly unavailable, you need to take care not to accidentally end up with your own software subject to licensing under the open source license terms.
The Linux Foundation's Open Compliance Program is a useful initiative for software compliance in the OSS community. It provides a self-assessment checklist, software tools for identifying open source content in software deliverables and a directory of companies that use OSS. The foundation’s OpenChain Project has created ISO 5230, the International Standard for open source compliance.
Fortunately, most OSS is developed under one of a handful of licences, making compliance easier. Fastify, NearForm’s web framework of choice, operates under the MIT licence, for example, as do Clinic.js and Pino.js — two open source tools our developers helped to create. Nonetheless, it is important to have a policy in place to manage your OSS procurement successfully:
Within your organisation, you need to decide which open source licences your company can and cannot use, and the process to be followed for exceptions. You will need to create lists of both approved licences, and licences to be avoided, and outline an approval process for all other licences. The list of approved licences will differ depending on what the OSS is being used for, with greater scrutiny being required if the OSS, or a portion of it, is being used in the deployment or distribution of your products.
To ensure you comply with the various licence obligations, you need to audit your entire development and deployment processes, bringing together all of the licence terms and determining the business purpose for each licensed component.
Remember that if you breach the terms of an OSS licence, you are potentially liable for copyright infringement. That could mean termination of the licence and a court injunction preventing you from using the software in the future — not to mention financial penalties for its wrongful use and legal fees.
Once you have decided to integrate OSS into your enterprise software, you need to work on building strong relationships with the communities behind the software. At NearForm, we are active members of the open source community, encouraging our developers to contribute to open source technology, and we also organise NodeConfEU , the key Node.js event in Europe for the Node.js community.
Not only does this involvement help to ensure the ongoing quality and security of OSS, it also means we can be involved in creating open source tools to identify errors early in development so that technical debt is reduced and developers can spend more time developing new features. Clinic.js and Pino.js are examples of these.
In your own organisation, you should appoint an appropriate developer or development team to take ownership of the OSS components they are using, and even create a centralised open source team if budget allows.
Procuring enterprise software usually involves substantial work by legal and procurement teams to investigate issues such as contracts, licensing and support. That does not apply when you procure OSS, but you still need to investigate what OSS your developers are deploying to production.
You need to ask the right questions when procuring OSS for your enterprise projects; your organisation’s open source owner or team should lead your research into the OSS components to be included in your enterprise software. They should investigate who is maintaining the code in question, whether they will maintain it as long as you plan to use it, and who is available to help if something goes wrong.
Criteria for evaluating OSS can be agreed by IT, DevOps, security, legal and procurement. When code selections are made following thorough vetting, they can be added to a properly maintained database of approved options that developers can check when introducing new code.
Another option is to make developers individually responsible for referring to the procurement team’s standard checklist of approval criteria for software before they adopt new open source components. This approach would need an approval process to document that the criteria have been met.
The most innovative and forward-thinking organisations are taking steps to ensure OSS licence compliance so that they can avail of such benefits as faster development time, community-supported development and code review, and platform adoption.
By adopting prudent IP strategies and implementing an open source procurement process, these organisations are reducing risk across the enterprise and product lines. Asking the right questions and putting appropriate standards in place before developers start using the components help to unlock the true potential of OSS, bringing us a step closer to a world in which tedious, manual processes are replaced by digital services and convenience.
Open source is here to stay, and so the question becomes not whether a company should use open source software, but how open source software can be used in the most effective and compliant way.