Removable Features of Operating Systems

The IPKat is no expert when it comes to the software industry but, like many IP enthusiasts, he tries to keep up with the major issues and thought-trends as and when they crop up. One of the issues he has pondered about from time to time is the sometimes hostile, sometimes constructive tensions that exist between the business models that drive proprietary software and open source, as well as the continuing dialogue between the supporters of each. Bearing this in mind, the Kat is pleased to be running, over the next few weeks and starting today, a series of four short pieces by his friend Keith Braithwaite, which he hopes will do two things. One is to seek to pinpoint the most significant issues as viewed from the industry side rather than from that of the academics and lawyers in whose company this Kat is most comfortable. The other is to place these issues within some sort of temporal continuum where that is possible. And here's the first of them:

Removable Features of Operating Systems

Prologue

It is long established that intellectual property law applies to computer software. Source code written by programmers is subject to copyright and, where programmers are employees, the copyright is almost always assigned to their employer. The processes and techniques embodied in that source code may be further protected by patents. Individual programmers or, as is more common these days, teams of programmers invent technical solutions to problems, and those solutions may be protected by patents. Again, a patent will usually be assigned to the employer, if any, of the inventor, but sometimes to some other organization.

The fact that this is possible is a source of controversy. The Free and Open Source Software community embraces strong copyright protection of programs—that is how Open Source (OS) licences gain their legitimacy and strength—but they have set their faces against patent protection.

The field is complex and fraught. In some cases it is not clear even from the statements of any given patent office whether it even grants software patents or recognises the possibility of patenting an invention realised as software. Various precedents have been set for the patent-eligibility of software, and various policies expounded, which differ between jurisdictions.

Notwithstanding all this confusion, substantial portfolios of software patents exist. All major (and a great many minor) software vendors have a lengthy list of patents and often agree to cross-license items from each other’s portfolios. Other vendors and even their customers can find themselves in court for infringing patents.

The question of whether software patents are possible, valid or desirable is often discussed in lofty, abstract terms. However, the actions that arise through IP infringement and attempts to avoid it in software development can have very concrete outcomes for the users of software systems. This series of four posts explores some aspects of that impact.

First, we examine the impact of removing a feature from software. In many cases where patent infringement is claimed this is the “obvious” course of action for the infringer but as we shall see, it is not necessarily the best option from the user’s point of view.

What is a removable feature?

The operating systems of computers and intelligent devices (eg mobile phones, set-top boxes, satellite navigation systems and even dishwashers) are complex pieces of software. Yet the end user is often hardly aware that they exist—until something goes wrong.

Functions of the operating system include the management of system resources, such as memory, and storage, providing graphical displays, handling input devices and networks and any other generic features of the system, which may be used by every application and not specifically for any particular one.

Because of their inherent complexity, modern operating systems are highly modular. Particular modules can be included or excluded as required (for example, support for a particular model of printer or DVD drive).

Vendors facing patent infringement claims sometimes react by removing the offending feature or replacing it with a near equivalent that is unencumbered by IPR. In the case of OS software, in theory any user of the software can remove a patented feature and recompile the software. In practice there are considerable obstacles to doing that.

The operation of removing a patented feature requires considerable expertise, comprehensive and accurate documentation, potentially a lot of time and the appropriate software tools. Even if that can be arranged it may be that, without the patented feature, the software is next to useless.

Software users do not escape liability to pay damages for past infringements simply because they no longer use the infringing technology and, if any other patents cover its remaining features, the act of recompiling the code without the original feature may cause further infringement.

Intellectual property and removable features

So, removing features doesn’t necessarily avoid liability. It can also be disastrous for the user. Imagine you've bought a new flat-screen TV with a memory-card slot. Eager to display your digital photos as an instant slide show, you insert a card from your camera. But instead of a slide show, all you see is an error message! Your TV helpfully offers to repair your card. That doesn’t help, so you move the card to your PC to see what might be the problem. You discover that all your carefully applied captions have been replaced with meaningless filenames. What has happened?

This can easily happen if your memory card happens to use a FAT file system which dates back to pre-Windows MS-DOS days, to organise its storage, but the manufacturer of your TV has chosen not to take a license to the patented “long filenames” feature for FAT. In February 2009 it emerged that the Linux kernel (which, in this example, we imagine is the operating system on your TV) infringed a number of Microsoft patents. One of these concerned the way in which FAT can be used to support long filenames while maintaining the short filenames for older version of the operating system.

Satellite navigation seller TomTom agreed to remove exactly this infringing technology from its devices. This implied a change to the Linux kernel to avoid infringement. The Linux community, ever keen to demonstrate the ability of OS projects to “code around” problems like this, set to work to replace the offending module. The new module is designed to support short (“8.3”) filenames or long, but not both at the same time. Setting aside the question of whether this change in fact addresses the patent infringement, this change potentially renders the resulting file system incompatible with older software that recognises only short names or newer software written to use the patented functionality. So the new, non-infringing system does not have exactly the same functionality as the infringing version.

There are many other examples of technology that could turn out to have IP issues at any time, if their developers have not been careful, conscientious or fortunate enough not to have got caught. Because they relate not to “what” a system does, but to “how” it does it, they can be invisible to users. Let’s take a couple of examples and see what impact any potential IP issues with them might have.

Hibernation

When you shut down your PC or laptop, Windows lets you choose between a complete shutdown, hibernation or sleep. From the user’s point of view, the main difference between them is the speed with which the machine will start up again.

Linux distributors are in no doubt about the value of the hibernation feature to users. Some have begun to support at least the equivalent of hibernation―but getting that to work reliably is probably still beyond the capability of the average user. Even when it works, users may find that their wireless network is inactive after resuming after suspension. This lack of reliability is thought to be at least partly due to device drivers developed without the support of the relevant hardware manufacturers. This is a problem that has been solved very well by the proprietary operating systems, but those solutions have been rejected by the Linux developers.

Power management

Because of the importance of extending battery life, notebook and laptop computers have been designed for many years with power-saving hardware features. The processor can be slowed when it doesn’t have a lot to do, while unused parts of the system can be turned off. A standard (the Advanced Configuration and Power Interface specification–ACPI) was released in 1996 to provide operating systems with full control over the hardware to do this.

Linux distributions have been slow to take advantage of hardware power management features, in particular ACPI. This may be connected with the fact that the specification is complex and not easy to implement. Yet it is clear that there is a great need for it. According to some calculations, Linux-related carbon emissions currently total around five million tons annually–0.1% of the estimated amount of carbon added to the atmosphere each year by human activities.

In response to this need, the number of Linux-based “green” initiatives is growing rapidly. But optimistic press announcements cannot disguise the fact that there is still a long way to go in improving the integration between hardware, software and network management. For example, a Network World investigation in mid-2008 revealed that neither Red Hat nor SUSE distributions were able to exploit the ACPI features of the servers tested.

When it comes to saving the planet, should the potential cost of IP licences be allowed to stand in the way of progress?