An Accessibility Guide for Using Colors in Data Visualization
By Philippe Thomas, CEO at Vaultinum
Business decisionmakers in the UK are increasingly making the tech sector a priority for their investments, leading to astonishing levels of growth. Indeed, the UK is one of only three nations across the globe to have created more than 100 tech unicorns – private companies valued at over $1bn. £13bn was invested into tech by venture capital firms in the first half of 2021, making this a key time for investors and business owners alike to reconsider their investment risk prevention efforts.
In the tech sector, software is a primary asset of almost every investment. Despite this, it is generally not prioritised by investors carrying out due diligence efforts. Investors concentrate on financial, legal, and operations for their due diligence processes, but leave a lot to be desired when it comes to software. Software due diligence tends to be implemented manually, by non-experts, leading to an analysis which is far from comprehensive. As a result, a deep assessment of the use of open source software is lacking, which poses significant risks.
What is open source software?
Open source software is software that can be inspected, copied, modified and redistributed by developers. This differs from application software, which is designed for end-users and cannot be adapted in any way by individual developers, such as Skype or the Microsoft suite. The open source community operates on shared values of collaboration, and is currently thriving, with popular software development hosting site GitHub seeing 35% more code repositories created in 2020 than the previous year. The use of open source software can almost be considered a necessity nowadays for developers, as quick development is essential for businesses seeking an increased market share and competitive edge.
There are numerous benefits to integrating open source code within the code repositories of commercial software, so it certainly should not be viewed with fear by business leaders and investors. For example, open source code is less likely to become obsolete than in-house developed code, as developers will always have the backing of the strongly connected open source community for any required updates or bug fixes. That very community can also allow businesses to quickly resolve hiring difficulties and thus cut costs, as they can work with open source developers as an alternative. Though, investors will not be able to take advantage of these benefits for the long term if their open source implementation is poorly managed, which can often be the case.
Intellectual property restrictions can threaten your investments
Open source licencing can be complex, but when it comes to intellectual property, investors need to be particularly wary of any code bound by highly restrictive licencing. Copyleft, or so-called ‘non-permissive’ licences, require that when software is redistributed, it must be done so under the same or compatible terms as the original open source licence. The most commonly used copyleft licence to look out for is the GNU General Public Licence (GPL). This particular licence is known as strong copyleft because it applies not only to modifications made to the open source code originally licenced under the GPL, but also to any work that derives from GPL code. As a result, even if a developer only utilises a few lines of GPL code, their entire code base is bound by GPL terms.
If organisations opt to use code bound by restrictive licences such as the GNU GPL, their intellectual property could be at risk. Take Hancom Office, for example. In 2013 they built Ghostscript, an open source PDF interpreter, into their word-processing software. Ghostscript was bound by the GNU GPL, so according to the licence’s terms Hancom should have made its entire app suite open source, thus losing its IP rights. In some cases, such as this one, Hancom could pay a licencing fee to Artifex, Ghostscript’s developer. Artifex were open to waiving the restrictions of the GNU GPL if Hancom were willing to pay, which is certainly not a given for software bound by this licence. In 2017 Artifex therefore filed a lawsuit, which resulted in the US District Court ruling in Artifex’s favour. The exact terms of this settlement remain confidential, but it is sure that Hancom will have suffered significantly in terms of finances, reputation and its intellectual property rights.
Even when not as strict as the GNU GPL, all open source licences must be carefully reviewed by businesses, so that they are not unknowingly failing to comply with their restrictions. All open source licences share common principles inscribed in the ‘essential freedoms’ of the open source movement: being free to use, run, study, modify and redistribute open source software for any and all purposes. But there exists a plethora of different types of licences, so one piece of open source software can be very different from another.
Permissive licences, such as the BSD licence, the MIT licence, and Apache Licence v2.0, are a form of licence which differ from the hard copyleft of the GNU GPL. They maintain the ‘essential freedoms’ of the open source community, but do not require that these are upheld in derivative works. So, developers can be free to integrate open source software with a permissive licence into their wider codebase without consequence, distributing the full software under separate licencing terms, which is not possible with more restrictive licences. The wide diversity of open source licencing convention means that businesses must monitor and assess the various open source code used by their developers so that they do not run into any non compliance issues.
In the pre-acquisition phase investors must ensure that they implement comprehensive software due diligence which analyses the open source licencing restrictions of a piece of software, as well as checking for any potential cyber-exploitation and maintainability risks. The most comprehensive audits will use an algorithm able to scan every line of code, combined with expert review, to ensure that any use of open source software is identified and assessed accordingly. This process must also involve a thorough assessment of a business’ internal processes, including their open source management strategy, to mitigate for and avoid any possible risks in the future.