Progress

Here's the fourth and final contribution in a series of four short pieces by the IPKat's friend Keith Braithwaite (read the prologues to pieces one, two and three for the background) on the delicate balance between proprietary and open source models for the development and adoption of computer software.


Progress

Prologue

Last time we looked at the impact on users of removing a low-level technology from an operating system. This time we examine the claim, sometimes made by advocates of Free and Open Source software (FOSS), that so little progress has been made in recent decades by proprietary development that there is nothing to be lost by avoiding patented technology.

Proprietary technology is a source of advances

The irony is that many FOSS software products are intended as alternatives to established commercial products. OpenOffice is intended to be an alternative to the Microsoft Office suite and other commercial productivity tools. The GIMP is intended to be an alternative to Adobe Photoshop and Inkscape to Adobe Illustrator. These programs are clearly inspired by the commercial products they might be used to replace. One could argue that the spreadsheet application within OpenOffice has inherited all the innovation that has been applied to spreadsheets since VisiCalc in 1979, Lotus 1-2-3 in 1983 and Microsoft Excel in 1985. Each had a history of innovation and enhancement; all were developed as closed-source programs by corporations. Several FOSS spreadsheets exist, though none is as feature-rich as the commercial closed-source tools they ape.

So much for user applications. The previous articles in this series looked at operating system features. Some in the FOSS community hold that, since there have been no significant innovations in operating systems since the late 1960s, proprietary operating system offerings present no advantage.

It is surprising how many of the features that we now take for granted in a modern operating system were available on machines predating, say, the 1970s. So-called “time-sharing”, the use of one computer to run multiple programs for multiple users, was developed in the 1950s and became available in commercial products in the mid 1960s. For the user (at least, a very small group of privileged users), systems with a mouse and an interactive graphical user interface were available in 1968. It can look as if all the features of a modern operating system were available, although perhaps not all on the same system at the same time, by 1970.

1970 is a key year because the development of Unix at AT&T began in 1969 and the product was released in 1971. Unix is the indirect ancestor of both commercial operating systems such as Solaris and Mac OS and the free Linux distributions. Although Linux does not share any code with the original, proprietary, Unix operating system it does aim to be conformant with the various standards that define a “Unix-like” operating system. If it were really true that there has been little innovation in recent decades we might expect, then, that contemporary OS’s, including Linux, would not have any major features not in Unix. Is this true?

Not really. Here’s some detail on three examples of innovation appearing in modern systems. Since it is true that a many of the OS features familiar to users were developed a while ago these newer features can be quite technical.

Pre-emptable Kernel code

Modern operating systems are typically separated into a “kernel” which manages the hardware resources of the machine and “userland” where other services and applications live. Applications access the disk drive, network and other system resources by executing code in the kernel. The actual hardware involved is controlled by a piece of code called a “driver”. In earlier systems the kernel code might itself choose to defer a request in order to service one with higher priority, but there was no way to make the kernel preempt a request once it was started. This approach leads to latency problems, where a request that is actually very quick to service (such as pulling some data from the network) seems to a take a relatively long time to complete because the network driver has to wait for another task running in the kernel to complete.

To avoid this problem the kernel can be made preemptible. In a preemptible kernel a request can be overridden. In our example when data arrives from the network the driver interrupts another request currently running in the kernel and moves that data into memory or on to disk, at which point the first task resumes. This greatly reduces the latency of activities, like network access, where the computer needs to respond to an event that will happen at some unknown time in the future but that can be dealt with very quickly.

Microsoft Windows NT was released in the mid 1990s with a preemptive kernel, a feature inherited by its descendants, XP, Vista and 7. Linux has featured a preemptive kernel since version 6.2 which was released in 2003

RAID

Disk drives are marvels of engineering, but are not perfect. They can suffer mechanical or electrical failures and data can be corrupted or lost. Since reading and writing to a disk involves physically moving a read head from one location over the disk to another there can also be delays in retrieving data. One approach to this problem is to build higher quality disks. This is expensive and offers diminishing returns. In 1987 an alternative was introduced, the Redundant Array of Inexpensive Disks, or “RAID”.

In a RAID system data is recorded twice, so that if a single copy has a fault the data is not lost: this is called “mirroring”. Data can also be “striped” across multiple disks, with the different parts of the data on different disks, so that reading successive parts of the data does not need any one disk to make many movements of the head.I Instead, data is simply read form the disk with the next stripe. Striping and mirroring are combined in various ways to give different combinations of speed and safety. Some RAID systems also include additional measures identify and correct corrupted data.

