Open source software allows businesses to use cutting edge code without licence fees. Sadly nothing comes for free, and a lot of scaremongering has followed its rise.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
But while open source does carry some risks for a business, risk analysis can reduce the fear, uncertainty and doubt.
There are some risks associated with using open source software that are heightened in comparison to proprietary software. Legal commentators often stress the risks of copyright infringement, spurred on perhaps by the highly visible Linux litigation in the US.
The dangers of copyright infringement, with its potentially dire financial consequences, should not be ignored. It is also true that the often huge number of contributors to open source code means there are a lot of potential claimants for an infringement suit.
Risk is subjective
This, combined with the fact that open source software tends to be supplied without any kind of indemnity, leaves users feeling understandably vulnerable. On critical applications, such as network operating systems, some feel this is a risk too far.
On the other hand, it is clear that this view is not shared by everyone. Any deployment of software should usually be preceded by an assessment of the total cost of ownership. The risk of infringement would be one further factor to consider when calculating how much the deployment would cost.
The risk can also be reduced by purchasing open source software from a supplier such as Red Hat for Linux, which provides indemnity protection against infringement suits.
Alternative insurance is also available. Further protection can be gained by ensuring that any open source deployment is easily substituted should an infringement suit necessitate it.
The increasing numbers of organisations in both public and private sectors using open source show that this risk is not considered to be as decisive as some might suggest. When it is balanced against the substantial cost savings in licence fees open source allows, this is understandable.
Another legal risk that is often cited is the lack of warranty protection with open source software. The position is more complex than it may first appear to be. Despite what the licences may say, English law does not always allow warranty protection to be excluded. Even though open source licences are (usually) stated to be provided warranty free, the law will imply certain warranties anyway.
Are warranties worth it?
It is worth considering here the extent to which a proprietary software supplier would provide certain warranties in any event. It would be extremely surprising, for example, for a proprietary software supplier to warrant that the software they are supplying will provide uninterrupted and error-free operation.
A customer should consider what protection they would expect from a warranty, and see if they could get it elsewhere. The lack of explicit warranty protection is therefore not as important as it may first seem - rather, it should be another factor that is put into the equation when considering open source against proprietary software.
Chief among concerns for those who develop software and rely on licensing income for their livelihood is the risk of the "infection" or "liberation" (depending on where you stand) of proprietary code through its incorporation with open source code.
The danger is that by incorporating code licensed under certain open source licences (such as the General Public Licence) into proprietary code, the entirety has to be released under the terms of the open source licence, and a crucial income stream could be lost.
Often, this is not apparent until the intellectual property of the developer is audited. Discovery of open source code in proprietary software intended for paid licensing has, in the past, caused the substantial devaluation of companies on the eve of their sale.
So how can this risk be minimised? The answer is education, education, education. All proprietary software developers should have an open source software policy in place. This policy should involve explaining to development staff why they should care about the differences between open source and public domain software.
As some licences are more dangerous to developers than others, it should stipulate the specific licences that code can and cannot be incorporated under. There should be a form of approval process for developers who want to use portions of code that are licensed under an open source licence.
A code library containing open source licensed code incorporated into proprietary code, together with the relevant licences should be developed.
No nasty surprises
For development projects that have proceeded without the benefit of an open source policy, an audit of the code should be undertaken where possible to minimise any nasty surprises. Ideally, such an audit should also be undertaken before releasing any proprietary software.
Open source software represents a tremendous business opportunity for customers and developers alike. The potential savings in royalty payments alone are substantial.
Although it is not without risk, these risks are manageable once they are properly understood. From a legal perspective, the first factor to consider will always be the particular open source licence that governs the proposed code to be used. In what can be a very complex area, specialist legal advice can enable your business to profit from using open source software.
James Duffett-Smith is an IT specialist at international law firm Pinsent Masons
Pinsent Masons is running free breakfast seminars in major UK cities on the legal issues surrounding open source software. Further details can be found online
Steps to open source safety
What users should do:
- Review software licences
- Undertake a holistic risk assessment in the context of the overall objectives of the software deployment
- Consider insurance or indemnity protection
What developers should do:
- Implement an open source policy
- Educate their development staff
- Build an approved code library
- Be clear which open source licences their staff can use