Analysis: Embracing open source GPLv3 and avoiding hardware lock-in
It is almost a year since the Free Software Foundation (FSF) released the third version of its General Public License (GPL). Prior to the release there was a great deal of public consultation where several contentious issues were hammered out. The greatest of those was the Tivoisation clause.
“Tivoisation,” a term coined by Richard Stallman, founder of the FSF, is the use of hardware to prevent changes to the software running on a device. This was in response to TiVo and other manufacturers who use open source software in their devices but who then use encryption, digital signatures or other means to prevent their customers from making alterations. These manufacturers complied with the letter of the older GPL, but not its spirit.
What Stallman and the FSF were attempting to do was enforce the freedom that the GPL gave end users by limiting the controls manufacturers could place on them.
It was controversial because there are systems where security issues may be of greater importance than the freedom to make changes. Cases such as voting machines, medical instruments and safety-critical applications come to mind.
A – X of LinuxA AndroidB Broadcom and LiMoC Carrier Grade LinuxD Driving automotiveE Ericsson 3GF Free software embeddedG Google G1H How to migrate I IntelJ Jumping on boardL Luminary MicroM Mobile LinuxN Nokia does battleO Open Source engineeringP Power shiftQ QualcommR RTOS versus LinuxS StallmanT Tivo-isationU UK radio mappingV VirtualLogix VLXW 2 Watt green PCX Xilinx adds Linux
To address that concern, the final version limited this clause to consumer devices, thereby ensuring that those machines that need to be tamper-proof may be so and security remains robust. But for consumer device manufacturers, is this really an issue? Should you be worried about your end users changing, or even replacing entirely, the software on their devices if it doesn’t entail broader security issues? Or is there some benefit to making your devices “hackable” to users who want the freedom to customise their device and developers who want to help them?
As a device manufacturer you have limited engineering resources, time and budget. Development cycles in the consumer market tend to be very short, sometimes just a few months. Not getting your product out in time for Christmas or just a few weeks ahead of your rival could make all the difference between success and failure. Can making a hackable device help, or would it be a hindrance? Are you making customisation part of your product’s uniqueness?
Remember also that most consumers couldn’t care less what operating system is on their funky new phone, PDA or set-top box. What they do care about, however, is style and features. Who hasn’t changed their ring tone or the background image on their phone or loaded some new applications on their PDA? How about making their navigation systems sound like Yoda or Borat?
By being open with your design – at least from the software side – you can build an ecosystem around your device. Using a standard Linux distribution and open source tools makes it cost-effective for anyone interested in developing new applications or improving existing ones, not just the larger partners.
What this means is that your product can become more attractive not just to the hackers who want to play but to the wider consumer population. This can actually be a competitive advantage.
The ultimate benefit would be if someone has a bright idea for some new killer application and because your device is open and the tools are available that application is written for your device. Your closed source competitors will have to find the resources to compete whilst you are free to move on to your next project.
One concern may be that using open source software means that you have to change how you work. You may be used to working with tool vendors and prefer the safety net of having tested and supported software to work with. Venturing out into the open source world may seem risky. With a small development team you simply may not have the resources available to track the community and integrate the security and bug fixes that are released all the time.
This is where using a standard distribution, rather than shoehorning an in-house Linux kernel, is a benefit. It removes the integration and testing work by providing a stable platform. If the community can use the same source many potential conflicts can be avoided altogether. Being hackable does not mean you have to become a hacker.
Being hackable does not mean you have an increased support burden either. The FSF recognises within the GPLv3 that you should not have to support modified systems. This means broader security (for networks and other devices) is not an issue.
The only consideration is the possibility of providing some way to ‘restore’ the device should some customisation efforts go very wrong, but other than ensuring your original source is available there is no additional burden compared to closed source development.
The benefits of an open design can be so great that Tivoisation should not even be a consideration.
By Richard Danter, Wind River Linux Engineering Specialist
NB: On the FSF website, Stephen Fry introduces free software in a video, and reminds people of the 25th birthday of the GNU Project.
See also: Electronics Weekly’s Focus on Mobile Linux, a roundup of content related to the open source operating system shaped for mobile devices.