At this very moment, someone, somewhere within your organisation is probably using open source software. Maybe it's being used to run mission critical servers or to slot into a newly developed application.
So what, you might say, it's better than a free lunch - the relevant open source software is good enough, practically cost free and makes business sense. However, just like any other business activity, using open source software involves risks and costs. You should ensure that those risks and costs are considered, and weighed up against the perceived benefits, before deciding whether or not that person should be allowed to continue using the open source software.
This article highlights the potential benefits of using open source software, contrasts those benefits against the risks, and suggests strategies to mitigate those risks. If you have any queries or concerns about the legal risks of using open source software, please contact one of Bell Gully's IT law specialists.
In brief, open source software is software and its human readable source code made available by developers:
However, conditions are often placed on redistribution of open source software, including requirements that any redistribution of the software and any modifications:
Conditions similar to these are set out in the GNU Public Licence, which applies to the use and distribution of Linux, but there is a broad variety of open source licences containing variations on these conditions.
It may be that there is a sole developer of the open source software, but it is more common for the open source software to have been developed by a number of different developers (i.e., a community of developers).
Open source software can be contrasted with closed source or proprietary software, the developers of which closely protect the source code, only providing the machine readable object code to licensees that have:
The following key benefits can be identified in relation to open source software:
The following key risks can be identified in relation to open source software:
Looking at open source licences, the key elements of acceptance and consideration may not be present as:
As two of the key elements of a contract could be missing, it is unlikely that the legal foundation for open source licences is contract law.
Instead, the legal foundation for open source licences is seen to be copyright law, and a copyright licence can be amended or terminated at any time by the licensor giving notice to the licensee. As a result, there remains a risk that an open source licence could be changed or terminated unilaterally at any time by the developer.
That said, if the open source software was developed by a number of developers, and they have joint ownership of the copyright in the software, then they would all need to agree to the change or termination.
It may also be possible to claim that the developer should be prevented from terminating or changing the open source licence under the common law doctrine of estoppel. This doctrine prevents people from going back on representations that others have relied on to their detriment. However, in each case it would be necessary to establish such a representation was made, as well as reliance by the relevant user to their detriment.
The risk of problems with open source software falls on the user. In general, no warranties are provided in relation to the performance or operation of open source software. As a result, you cannot turn to your supplier and seek damages for breach of warranty.
That said, it may be possible to argue that the exclusion of implied warranties and tortuous claims in most open source licences doesn't work at law (on the basis that the licence is a copyright licence, not a contractual licence, and copyright law does not support such exclusions).
This might be a difficult argument to win though, as the licence terms provide good evidence that the user has voluntarily assumed the risk of use. In addition, the relevant licensor may not have pockets deep enough to justify legal action.
Lastly, by way of comparison, it should be remembered that most proprietary software is supplied on terms and conditions that limit the developer's liability as much as possible (unless the user had very strong bargaining power at the time of licensing).
More than 50 different open source licences are listed on the Open Source Initiative's website. As a result, it is not possible to assume that the kinds of use, development and distribution that you are contemplating will automatically be permitted by the applicable licence.
The main risk that arises here is that your rights to redistribute might be fettered. As mentioned above, a number of open source licences require that if modifications are made to the software and distributed, then they must be distributed with the source code for the modifications, on the same terms as the original licence (i.e., at no or minimal cost).
This does not present problems if you merely intend to develop modifications for internal use. However, if you plan on providing the modifications to others you do business with, or selling them to customers, then a check of the licence may indicate that you need to think again, as you might have to provide them at no charge or let your competitors also have access to the modifications.
Although the up-front costs of open source software may be minimal, it must be remembered that there are other costs involved in the use of software, particularly maintenance and support. In this regard, a total cost of ownership approach should be taken to open source software, considering not just the up front licence costs, but the costs of support and maintenance and scaling for future growth.
Even though the source code for an open source product will be available, you should budget for and retain technical staff skilled in its use, support and modification, or contract with service providers to obtain access to such services. This need has provided business opportunities for organisations that specialise in the support and modification of open source products.
Recent studies initiated by major IT companies are equivocal as to the total cost of ownership of major open source products. On one hand, studies initiated by organisations that have their own open source initiatives (including hardware and support providers) indicate lower total costs of ownership of open source software. On the other hand, studies initiated by organisations that don't have open source initiatives indicate that proprietary software has a lower total cost of ownership. In effect, it will be up to you to make a call about the total cost of ownership of the software for your enterprise.
Most suppliers of proprietary software will give their customers an indemnity in relation to the breach of third party intellectual property rights (although these tend to be limited as much as possible). Under the indemnity, if the customer is sued by a third party on the basis that the software breaches the third party's copyright (or other intellectual property rights such as a patents), then the supplier is required to pay the customer's costs and step in to run the defence of the claim.
Most proprietary software suppliers give such an indemnity as they have confidence in the integrity of their software development processes and have good patent protection, or can carry the risk of patent claims (being satisfied based on patent searches that this risk is minimal).
Such indemnities are generally unavailable in relation to open source software, as the supplier cannot have the same certainty regarding the integrity of the development process. The risks that arise as a result have been high-lighted in the recent claims by SCO Group against IBM regarding breach of SCO's rights in Unix source code.
Perhaps as a result of this claim, some commercial suppliers of open source software are starting to offer indemnities regarding breach of third party intellectual property rights (for example, the supplier of the JBoss application server).
The first step in mitigating the risks that arise is to establish an enterprise wide policy on the use of open source software, and make sure it is followed.
At one extreme, this policy could completely ban the use of open source software but this would be a knee-jerk reaction and may not prove effective (as people sometimes react to outright bans by ignoring them). Instead it may be better to allow the controlled use of open source software, for example, only allowing the use of software that has proven to be reliable and robust and that is not subject to outstanding intellectual property claims.
Other risk mitigation steps to take include:
Lastly, if you have sufficient bargaining power and you are obtaining the software from a significant supplier, you could also ask the supplier to take on the risk of third party intellectual property claims through an indemnity.
This publication is necessarily brief and general in nature. You should seek professional advice before taking any action in relation to the matters dealt with in this publication.