For many CTOs, CEOs and in-house lawyers, the use of open source software (OSS) in their organisations has long been put in the too-hard basket. The risks (real or perceived) of inadvertently tainting proprietary code with the fuzzy, permissive terms applying to OSS are not well understood by many people, and even fewer have been willing to tackle them head-on.
The philosophy underlying OSS is that source code (usually jealously guarded and heavily protected as valuable IP) wants to be free. Early proponents of OSS tended to be inspired by concepts of freedom of property, and were inherently against the restrictive nature of intellectual property rights – a philosophy that didn’t blend well with Microsoft, Oracle and the other software giants as they rose to power in the 1980s.
Today, the term ‘open source software’ generally means that the source code (i.e., the humanreadable portion of computer code) can be seen, modified and redistributed by the public without paying any royalties or licence fees – resulting in a continuing cycle of open and collaborative improvement for the benefit of society in general.
There is a catch however. Despite a common misperception that OSS means ‘licence-free’, users of OSS are still subject to a software licence, just as users of proprietary, commercial software are. OSS licensors still use copyright law to control the behaviour of users; but rather than using it to curtail or restrict what a user might otherwise be able to do (i.e., copy or distribute software), they use the powers they have as copyright owners to ensure that the OSS remains ‘free’, and that users aren’t able to impose on it their own restrictions.
The principal fear relating to using OSS arises from a concept known as ‘copyleft’ (as in the opposite of copyright), which arises in some – though not all – OSS licences. More pejoratively known as ‘viral’ licences, copyleft licences (the most well-known of which are the GPLv2 and its successor GPLv3) provide that the terms that apply to original OSS are inherited by any subsequent licensee of that software, or variations of it. In practice, this means that if an organisation wishes to redistribute software which includes elements of OSS, then it may have to make available the source code to all of that software under the terms of that licence, including elements of the code which it might have thought were proprietary.
This of course leads to a significant grey area – determining exactly when a "work is based on the [OSS] Program" (in the words of the GPLv2). Answering that question will require a detailed working knowledge of the code in question, and how the derivative work or adaptation came to be – but it is a question that only needs to be asked in relatively few circumstances. Copyleft provisions are only triggered if a licensee distributes the OSS – so if it is only ever used internally within an organisation, then those provisions shouldn’t cause any problems.
The GPLv3 also clarifies that making software available as a software-as-a-service (SAAS) offering does not constitute ‘distribution’ of the software.
The problem is that for many potential users, the relatively rare and avoidable effects of copyleft licences can distract from the obvious benefits that OSS can offer – zero licensing fees, reduced development costs, flexibility across software solutions and vendors and regularly (and freely) available fixes and updates through the collaborative OSS community. The majority of OSS licences (including the MIT, BSD 2.0 or Apache 2.0 licences) do not contain copyleft provisions – and for that reason, tend to apply to the most popular OSS products.
There is also a huge amount of reputable, mature, and well supported OSS already in use by a large number of businesses (a 2011 Gartner survey put the figure at more than half of surveyed organisations) – including the Android and Linux operating systems, applications like Mozilla Firefox web browser, and server software like Apache or database software like MySQL.
This doesn’t mean that problems can’t arise. Pre-acquisition due diligence of an organisation distributing software should ensure that any applicable OSS licences have been complied with, and – as would be the case with any other software – confirm that the downstream licence rights granted by the target haven’t exceeded the rights it has been granted by the original licensor.
It may also be worth investing in a code scanning service to verify the extent of any OSS in a target’s software product.
For organisations considering procuring a solution that includes OSS, very little can be expected in the way of warranties, and a clear understanding of exactly which OSS licences apply will be needed. It may also put more pressure on contracted support services if something goes wrong, and some would argue that a supplier of OSS support services has less commercial incentive to get to the bottom of a problem than someone who has invested a lot of time and money in developing and marketing proprietary software.
Regardless of an organisation’s own views on the open source philosophy, the reality is that the use of OSS is on the rise. The perceived risks may or may not be acceptable, but understanding those risks and setting down an organisation’s stance in a formal internal OSS policy can help to manage any issues before they arise, as well giving to potential investors or acquirers the same