Working with a RAID array is much more complicated that working with a single disk. While there are hardware-based solutions, where a “RAID controller” manages the disks in the RAID array, modern operating systems can manage RAID themselves.

Microkernels

We saw before that the operating system kernel is responsible for managing system resources via drivers which talk to network connections, disk drives, graphics cards and other components.
The Linux kernel is a very traditional design and uses the so-called “monolithic” approach, where the drivers and other kernel components are all hidden behind a single interface. Facilities such as the file system that we discussed in the first article can vary by loading different drivers, but this is hidden from userland applications. Having a monolithic kernel has been a popular design choice since the 1960s and was used in the Microsoft Windows 95 family of operating systems. In the 1980s an alternative “microkernel” architecture was developed in which the kernel itself is pared down to the very barest minimum and facilities such as the file system are implemented as userland programs which user applications talk to (perhaps via the kernel, perhaps directly). This has the potential to make the operating system much more reliable. With a monolithic kernel a badly written driver or some other problem can crash the entire OS. With a microkernel the driver would crash and need to be restarted but the kernel itself and the other programs providing operating system services would continue.

At first this technology had very poor performance, but intensive research overcame that problem and microkernel architectures have been used in mobile telephone handsets.
Between the two extremes is the “hybrid kernel” approach, in which some operating system services are provided by the kernel itself and some by userland processes. Both MacOSX and Windows NT- derived OSs use this kind of approach.

Other features

Some of the operating system features discussed in previous articles also pass the “1970” test. For example, the power management features mentioned in the first article and the zero-copy IO mentioned in the previous article arose in the 1990s

Summary

It is true that a surprising amount of the computing experience we take for granted today was available to someone forty or fifty years ago. As hardware has become more capable, technology choices that were once only available on gigantic research systems are available to all. We can now buy netbook class machines for a couple of hundred pounds that provide the same kind of environment that Doug Englebart demonstrated to an amazed audience in 1968. This can lead to the erroneous conclusion that all the interesting work has been done, but this is not the case. Innovation continues, although often in ways that enhance the computer user's experience: it’s faster, smoother, more responsive, more reliable, without necessarily presenting a big new feature.

Series Summary

We’ve seen that, when a technology vendor decides to use a patented technology without taking a licence, it can be putting at risk features that users can come to rely upon. If the technology supporting these features has to be removed, or a less capable replacement used, the functionality of a device or system can be degraded. This applies to domestic end users and corporate IT departments. We’ve also seen that choosing not to use a technology because it is patented, either to avoid a licence fee or on principle, can rob users of the opportunity to take advantage of valuable advances. Some who advocate avoiding proprietary technology claim that little real progress has been made in some fundamental technology areas for so long that patented technologies do not in fact represent progress. We’ve seen that this is not the case.
The arguments around software patents are complex and show no sign of resolving themselves soon. Increasingly often, the courts have to intervene to assist the legally recognised owners of technology defend their property rights. The opponents of software patents are increasingly bold in both their argument against the principle and their willingness to test the practice of intellectual property in software.

Proprietary v open source software: more on removable features

Here's the third in a series of four short pieces by the IPKat's friend Keith Braithwaite (read the prologues to pieces one and two for the background) on the delicate balance between proprietary and open source models for the development and adoption of computer software.

More on Removable Features

Prologue

Last time we looked at the hidden downsides, for users, of spurning patented technology.
Now we return to the question of removing patented technology from existing products. This time we will look at a very low-level technology, buried deep inside the operating system, but which has a big impact on users’ experiences.

Despite its origins as a means of publishing scientific papers the web has become a rich visual medium. Almost every webpage has many graphical elements and graphics files tend to be large, particularly the high-resolution, rich colour images that we have become used to. Viewing this sort of content would be a much less satisfying experience without the application of two technologies from the proprietary world.

Zero-copy I/O

Many applications spend much of their time copying large chunks of data from one place in memory to another. For example, a web server delivering a page has to first retrieve the content from disk which involves copying it from a disk i/o buffer into the application’s memory space. The content is then copied into the buffer of a network socket to transmit it to the web browser. But doing that copies the content yet again to a network card buffer ready for serialisation on to the network itself.

