Open source software - a free lunch?

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.

What is open source?

In brief, open source software is software and its “human readable” source code made available by developers:

1. without charge (or with a minimal charge);
   
   
2. under very permissive licence terms (allowing copying, modification and redistribution of the software and its source code); and
   
   
3. generally on an “as is where is” basis.

However, conditions are often placed on redistribution of open source software, including requirements that any redistribution of the software and any modifications:

1. be on the same terms as the licence from the original developer; and
   
   
2. include the source code and documentation for the original software and the 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:

1. paid the relevant licence fee; and
   
   
2. agreed to much more restrictive licence terms.

What are the benefits?

The following key benefits can be identified in relation to open source software:

1. You've got the source code
   
   Access to the source code means that you can better understand how the software works and undertake “self-help” remedy of bugs or problems. You (or your development team) can also develop or modify the software to better suit your requirements.
   
   
2. Quality and security
   
   Given that the source code is made available to a number of developers, peer review by “many eyes” means that open source software can be more robust and secure than proprietary software. That said, this does not guarantee robustness or security, and lesser known open source software is unlikely to have been subject to the same scrutiny as well known open source software such as Linux.
   
   
3. You are not alone
   
   Most open source software has a “community” of developers that contribute to its development or improvement. This community, and the open exchange of ideas that it fosters, often reduces the need to “re-invent the wheel” when considering a particular development or problem in relation to an open source product.
   
   
4. Control the life of the software
   
   You have greater control over the usable life of open source software, as you are not necessarily reliant on the supplier continuing with a support and maintenance program. In effect, you are better able to avoid becoming a “captured customer”.
   
   
5. Up-front costs are low
   
   The lack of a significant up-front licence fee means that the up-front costs are low. If your business is growing fast, the ability to scale the use of the software, without incurring additional licence fees, means that ongoing costs can also be lower than proprietary software.

So what about those risks?

The following key risks can be identified in relation to open source software:

1. Your open source licence could be unilaterally changed or even terminated
   
   Your open source licence could be terminated unilaterally because it may not be an enforceable contract. When lawyers try and decide if an enforceable contract exists they generally look for the following key elements:
   
   
   1. an offer by one person to establish a contract;
      
      
   2. acceptance by another person of the establishment of the contract;
      
      
   3. consideration (comprising payment or a promise to do something);
      
      
   4. certainty of the subject matter of the contract and the parties to the contract; and
      
      
   5. a general intention to create a contract.
      
      

   Looking at open source licences, the key elements of “acceptance” and “consideration” may not be present as:

   1. most open source licences do not require the payment of a fee to the licensor;
      
      
   2. the promises made under some open source licences to distribute modifications on specified terms need only be kept if the licensee actually makes modifications and decides to distribute them (i.e., the customer decides whether or not the promise applies); and
      
      
   3. the licensee does not really have the opportunity to accept or reject the licence terms or make that acceptance known in a tangible way.
      
      

   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.

2. The software is supplied “as is where is”

   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).

3. No two open source licences are the same

   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.

4. Open source does not mean free

   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.

5. You don't get a third party IP indemnity

   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).

How do I mitigate those risks?

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:

1. documenting exactly what you want to do with the open source software;
   
   
2. getting the licence terms checked by your legal team or one of Bell Gully's IT law specialists and making sure they are consistent with your intended use;
   
   
3. checking out the supplier - you want to know that you are dealing with a reputable entity;
   
   
4. checking out the background to the open source software - are there reports of poor performance or security problems, or does it have a good reputation;
   
   
5. establishing whether there are any existing or threatened intellectual property claims in respect of the open source software; and
   
   
6. outlining a reasonable exit strategy, so that you are not excessively exposed if you have to stop using the open source software because of third party intellectual property claims, or termination or amendment of the licence.

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.

Jeremy Salmond