The open-source software (OSS) movement is currently undergoing a renaissance. Businesses should be aware of the legal risks OSS poses and how best to manage them. There are many examples of the advance of this type of software. Google’s open-source Android operating system has redefined the smartphone market and Linux’s share of the desktop operating system market is increasing. Businesses which would never previously have trusted open-source applications now use OSS like Apache, mySQL and JBoss with confidence. And nearly every software development project today uses open-source tools and libraries to some extent.

What is OSS?

Proprietary software is distributed in "object code" form (also known as the executable form because it is the form in which the computer runs the program). This is a set of files that contain the program in a form only the computer can understand. The "source code" form of the software – written in a human-readable programming language such as C+ or Java - is a closely guarded secret.

By contrast, OSS is distributed in source code form. Having the source code allows anyone to understand how the software works, to customise or modify it, to maintain it and to make it work with other software.

What are open-source licences?

Computer programs are protected by copyright. The person who owns the copyright in a computer program (usually the developer) has the exclusive right to copy the program - which is necessary to run a program on a computer - and to allow others to copy it.

A copyright owner may permit other people to use its software subject to the terms of a licence. The owner can enter into licence agreements with specific customers, or may publish a licence allowing anyone who complies with the terms of the licence to use the software. Open-source licences are in the latter category. If a person uses the software in breach of the terms of the licence, then this will constitute copyright infringement.

A copyright owner can specify any terms it wants in a licence. For the sake of convenience it will usually use an established open-source licence, but there is nothing to stop it writing its own or amending an established licence to suit its purposes.

Types of open-source licence

Open-source licences come in different forms. Some are very permissive and allow licensees to do just about anything with the software. Others are highly restrictive and place conditions on the use and modification of the software.

The MIT License is a free software licence produced by the Massachusetts Institute of Technology (MIT) and is an example of a highly permissive licence. It allows anyone to use, copy, modify, merge, publish, distribute, sublicense and sell copies of the software. The only restriction it imposes is that the copyright and permission notices must be included in any copies of the software.

The Apache License is a popular moderately permissive licence. The latest version permits anyone to reproduce and distribute copies of the software provided that they:

  • Distribute a copy of the licence along with the software 
  • Mark modified files as having been modified
  • Retain all copyright, patent, trademark and attribution notices

The GNU General Public License is an example of a "copyleft" license and is probably the most restrictive of the well-known open-source licences. The concept of copyleft was developed by open-source advocates who were concerned that commercial businesses could use and modify open-source tools without giving anything back.

Copyleft licences require that anyone who makes modifications or additions to the source code, and then seeks to distribute the resulting product, must make the source code of the resulting product available under the same copyleft licence terms.

What are the risks associated with copyleft licences?

Copyleft creates a potential issue for commercial software developers: if a developer uses tools and libraries licensed under a copyleft licence in a product, they may be required to make the source code of their entire product freely available to the public. This would preclude the developer from charging a licence fee for their product (although they could still charge for support or other services) and would also allow the public to see how their product works and potentially copy or modify it.

There is considerable debate among lawyers as to the legal enforceability of a copyleft licence. Depending on the specific licence, this may come down to a question of whether the product is a "derivative work" of the open-source work under US copyright law. This can depend on the technical details of how the open-source work has been used or modified – for instance, whether it has been statically or dynamically linked to the rest of the application.

The bottom line is that if you are developing software which includes open source tools or libraries, you should obtain legal advice on what obligations the open-source licence may impose on you.

What are the other issues with open-source licences?

OSS is inherently susceptible to intellectual property disputes. Many open-source projects are collaborations involving many different developers. There is a risk that one or more of those developers will infringe copyright by copying a third party’s code.

Unfortunately there is little that can be done to mitigate against this risk. In proprietary software licences, the developer often indemnifies the user against intellectual property infringement claims. Open-source licences seldom include such an indemnity. Indeed, many such licences expressly exclude any liability of any of the developers for intellectual property infringement.

It may be possible for a user to conduct due diligence on the open-source project to satisfy itself that the risk of intellectual property infringement is small. However, such checks are made more difficult where a project has involved many different developers over a period of years. It may not be possible to identify the developers, or to identify which parts of the code were written by which developers. Ultimately, intellectual property infringement arising from open source projects may be a risk your business has to accept.

Another potential issue is that OSS is generally provided on an "as is" basis – meaning that the developers provide no warranties that the software complies with any documentation or is fit for any particular purpose and exclude all liability for this. It is, therefore, important that businesses fully test open-source software to ensure it meets their requirements prior to implementation, rather than relying on documented functionality.

Open-source licences can generally be revoked or changed by the developer at will. Proprietary software licences generally take the form of a contract between the vendor and the customer. Under contract law, as long as the customer complies with the terms of the contract, the vendor generally will not have the right to unilaterally cancel or revoke the licence. By contrast, because an open-source licence is merely a permission from the copyright owner, the developer is entitled to revoke or change the terms of an open-source licence. In practice, however, developers very rarely do this, and some licences are drafted to prevent them from doing so.

Finally, it is worth noting that the legal enforceability of open-source licences has yet to be tested in most jurisdictions. While there have been a large number of cases involving OSS, to date only a few decisions – in the USA and Germany - have involved a final ruling that an open-source licence is legally binding.

Key steps when using OSS

To mitigate and manage the risks associated with OSS we recommend that companies:

  • Identify any OSS used in their businesses and obtain copies of the relevant licence agreements and, if any of these licence agreements are "copyleft", obtain legal advice on what obligations the licence imposes and how this may affect their rights. 
  • Conduct due diligence on the developers of the software to assess the risk of intellectual property infringement. 
  • Fully test the software to ensure it meets their requirements prior to implementation, rather than relying on documented functionality.