An alternative is to copy the data into memory once and then pass around the system a “pointer” (or reference) to that data. The pointer is very small and requires much less effort to handle. Imagine the difference between sending a colleague a reference to a book in a note versus sending them the whole book. This is called (somewhat misleadingly) “Zero-Copy I/O”
The Apache 2 web server, for example, has a configuration option which means that when handling a request for a file requires no access to the data within a file – such as when delivering a file to a web browser as a download – Apache delivers the file contents without ever reading the file. But this is only possible if the operating system upon which Apache is running supports this feature.

The advantages can be significant. Sun Microsystems published a benchmark (showing measurements taken using ftp servers with a 1MB file) showing an improvement of 40% in the throughput and 20% less CPU utilization in servers that use Zero-Copy I/O. Removal of this functionality would make an impact on both users and operators of the server:

• The end user will perceive poor performance while using the resources of the server;
• The server owner will have to expend more to support the same number of users.

“Latency matters. Amazon found every 100ms of latency cost them 1% in sales. Google found an extra 0.5 seconds in search page generation time caused traffic to drop by 20% . A broker could lose $4 million in revenues per millisecond if his electronic trading platform is 5 milliseconds behind the competition.”

Data from IBM show how using a traditional approach instead of Zero-Copy I/O can almost triple the response time of an example application serving static files of various sizes . Such a slowdown could have a very serious impact on sales from a retail website – or drive away users to a faster competitor.

Even in your day-to-day work, you are probably benefiting from Zero-Copy I/O without being aware of it. Every time you request a large file – be it a photo, a software download, an audio track or a hospital x-ray – Zero-Copy I/O saves anything from seconds to minutes of your valuable time.

Zero-Copy I/O is becoming more widespread and the introduction of that technology into a range of products is being managed well. Let’s look at an older example of a key technology being mismanaged.

Image compression

Ever since the first NCSA Mosaic browser let webpages contain images, the Graphics Interchange Format (GIF) had been used as the standard encoding for simple pictures such as icons and page backgrounds. The authors of web servers and browsers thought little about this until 1994, when the owner of the intellectual property in the GIF standard, Compuserve, sought to collect royalties from companies incorporating that technology in their products. How could this have happened?

Computer manufacturer Sperry patented the Lempel-Ziv-Welch compression algorithm (LZW) in 1986. Unfortunately, LZW was published in a computer journal without reference to the fact that Sperry held a patent on it.

Not long after this Compuserve needed an efficient graphics representation for distributing images to their (pre-web) users and saw LZW as an ideal way to compress the graphics content of images. The resulting technology, GIF, was used widely by Compuserve users to share images. When the web arrived it seemed only natural to use GIF there, too. Sperry, merging with Burroughs to form Unisys, forgot that it owned the LZW patent until 1994. Unisys belatedly felt that it was obliged to assert its rights by demanding royalties from users of LZW – including the vendors of software that encoded or decoded GIF images, which included web server and browser makers.

Unisys quickly came to an agreement with Compuserve, letting it continue using LZW in the GIF format. Initially, both Compuserve and Unisys insisted that they only wanted to charge vendors of commercial software that employed the GIF algorithms. However, they soon had to retract this guideline because vendors started distributing the GIF support module as a “free add-on” to their commercial packages. Soon, only genuinely charitable organizations were able to avoid the payment of at least $0.10 per copy of any software that encoded GIFs.

Despite handing free licences to hundreds of non-profit organizations, schools, governments and so on, Unisys continued to generate only negative publicity. Anyone using a content management system or website authoring tool, or even an image editing application, was either deprived of the facility to use the web’s most popular image format and/or ran the risk of being found liable for infringing Unisys’s patent.

The worldwide patents on LZW expired in 2006. By then the GIF controversy had led directly to the formulation in 1995 of a new image encoding standard called Portable Network Graphics (PNG). However, PNG is still not fully established, largely due to the initial unwillingness of the leading browser vendors to invest in supporting it – even when it became an official standard of the WorldWide Web Consortium. Most webmasters continued to use GIFs, even though they were covered by patents, rather than lose readers.

Next article

My fourth and final article, which will wrap up the whole series with a summary, will look at the proposition that product designers don’t need to use proprietary technology because no real progress has been made in many areas for several decades. The conclusions may surprise you.

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?