Tag Archives: Richard Stallman

Open wide, let me put this in you

Given that the UK Government is considering switching to open source formats and software, and that several municipalities (or entire government departments) within and without the EU have decided to ditch proprietary software in favour of FOSS (Free and Open Source Software) alternatives, it’s worth us having a look at the pros and cons of such a move, if only to better understand (or object to) the decisions being made at this level.

Firstly, a quick explanation of the terms are in order:

Open Source Software: See here for the official Open source Definition

Open source is a development model based upon the “four software freedoms” elucidated by Richard Stallman of the Free Software Foundation as: the freedom to run [the] software for any purpose; the freedom to study how the program works and change it to suit your needs; the freedom to redistribute the code; the freedom to distribute your modified software so others may benefit from your changes.
The free in Free Software refers to liberty, not price. In practice, this means that using software with an open source license gives developers, engineers and end-users the ability to share their ideas and make contributions (fix errors or bugs, add new features etc) that benefit anybody using said software. It also means that the code is available for constant review, giving rise to the argument that FOSS deals easily and promptly with, for example, security issues.

Proprietary Software:

Software licensed under the exclusive terms supplied by the copyright holder. Generally speaking, proprietary licenses give the right only to use the software under certain conditions, in practice meaning that one is restricted from modifying, sharing, studying, distributing or reverse engineering the code.
Only the provider of the software has access to the source code, and therefore only they can modify, release updates or add new functionality to the software.

Licensing:

It’s worth noting that both proprietary and open source (or free) licensing uses the same legal basis (usually copyrights) to construct agreements. Proprietary licensing (most often in the form of an End User License Agreement) will state precisely what you can and cannot do with your purchased license, whereas open source licenses can vary from completely free, i.e. no restrictions at all, to the requirement that published code must be released using the same or equivalent licensing.

So how would it benefit government departments?

1. Switching formats (for example from Microsoft’s proprietary .doc Word document format to the open standard .odt format) could mean that all government departments regardless of operating system or software in use will be able to read and write to the same target and expect the same results. Of course, I suspect this happens now with office documents, but is burdened by an EULA with an annual fee.
As the format has new features added, no additional cost is applied outside the manpower required to roll out the updates. This would also make it easier for the various departments to deploy a variety of operating systems depending on their needs without the burden of having to re-format documents for particular users.

2. Overall costs of deployment are reduced (not paying for licenses or new iterations of the software, for example). This is a disputed one, as a counter argument exists. The cost of retraining staff for using new software, and the cost of training or employment of new IT staff with a new system has been said to vacuum up any savings made by switching.
As it currently stands, much of the UK Government is still using versions of Windows and other related software created well over a decade ago, so I believe the retraining costs of switching would amount to much the same were they to update to more modern versions, with the added benefit of lower future spending.

3. Updates, bug fixes, plugins and tweaks etc can be created in-house without additional licensing or approval. Most IT departments, whether government or business, have employees who write and deploy software for front- or back-end offices. An easily understood example might be an intranet where employees have access to FAQs, forums, customer databases and the like. As has been my experience, certain parts of an intranet may make use of bespoke Internet Explorer (Microsoft’s default browser) features, such as ActiveX plugins. Only IE supports ActiveX, and only Microsoft decides whether a plugin is still useful or will be deprecated.
This is a problem because the choices are often either to use an outdated browser (not secure when used outside the intranet) or rewrite from scratch to whichever iteration they update to. This is a vicious circle, and would be ameliorated by using an open standard such as HTML5 to code the intranet and open source software to maintain legacy features (for example by using a browser’s plugin architecture or altering its code) while keeping up-to-date with regards to general internet security.

4. Writing your own software. Libraries and back-end services written for one open source program can often be used in other programs without express permission (depending on the license), lessening the burden of writing new ones from scratch.

What are the downsides to switching?

1. With regards to format-switching, Microsoft Office now supports open document formats, so only some brief training informing staff to save in .odt would be required. Switching entire platforms may require further training due to the variety of options available outside the proprietary software pool, however, given that various departments may be required to give training for new versions of proprietary OS deployments, I believe the costs are comparable.

2. Long term viability. An issue that comes up within the Open Source communities is what to do with a project when its creators or maintainers decide to no longer support the software. This could add to the overall costs if a department depends on some code that is no longer supported, as it may require a switch to an alternative or for the IT chaps to maintain it themselves.

3. Interoperability. An issue that plagues the modern world as a whole, really, but one that should concern a government considering deployment of FOSS. An example might be using Microsoft’s Exchange for email. Support for ActiveSync et al outside the Windows environment is choppy, if not appalling.

4. Regulations. There may be legal requirements upon software deployment, such as using particular encryption methods or in fact using software with specific licensing restrictions, exemptions, or requirements. I believe this would be the issue most necessary to adhere to, and the most difficult to overcome.

All cards on the table, I am an advocate of FOSS, so my opinions should be regarded accordingly.

That said, these are only a few of the pros and cons we should consider (the ones that came to mind when writing this post…). Can you think of any other issues governments could run into from a switch? Or perhaps you’ve noticed a benefit not noted above? How about a mistake I’ve made? Comments and suggestions very welcome through the comments link below.

Further reading:

List of Open Source Licenses
Legal Issues and Best Practices around procuring or deploying open source software