Latest News
|NewsletterCustomer demand is synonymous with technological innovation. Pushing the boundaries of product design, manufacturers continually look to do more – features, functionality and processing power – in less space for less money.
Fundamental to achieving these goals is the use of open source code. Readily available, cost-effective, and outside the lines of the normal software procurement process, open source code is at the nexus of all of today’s software development.
The widespread acceptance of open source continues to grow as an important alternative to commercial software. It is safe to say that open source is everywhere and is being used within your organisation whether or not you are aware of it. In fact, it makes up at least 30 per cent of the total lines of code in all software applications - both internally developed, and commercial software applications installed on your network.
Even if you implemented policies prohibiting its use in the development process, it is already there by virtue of the operating system you may be using or your word processing application. Often, open source makes up 50 per cent or more of an application’s total code base.
The prevalence of open source has thought-provoking implications for the electronics industry in that it introduces new risk from an intellectual property and security standpoint.
Commonly found throughout the electronics industry is embedded open source, which poses greater challenges by virtue of the licence that governs its use - the General Public Licence version 2.0. The GPLv2 is the legacy open source license that permeates a significant percentage of the embedded market.
The most recognisable embedded open source project is embedded Linux, which denotes the use of Linux OS in an embedded system such as you would find in an embedded computer system such as mobile phones, personal digital assistants, and media players.
It can also be found in machine control and industrial automation among other things. Embedded Linux is different from its cousin, Linux OS, in that it was made specifically for devices with smaller sized RAM and flash-memory based storage and is not appropriate for use with desktop computers. Embedded Linux exists on a large percentage of consumer devices and is covered by the GPLv2.
The Digital Rights Management (DRM) Drama
As of June 2007, the GPLv2 was upgraded to version 3, and is not compatible with its predecessor. This effectively puts a halt to the future innovation of retail items using code covered under the GPLv2 primarily due to the Digital Restrictions Mismanagement provisions.
DRM is most often associated with DVDs and other media. With DRM came laws that prohibited individuals from writing tools to bypass its restrictions such as the Digital Millennium Copyright Act and the European Union Copyright Directive. The GPLv3 provisions ignited a debate about whether or not these laws suppressed the intent and spirit of the GPL. GPLv3 was written with the intent to prevent what Eben Moglen, lawyer for the Free Software Foundation (instigators of the GPLv3) termed “Tivoization”.
TiVo, manufacturers of the eponymous TiVo digital recording system, built the software for their device using both the Linux kernel and GNU software - both licensed under the GPLv2, which requires distributors to make their source code available to anyone receiving the software. This would mean everyone purchasing the TiVo device. The intent of this GPLv2 provision was to allow anyone using software under the licence to modify it to suit their needs.
The Free Software Foundation believes that TiVo superseded the intent of the license by ensuring that their device would run programs with digital signatures that matched (and were authorised by) their organisation. TiVo did release its source code for modification, as outlined in the provisions of the GPLv2, modified software cannot run on their devices. Therein lies “Tivoization”.
Interestingly, Linus Torvalds, the father of the Linux kernel, has said he believes TiVo has a right to use digital signatures to limit what runs on their hardware as private digital signatures are important for software security. He has stated that he believes software licences, such as the GPLv2, should only relate to software, not on the hardware running it and if the software source code were released for anyone to modify for use on other hardware, he doesn’t see it as GPL violation.
According to Moglen, the FSF developed the GPLv3 with the intent of “prohibiting technical means of evasion of its rules, with the same clarity that it prohibits legal evasion of its rules.”
In his presentation at the 3rd International GPLv3 Conference, Moglen explained his stance by saying,“Let’s say I make a digital video recorder, let’s say I call it TiVo, and I sell it to you and I say; ‘There’s GPL’d software in here, here is the source code. The only thing is, if you modify this software inside my box I will cut your service off.’ That would be a straightforward violation of the GPL. You would be adding a condition to the license and you couldn’t do it.
We are saying that the licence should prohibit technical means of evasion of its rules, with the same clarity that it prohibits legal evasion of its rules, that’s all.”
Although it is best to seek qualified legal advice for the proper interpretation of the GPL and how it affects individual business practices, it is safe to assume that the GPLv3 is asking that manufacturers using embedded open source covered under the GPL to release all of their source code and refrain from preventing modification to the hardware that surrounds it. The Google Android project is a perfect example of this model in action.
Unless companies are willing and able to allow open modification of their products, they may want to search for viable alternatives to any embedded open source covered by the GPL.
Where Do We Go From Here?
The issues pertaining to the GPL matter greatly to organisations shipping products containing the GPL in either of its iterations.
Manufacturers using electronic components are not always aware that they contain embedded open source and thus, would not be aware of the license provisions governing the undocumented code. Without a clear understanding of what open source is being used and where it resides, manufacturers leave themselves open to risk.
The growing complexity of multi-source development environments necessitates transparency in the application development lifecycle. Successful open source management calls for a robust and enforceable software risk management process based on the following best practices:
Policy – setting development guidelines for the procurement and use of open source and third party components
Education – Ensuring that the development teams understand the importance of and adhere to the open source use policy
Audit and analysis – Keeping an ongoing inventory of open source and third party components, reporting on their use, detecting known vulnerabilities and alerting the organisation to legal liabilities
Among the necessary steps for implementing a software risk management policy, code audits are fundamental to its overall success. Thorough code audits enable security and engineering teams to ensure that open source and other third-party components meet the same rigorous security and quality assurance thresholds required of internally developed, proprietary code.
They also alert the organisation to the existence of undocumented code, what license governs its use and whether or not it contains a known vulnerability.
All organisations should ensure that they can confidently answer the following questions:
What open source and third party software components are we using?
Where are we using them?
Are they secure? Do they have known vulnerabilities?
What rights do we have to use them, and are we in compliance with any obligations regarding their use?
Enacting best practices for open source use empowers organisations to use it to their best advantage as a solution for driving continual innovation and growth and prevent open source licensing and security issues.
Mark Tolliver is CEO of Palamida