To print: Click here or Select File and then Print from your browser's menu

This story was printed from silicon.com, located at http://www.silicon.com/

Story URL: http://software.silicon.com/applications/0,39024653,39161867,00.htm

Open source - is it a risk for your business?
Analysis: How to make sure it does more good than ill

By Field Fisher Waterhouse

Published: Thursday 31 August 2006

Although there are many benefits to using open source software, Paul Barton, technology partner at law firm Field Fisher Waterhouse LLP explains the legal issues end users must be aware of to avoid trouble.

For many organisations, from SMEs to government departments, the use of open source software (or OSS) is becoming increasingly popular. Lower costs, increased flexibility and, in many cases, better security make it an attractive option for IT departments.

But what are the legal obligations associated with its use? Many end users are unaware of these issues.

There are a number of different licences associated with OSS which vary in terms of what they allow a licensee to do. There is no substitute for a detailed analysis of the specific terms of the OSS licence being used and the means by which any derivative software is exploited.

Pros and cons of using open source

One of the key benefits of open source software is the ability to access source code and modify, adapt and enhance the software to meet the licensee's particular needs.

With OSS, costs and development time are often greatly reduced in the short-term, given the extensive stock of existing code available for developers. Most open source licences allow the licensee to modify the program, enabling a considerable degree of tailoring. Support and maintenance is also often easier since the source code is freely available.

However, most forms of OSS licences are structured in favour of the contributor rather than the licensee. There are usually no contractual commitments of quality or fitness for purpose. The licensee will have to bear the risk of any errors in the code, and since there are often many contributors at work, there are numerous opportunities for infringing code to be introduced. This may, in some cases, outweigh the time and cost advantages of using open source.

OSS licences contain very few (if any) of the warranties that might generally be included in proprietary software. For example, those relating to the suitability of the software for a particular use, meeting a particular specification or being developed to a particular standard of care.

Crucially, the licence includes no indemnity protection against claims by third parties for intellectual property rights (IPR) infringement, so the user of the software is not automatically protected from such legal actions.

One significant limitation is that once the OSS has been modified, the licensee is usually obliged to put these modifications back into the open source community. If a new piece of software is deemed to be derived from, combined with or a modified version of an open source application, it may be subject to the terms of the open source licence. In return for open access to the software, most licences require licensees to provide access to derivative works for others to use, modify and redistribute (often referred to as the 'viral' effect). Failure to do so contravenes the OSS' licence. If the OSS user does not license his own code under the terms of the open source licence, he has no right to use the software.

The combining of open source and proprietary products can carry significant commercial risks. For those buying software products, this may apply even when only part of a software product is open source.

One tricky situation is 'contaminating' software by combining it with open source code. This means a company may be obliged to reveal the code for the entire package, thus giving competitors access to its own proprietary and confidential source code.

There is a great deal of debate as to whether, in such situations, the whole software package must be disclosed or whether it should be just the parts that interact with the open source code. This is an area of legal uncertainty and consequently it is important to be aware that contaminating products with open source code carries with it certain risks.

This makes it difficult for businesses to use OSS as a platform for onward licensing, given that much of the 'traditional' commercial value may have to be surrendered. The terms of the licences vary, and the individual licence must be analysed in detail to determine the extent of the viral effect and what must, in turn be licensed back to the open source community.

Practical steps in minimising risk

There is no simple solution to open source issues, reflecting the fact that there are a number of different OSS licences which have largely been untested in the courts. However any business using open source products should consider taking the following steps:

Identify the commercial value of open source

• For example, does the OSS code form a core or peripheral part of your software?

Consider your business model

• Does your business generate its revenue primarily from software licensing? If this is the case, the potential loss of licensing revenues resulting from having to disclose the source code as a condition of using the OSS may be significant.
  
  

• Are consulting or support services the main source of revenue, with software provided on a royalty-free basis or already priced in? If this is the case, being obliged to release the source code to any of your software which incorporates OSS may not result in a substantial loss of revenue.

Manage the risks

• Conduct a high-level technical and commercial assessment of both the contribution that OSS makes to your revenues and the technical need for open source (in some cases, the reliability and robustness of open source software may not be sufficient, while in others OSS may provide a higher level of resilience than proprietary software).
  
  

• Formulate an internal policy for software developers and make them aware of the legal and commercial risks of using OSS.
  
  

• Ensure there is a process of tracking and recording the use of open source software to ensure licensing obligations of an individual piece of OSS are met. For instance, consider using use automated tools such as Black Duck or Palamida to track the use of your software. This may be particularly useful in valuing the contribution OSS makes to certain proprietary software or as part of the due diligence process in a corporate acquisition.
  
  
• Consider obtaining insurance (increasingly available through specialist brokers) against liability for infringement of third party IPR.

Paul Barton is a partner in the technology law group at Field Fisher Waterhouse LLP