O̶p̶e̶n̶ ̶S̶o̶u̶r̶c̶e̶ Software Policies

If you make decisions regarding software procurement in your institution or business, I’d highly recommend you read this article from Opensource.com. In it, Gunnar Hellekson of Red Hat shows that an “open source software policy” can be easily re-written to apply to all software, in a lot of cases by simple removing the phrase “open source”.

There’s always been a lot of FUD surrounding open source software, often produced by the marketing teams of its competitors. Taking the USA’s IRS open source policy as an example, Hellekson, rather than trying to debunk or gloss over the potential risks associated with adopting open source, shows that these risks apply to proprietary software in exactly the same way.

I’ll just take one of his examples from the document mentioned above:

Open source software, while it can be useful in many instances and appear to be cost effective, may present a security risk because open source developers don’t typically follow security best practices when developing their software.

It’s laughable to think that this should be exclusive to open source software. Assuming that it’s true the open source developers don’t typically follow the best security practices (Hellekson argues it’s not, as would I), the licence applied to a piece of software make no difference to the security practice of its developers.

If your developer isn’t security conscious, the fact that no-one outside the company can read the source code isn’t going to change that. When procuring any software, you should always be prepared to mitigate the risk that the software’s not secure.

I was going to finish this post by giving the UK Government’s open source guidelines the same treatment that Hellekson gave to the IRS’s, but it would be unwarranted. Reading though the guidelines, they serve to educate the reader that open source and proprietary software should be treated as one and the same when assessing systems. A flaky open source system shouldn’t be chosen over a robust and secure proprietary system, nor should a robust and secure proprietary system be chosen over a robust and secure open source system purely on the basis of the licence.

While it’s easy to see that the proprietary or open source licence applied to a solution shouldn’t affect whether or not you choose it, at OSS Watch we know it can be hard to assess open source solutions on a level playing field with proprietary ones. Proprietary software is often presented as a single package for you to assess, while an open source solution may consist of several parts from different commercial and community sources. If you’d like help assessing software solutions in an unbiased way, send us an email to info@oss-watch.ac.uk.