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.
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
www.out-law.com
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