Content

Open source. Love it or hate it, but can you trust it?

Open source software (OSS) is firmly entrenched in the infrastructure of the Internet, and is now making inroads into the security market too. But although the darling of techies everywhere, OSS has its doubters. In particular, many corporate managers have concerns about support, accountability, and longevity.

There are many arguments and counter-arguments. Too often, debate turns into a sour wrangle, or is lead from the start by organisations with vested interests in the conclusion – Microsoft UK was the target of many OSS jibes after its Windows vs. Linux seminars, pitched as an "open and honest technology discussion" about "the facts on Linux and Open Source Software", but which mysteriously lacked any Linux representation on the panel.

And so what? Note to the open source world: competitors don't play by your rules. Microsoft is competing and the OSS crowd had better get used to it. You don't step into the ring with a heavyweight and expect love-taps.

The fact remains that strong questions are being asked (frequently in camera) of the open source world, which is having to grow up (in the competitive sense) and answer them before corporate customers will consider trusting their core infrastructure to software beset by so much fear, uncertainty and doubt.

Some of the questions I hear most frequently are discussed below. In most cases there is no clear answer: open source software projects are many and varied, and how far one can go to reassure users is not indicative of the industry as a whole.

And to be fair, it should be noted that many of these questions could (and should!) equally well be levelled at proprietary software vendors who, lacking the clarity of open source development, may not be able to prove their own case either.

Can you trust the code?

OSS proponents argue that having source code available is a good thing, as it enables vulnerabilities to be found and corrected quickly. They argue that for customers, having access to the source also allows independent audits, and in-house patching if necessary. This is true, but of course black-hats also have access to the source, and some of them are extremely good programmers. Are you willing to bet that your best coder is better than the best black-hat? More to the point, have you tasked your best coder with doing an audit of your open source software? Shouldn't he be generating software for your company?

These concerns are perfectly valid, and the OSS industry needs to have ready answers for them. Microsoft staff, for example, have told me that no security patches have ever resulted from the company's shared source programme. But Phil Dunkelberger, CEO of encryption firm PGP, which has roots firmly in the OSS world, told SC the company regularly receives valuable feedback from customers reviewing the PGP code, and has even caught potential vulnerabilities before they could be exploited. Obviously your mileage will vary, but clearly some are benefiting from the process.

If anyone can contribute, anyone can plant a Trojan

One myth of OSS development is that anyone can get code into a project. It is absolutely true that anyone can contribute code, and nearly all projects welcome ideas, patches or fixes from users. But at the top of every project is a maintainer, a coordinator (or small number of the same) whose job it is to vet each contribution, weigh its merits, and check it for errors or outright abuse. Only if the patch passes muster will it be included into the program's source, and even then it will be scrutinised by many other developers, seeking to establish what it fixed and if deploying it will have an impact on their environment.

So yes: anyone can send Trojan code to a project. The likelihood of it making it into live version is vanishingly small, unlike the many documented backdoors in commercial software, which lacks the public scrutiny. Transparency keeps OSS honest.

Who is accountable?

In general, big open source projects tend to have excellent track records for patching bugs. And with programmers from firms like IBM, HP, Novell, Oracle, Computer Associates and many more on the job, fixes tend to reach customers quickly. But "quickly" does not imply "consistently", and without an ironclad SLA backing up the promises of support, this is just not good enough for many corporate users.

For many big projects, such as the Apache web server, databases like MySQL and PostgreSQL, or the sendmail email server, you can expect the same levels of attention and support as any commercial package, and many large OSS systems do in fact have non-free versions which offer service and support by the supplier.

So far so good, but a key strength of open source programming could also be a weakness here. "Don't reinvent the wheel", is the mantra, and projects are built by reusing a myriad of components sourced from other projects. No one writes their own graphic interface code: they just reuse one of several available toolkits. Networking code? Process management? Data layer? Authentication? You can build a complete new project with a bare minimum of work, just gluing the wealth of available resources together. But can you guarantee support for all of those contributed pieces?

The answer is simple: no, you cannot. But you can turn to a distribution vendor, like Red Hat or Novell, and rely on them to support all the components. And in reality, broken components do get fixed very fast, even major components. When the community had a gripe with the license wrangles at the X11 controlling body XFree86 (X11 was the graphics subsystem used by most Linux distributions), the community promptly "forked" development, created their own version – XOrg – which has now supplanted XFree86 on most distributions, and supported by the distribution vendors.

What about patent and intellectual property (IP) issues?

No one expected SCO, which had followed a complicated path along which it was a Unix vendor, Linux distribution vendor, and Unix vendor again at various stages, to start suing everyone in sight. First IBM, which SCO alleged had stolen Unix code and inserted it into Linux, then some customers, which it claimed were violating IP by using Linux. Lawsuits with Novell and Red Hat followed, and the cases are still rumbling on.

Few people believe SCO has any hope of winning these cases. One (against customer Daimler-Chrysler) has been dismissed already, and several are on hold. But setting aside the conspiracy theories about why the cases were brought at all, there is a very real concern that OSS projects may in fact be found to violate IP or patents, in the current cases or others, which may skewer OSS development.

With the exception of players the size of IBM, OSS companies do not have patent portfolios large enough to cross-license around the problem, as it traditional in the proprietary software space. And even those that do have shown little desire to donate their patent assets to the OSS world, no matter how vocally they are supporting it.

In most cases, the development community could work around the problem. The infamous GIF patent led to the development of the arguably superior PNG image format, which also has no strings attached. Questions about MP3 patents have been raised, with at least two results: some distributions (including Red Hat) have removed support for the audio format from their base systems, and the community promptly shifted to Ogg Vorbis, which is free and (some argue) a better codec anyway.

Will the developers always be able to move so nimbly? With patents being granted on processes and algorithms, what if an open source database project was judged to be infringe in some fundamental way? That could really hurt, and the people it would hurt most would be users.

Many observers expect commercial software companies, losing ground on many fronts to OSS competitors, to fall back to a patent fight to crush the opposition. The legal groundwork has already been laid: the US government is openly supportive of self-serving industry objectives. We have patents on mathematical processes, copyright extensions, anti-reverse engineering legislation, bills supporting the music industry in its battle against piracy at the unfortunate expense of fair use rights, and many other examples.

Some progress is being made. A German court recently found that the GPL – the license underpinning the majority of open source software – to be enforceable and valid, a landmark precedent. There is an enormous amount of confusion about the GPL. It is accused of being "viral", of requiring that users of "GPLed" code immediately cede their own software to the community, or of being impossible to enforce.

Most arguments are based around a basic misconception: that the GPL is a contract governing usage. It is not: it is a copyright license, which operates under entirely different rules. But misconceptions aside, there certainly are rules, and if you are using GPL software in your organisation you would be wise to familiarise yourself with them.

It is not uncommon for the OSS community to be dismissive of the perceived risks and the questions raised, especially when they are raised by the likes of historic foes such as SCO or Microsoft. But corporate users cannot afford the same laissez faire, and like it or not the questions do need to be answered.

Today, for the most part, the open source community has demonstrated its ability to deliver and support high-quality software, and is standing firm in the face of legal challenges. But what really matters is the user, both as a buyer and member of the community. Are you swayed enough by the evidence to bet critical security infrastructure on open source software? Are the questions causing sufficient uncertainty to give you pause? Or are the counter-arguments, and the possibilities of unanswered questions, simply too risky to contemplate such a move?

If you have strong feelings about open source, let us know. Write to us at [email protected]

 

 

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.