By Field Fisher Waterhouse, 31 August 2006 11:45
COMMENT
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
Comments
There are 6 comments. Join the discussion
1. Simon Hobson
Oh dear ! For someone claiming to be a legal professional this writer seems remarkably ignorant on the subject. After the third reading, it becomes obvious that the author is unclear who the article is addressed at - certainly the risks/issues differ depending on whether you are building systems for in-house use or for sale/licence to third parties.
Picking the piece apart :
"There are usually no contractual commitments of quality or fitness for purpose. "
Ever read a standard commercial software licence ? This is exactly one of the standard terms in just about every 'shrink wrap' licence I've ever read.
"The licensee will have to bear the risk of any errors in the code, ..."
Ditto.
"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."
Ditto !
In short, you pick up just about any off the shelf package and you will find clauses that basically absolve the vendor of any risks/liabilities whatsoever. Exactly the disclaimers that the author criticises OSS licences for
"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."
Ahh, at last, a statement that is accurate-ish !
Now we come to the reall biggie, the one that proves the author knows NOTHING about the licences he tallks about :
"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."
This simply is NOT true ! It's one of the 'myths' put about by certain anti-OSS people as part of their FUD campaign. Go read the common licences again, typically you can create a derived work from a GPL licenced program and you are NOT forced to distribute it. You can use it internally without any problem - it is only if you redistribute the program that the licence requires that your derived works are offered under the same terms.
Think about it, it makes sense and is designed to stop someone taking an OSS program, fiddling with it, and then selling it as a closed package.
BUT, depending on what you have done, you may still be able to distribute YOUR program as closed source. Typically this would be where you have written something that is used as part of a suite, but which is not itself inextricably linked with the original code. Your program may be a standalone piece of code (although it might not do anything useful without the rest of the suite) and it can be closed source - as long as you don't try and restrict use or distribution of the other OSS components in the suite.
A good example might be where a vendor builds an 'appliance' using (for example) Linux as it's core OS but with a proprietry program layered on top - just like the PVR sat under my telly. Even if the closed program can't run without dynamically linking to certain libraries etc, typically it is still OK to keep it closed AS LONG AS the vendor doesn't try to claim that the whole system is closed.
There are plenty of closed source packages that work with/rely upon OSS software - please stop spreading this innaccurate FUD.
All in all, whilst there are some real and useful pieces of information in the article, it's completely spoilt by the serious factual errors - of the sort we expect to see from the FUD departments of major closed source vendors.
2. Symon Chalk
All round a good article, but it does mention the oft-stated, and mistaken, assumption that commercial software provides some form of warranty. In fact, if you read all the details of an EULA, practically all commerical software, especially the off-the-shelf kind (i.e. Microsoft Office) explicitly denies fitness for purpose, etc. In reality the only software offered with any form of warranty regarding fitness-for-purpose tends to be vertical market applications.
3. Charles McCreary
"OSS licences contain very few (if any) of the warranties that might generally be included in proprietary software." Have you actually read any EULA's recently? I can't recall a single fitness for purpose warranty in any software, open source or not.
With respect to possible infringing code in open source code, I find that highly unlikely. SCO vs. the IBM and the rest of the world is having a hard time finding any.
4. Richard Steiner
A company who writes software that is found to include open source code with a mandatory redistribution clause (such as code which is covered by the GPL) is generally not required to reveal their proprietary source code.
This is a myth I've seen propogated on other web site, and it simply is not true.
Instead, it is enough to remove the GPLed code (or other FOSS code whose license is being violated) from the proprietary project -- the project is then not in violation of the FOSS license, and it can continue to be developed and restricted as the company sees fit.
Also, if a company creates proprietary software which incorporates GPLed code but only distributes that software inside the company, that company has no requirement to distribute the source outside the company.
The company is only obligated to make the source available to those who have access to the executable binaries; there is no legal obligation whatsoever to expose the proprietary portions of the code to anyone else.
With regard to the guarantees found in commercial/proprietary software versus open source software, I think you'll find that almost all software disclaims responsibility for the consequences of running that software.
You might find the Cybersource study comparting a Microsoft EULA to the GPL on the following web site to be interesting:
http://lwn.net/Articles/29830/
5. anonymous
This article is inaccurate, and needs a complete overhaul. The writer does not appear to have a good legal knowledge of OSS licenses.
6. anonymous
Can I suggest the author of this article reads the Open Source Definition?
ThIS definition actually FORBIDS many of the things he says "most open source licences require". Such as, for example "requiring any changes be made public". That's only if you then want to distribute the program - in effect that is the fee you pay the original writer for him letting you use your code in the product you are selling or giving away.
"Most open source licences allow the licensee to modify the program". Change that to ALL OSD-compatible licences.
"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". I've already said it above, but it bears repeating - as far as OSD-compliant licences go, this statement is a downright falsehood. The OSD FORBIDS this sort of behaviour.
Practical means of eliminating risk? IF you are using software and not selling or giving it away, then just make sure the licences governing the software you use are OSD-compliant. Then, as you are not "copying" the software as far as the licences are concerned, there's no need to give a monkeys about the licences. Just make sure no copies make their way OUT of your organisation without a rather more thorough legal check.
Cheers,
Wol