Open source software (OSS) is a prevalent type of software that can increase the agility of software evolution, reduce the costs of software procurement and development and enhance the speed of market penetration. However, it comes attached with significant operational and legal risks which need to be considered when adopting or acquiring solutions with significant OSS components. At worst, incorporating OSS code into your product can mean that the source code in that product must be available to everyone at no cost.

Introduction to open source software (OSS)

OSS is characterised by the public availability of the source code at no cost, under licence terms that oblige any users of the code to keep the code publicly available under those same licence terms.

There are currently 93 OSS licences approved by the Open Source Initiative1 though estimates have put the total number in use in the thousands. As each licence will vary slightly, it can often be difficult to determine with precision what rights a person has in any given compilation of OSS code. For example, some OSS licence terms include an obligation to preserve notices identifying the original programmer/author, or require the licensed software to be capable of use in any way without restrictions.

Copyleft licences

One specific category of OSS licence is the “copyleft” licences, so named because it does not allow the programmer who uses the "copyleft" code to create an application to exercise the usual proprietary copyright and patent rights in the resulting work product.  Instead, the new application will be subject to the copyleft licence terms. This means that the programmer would not be entitled to charge for a licence to use that application. Instead, the new code used in the new application must also be publicly available and free to use for everyone at no cost. It is for this reason that copyleft OSS licences have been described as having a “viral” effect on any proprietary code into which it is incorporated and even on code that is combined or distributed with it.

OSS in products

Where an OSS licence requires the publication of the source code at no cost, the incorporation of any OSS will immediately impose an obligation to disclose relevant OSS component source code in a proprietary software product to any customers and this may include disclosing the relevant licence terms for that component. This is not controversial, and many enterprise proprietary software packages contain pockets of source code among the installed files. However, if copyleft OSS is involved the obligation to disclose source code may apply to the entire code base. An obligation on a company to disclose all the source code in one of its products (which may perhaps only incorporate a small amount of copyleft code) can be disastrous as source code is normally kept confidential and secure to protect to company’s valuable IP and the commercial advantages attached to access to source code for a product (which is extremely useful in creating a competitive product).

In the event there is a breach of an OSS licence, such as through a failure to provide the source code for that OSS component, the vendor is exposed to a risk of copyright (and possibly patent) infringement by the relevant author(s) of the OSS component. Cases in Europe and the United States have arisen where OSS was inadvertently (or “unintentionally”) incorporated by software vendors into their products and the owner of the code commenced proceedings against the vendors and the vendors’ customers for copyright and patent infringement.2 Remediation of code often involves identifying all OSS in a code base for the software product, and then providing a copy of the OSS source code and applicable licence to each customer.

OSS in back-office systems

In back-office systems, organisations can benefit from the free and open development of code by developers in the community, as well as having full access to the source code to create in-house modifications and modules suited to its own business. As the software remains in internal use and is not distributed or sold, the consequences of any copyleft obligations attaching to the code base are reduced (but not removed altogether). 

Other uses of oss

Monetisation of OSS products is possible, often through the provision of related products and services rather than directly through the OSS product itself. Additional apps, modules, features and functionalities may only be available at a cost after the prospective customer has had the opportunity to use the more limited OSS version. Enterprises will pay for the packaging, updating and distributing an OSS platform – Linux operates on this basis. Training, documentation and new features may be developed and supplied for a price. OSS products have also been used to sell support and maintenance services in relation to the OSS product, or offered “as a service” as part of a cloud solution.

OSS risks

There are three key risks of adopting a principally OSS solution, which should be taken into account before any strategic IT decision is made. 

The first, arises from the common misconception that OSS is completely free to use. However, OSS remains licensed software and upon acceptance of the OSS (generally by use of the software), the user is bound by those terms. If software developers are not careful in borrowing lines of code from code libraries which are available online, they may inadvertently impose copyleft terms on an entire proprietary software package.

As described above, a copyleft licence in an organisation’s proprietary software portfolio (and particularly in any product offering) can have significant ramifications on an organisation in the event a programmer makes a claim for copyright infringement because OSS licence terms have not been complied with. In the very least, OSS can reduce the value of the software in a company from a valuable proprietary right, to an asset encumbered with licence conditions.

Second, OSS is rarely provided with any warranties as there is generally no quality assurance testing or standardisation of coding methodology used by the developers as a class. Thus, use of OSS will be at the user’s own risk, inclusive of all its licence terms and software bugs or vulnerabilities.

Mitigation of this risk may entail investment in the IT department who will troubleshoot, support and maintain the software internally, train personnel and prepare supporting documentation. This cost will need to be factored into the cost-savings of using OSS.

While insurance can be taken out to further mitigate some of the risk in bugs and vulnerabilities in software, some policies may expressly exclude vulnerabilities introduced by OSS. In these circumstances, organisations should be careful in offering any warranties or indemnities in relation to intellectual property rights in its products and IT systems, and take account of this heightened risk in its IT business continuity plan.

Finally, the public availability of the source code means the code is accessible to both developers and hackers. The likelihood and risk of a security vulnerability being identified and exploited are thereby increased, although a diverse pool of developers may reduce the time to develop a patch. For example, the “Heartbleed” security vulnerability was identified in Open SSL,3 a common cryptographic code used in over 66% web servers in the world, many email servers, chat and virtual private networks, and made headlines for the untraceable exposure of highly sensitive personal information, emails and financial data.

A failure to promptly rectify the issue, whether by applying a security patch or transitioning to a different system, creates an exposure to claims there was a failure to reasonably secure personal information from misuse, interference loss or unauthorised access, modification or disclosure (in breach of Australian Privacy Principle 11) or a breach of confidentiality obligations in relation to the financial data by recklessly allowing its disclosure. In addition to any remedial costs, fines and damages that would flow from these claims, the reputational damage could also be significant.

Closing thoughts

OSS is a very powerful tool that can be used effectively to create cost-effective software and support agile business models. However, its adoption comes with risks. A proper risk assessment, both legal and technical, is recommended before adoption of OSS in any products or business critical functions.