The open source software movement has received a lot of press coverage in recent years. A result of this is many people associating the term "open" with open source software. This popular definition of "openness" is incomplete. Openness affects many aspects of computing besides freedom to view and modify source code. Shrewd proprietary computer companies have been able to take advantage of popular misconceptions about openness, masking their products in partial degrees of openness, then applying the "open" label. We should understand the different forms of openness and how they apply to the many facets of computers, software, systems, and even warranties and service agreements.
An important concept to keep in mind when thinking about openness is that open doesn't always mean transparent (as in having access to source code, hardware specs or other internal information). Prime examples of this are APIs, which provide standard (that is, open) programmatic interfaces to software libraries or applications. Software library developers may choose not to expose their source code; as long as such proprietary libraries use APIs conforming to standards, then developers coding to those libraries can freely port software between different platforms. The APIs are open because their definitions are freely available and under the control of standards organizations, despite their proprietary implementations. Some argue that standards organizations are inherently political, with restricted membership, and thus the standards they issue not truly open. This may be true to some extent, but standards are, to a fairly large degree, a collaborative process. If an industry-standard API is poorly designed, for whatever reason, then developers will tend not to use it and it will fall out of use if not improved.
An open component, whether software or hardware, can be proprietary due to licensing. The BSD license allows people to take open source code licensed under BSD, modify it, then sell only the binaries without having to release the modifications. This is also proprietary. Two main dynamics are present: licensing (the terms under which you may produce and use a product) and transparency (whether developers and users have access to source code, schematics, or other internal documentation).
Issues of openness affect computer systems and their usage in several areas, as Figure 1 illustrates. You must consider all components; licensing and transparency touch every aspect of hardware, software, systems, and service.
The most important attribute of any computer system component is licensing. Licensing controls who can produce a component, who can use it, how, when, and who can modify it, and often the terms of sale. This is why the outer-most circle in Figure 1 represents licensing; all other aspects are subservient. The GPL and BSD license are the two best known open source software licenses, but more exist, many of them derivatives or specializations of GPL and BSD. A detailed discussion of licensing is beyond the scope of this article, but suffice to say licensing defines the rules for developing and using software.
Licensing also controls the usage of patented components. Novell's new partnership with Microsoft came about, in part, as a result of Novell using lots of software developed with Mono in its SuSE Linux distribution. Mono is open source technology that emulates Microsoft's .NET architecture. Even though Mono was developed outside of Microsoft, the fact that it functions the same as .NET may expose it to legal action from Microsoft. Microsoft has registered many patents covering various aspects of .NET. Terms of the Novell partnership protect Novell and its development partners from such problems, but at a price. Novell loses a certain amount of independence now that it has tied its products so closely to Microsoft (a clever move by Microsoft). This situation illustrates how licensing controls even patents.
Proliferation of new licenses, especially open source licenses, requires software and system developers to maintain a detailed awareness of licensing terms for all components used in their products. Licensing issues have always been with us, but today's environment of increased openness and complex licensing bring them to the forefront and require greater attention.
In the not too distant past, users purchased their systems and components mostly from the same manufacturer. The manufacturers had complete control over the systems, including maintenance and upgrades (with some exceptions). Today, mixing and matching components is the norm and the sales distribution channels complex. These issues are not only for managers and stakeholders to consider; software and hardware developers have to understand the licensing and transparency of components they use to develop systems, both to protect themselves legally and to ensure their systems can continue to use complementary technology within the ecosystem.
Openness greatly affects computer hardware. The personal computer industry, specifically the Intel/AMD segment, has benefited enormously from various hardware standards. Examples include the PCI bus, IDE and SCSI interfaces, USB and FireWire, and AGP. Though most of these technologies require royalty payment to their creators, they are nonetheless open, because their specifications are publicly available; they must conform to certain physical and performance parameters. It is no accident that Apple Computer, a manufacturer of proprietary hardware, has less than a 10 percent share of the personal computer market at the time of this writing, while the rest of the consumer market belongs to numerous vendors building systems conforming to the PC standard. Open hardware standards in the PC segment of the industry have allowed many manufacturers to participate in the market and consumers have benefited from increased choice and availability of components.
The PC industry still suffers from manufacturers using proprietary features to the detriment of customers. This occurs in several areas:
Computer makers sometimes use hardware components not conforming to standard form factors. This requires users to purchase such components only from the manufacturer, usually at a much higher price than equivalent, standards-compliant versions.
Photo 1 shows a floppy drive from a personal computer, made by one of the large manufacturers. Notice the elliptical eject button. This button will only fit into a case made by the manufacturer. Thus, the drive can only be replaced with one purchased from the manufacturer. Although this is a simple example, it illustrates the concept of proprietary form factor. Personal computer power supplies are perhaps the component most often subject to this treatment.
Some computer manufacturers produce hardware that mostly, but doesn't completely, adhere to standards. Apple uses many industry standard hardware components in its Macs, but to retain control of its product, Apple uses its own style of firmware to boot and control the computers. Likewise, Mac OS X incorporates many key components from open source projects, yet is a proprietary product. This affects consumers.
Consider the AGP video cards used in many Apple computers. If you want to upgrade the AGP video card in your Mac, you must buy a special one created for the Mac. The purchase price of an AGP card made to the Apple AGP specification is much higher than one made for industry-standard personal computers, even though the cards may have identical specifications and may come from the same manufacturer. The reason for this is Mac systems require video cards with a special PROM. This is a classic form of proprietary implementation; it effectively protects the manufacturer from competition and insures higher profit margins.
Another common limitation on a system's degree of openness is the ability to upgrade components. Some personal computers come with video controllers built into the system motherboard. Usually there is a motherboard jumper or BIOS parameter which bypasses the built-in video controller and enables the user to install a new video card into the system. Sometimes these computers lack the jumper or BIOS setting, leaving the user stuck with the built-in video controller. The only way to upgrade the video controller is to purchase a new computer.
Serviceability is an often overlooked area of openness. Perhaps the best example of this is the CMOS battery in laptop computers: most computers use a small, round battery, similar to those found in wrist watches, to provide a trickle charge to the system BIOS when the computer is turned off. Eventually, these batteries go bad and need replacement. Replacing the CMOS battery on most laptops is a major task, often requiring complete disassembly.
This is a form of openness, in the literal sense of the word, but one worth considering. When you consider how most computer makers void the warranty of systems opened by users, this becomes a cause for concern. You may think that most CMOS batteries go bad way past the warranty period, so this isn't usually a problem. This is true most, but not all of the time. New computers sometimes ship with CMOS batteries that have been sitting in a warehouse several years. Some computer manufacturers make it easy to get at and replace the CMOS battery. IBM ThinkPads are the easiest laptop computers to replace the CMOS battery. Photo 2 shows the location of the CMOS battery on an IBM ThinkPad 600 series laptop.
This particular example is interesting, because it illustrates several aspects of openness applying to one component. First, the battery is very easy to remove; this makes it open from a serviceability standpoint. Second, the battery has a plastic sheath which holds the two lead wires in place; in this regard the component is closed, because few people are capable of or will take the trouble to make their own. Third, the battery itself is an industry standard CR2025, the same battery found in many wrist watches; this aspect of the component is open. The latter is most important--by choosing a standard battery IBM has all but assured a plentiful aftermarket supply of these special batteries. Some other laptops use proprietary CMOS batteries, only available from the manufacturer (and usually very difficult and a lot more expensive to replace).
Serviceability is an issue both for individual users and large organizations. A laptop computer that is difficult to service can mean a wait of several days to a week or more for an individual user. For a large organization with many computers to upgrade and service, it can create a logistical nightmare.
There are multiple ways by which system manufacturers make it difficult to service their products. Most commonly, they create a usage license that restricts upgrade and service to themselves or business partners (the enforcement mechanism being a voiding of the warranty). Another tactic is to make it difficult to get to and remove the component requiring service. For example, Toshiba Satellite laptop computers used a special screw to secure the hatch for the hard drive. The screw was made of soft metal (likely a low grade steel with high zinc content) and had a special head pattern requiring a special tool to loosen it. If you didn't use the special tool, chances were you would strip the screw head. Toshiba charged about $600 to replace a hard drive in those machines. Toshiba ceased this practice a few years ago, probably due to customer feedback and lost sales (though similar behavior still exists today with at least one other computer maker I'm aware of).
People rarely consider warranties and service agreements when assessing openness. Some manufacturers and vendors have very restrictive warranties and service agreements, while others don't. Users should always consider these when making purchasing decisions.
In some cases, like systems for vertical markets, users have no choice when it comes to service agreements. I know of a PC-based automotive service business management system where only the system manufacturer can do anything at all to the hardware or software, without voiding the warranty. The system is quite expensive, so shop owners dare not jeopardize their investment. Routine upgrades--such as adding a hard drive or memory--are quite expensive. This is a case of a system vendor having a captive market. Of course, the system usage license ultimately governs these warranty and service agreements, emphasizing the supreme power of licensing.
Other manufacturers take a much more liberal approach to warranties, allowing users to upgrade systems themselves without voiding the warranty. This type of warranty agreement is much more open.
Few people consider monetary cost a form of openness, but it is. Cost is a barrier to consider when buying or building systems. A computer user may not buy a particular system because of price. A system developer may have to consider other options when a particular component is too expensive. Standard components usually enjoy an advantage when it comes to cost, because they tend to become commodities, with resultant cost decreases.
Official, accepted standards are very important to openness. Standards insure that components will perform and interoperate more or less the same over a period of time and across different platforms. Standards often come under ridicule, but they have done much to advance the state of the art in computer technology.
There is also, in theory, nothing wrong with a good de facto standard. Java has enjoyed much success and wide usage, despite the lack of an approved standard. However, developers still take a risk when committing to a de facto standard controlled by a single company. This is why ISO rejected Sun Microsystem's application for Java as an ISO standard. Technology will often establish itself as a de facto standard before finally becoming an officially recognized one, though it must first meet the criteria of decentralized control.
There are times when competing versions of a technology introduce incompatibility in the marketplace. The Blue-ray vs. HD-DVD battle is an example of this. Digital camera manufacturers offer different versions of the RAW format, making it difficult to work with. At some point, a winner may emerge, or a compromise occur, on these technologies. This type of competition, while initially disruptive, can help insure that the best technology wins. Standards are indeed important, but competition often fuels technological innovation and, as such, needs free expression.
Interoperability is closely related to the issue of standards. This is one of the more important issues in system integration. Most data communication protocols conform to official standards, so that products from different companies will function properly and work with each other.
In the Linux world, interoperability between various software components relies on de-facto standards. These standards change, requiring software developers to keep abreast of the technology. For example, CORBA has fallen out of favor as the underlying messaging mechanism in Linux desktop environments. Its apparent replacement is DBUS. CORBA is an approved standard, while DBUS is a de facto one.
Taking these areas into consideration demonstrates that issues of openness and propriety affect all constituent components of a system (hardware, software, warranty, service agreements, etc.). This comprehensive assessment is an openness stack. When evaluating a system, examine all components and also all elements (licensing, transparency, interoperability) affecting those components. Cover the entire openness stack.
With a complete understanding of any given system's openness stack, you then have an idea of that system's degrees of openness. I use the plural form of degree, to highlight that the degree of openness depends on as many constituent system components as possible. The degrees of openness helps to decide if the system is worth investing in or developing. Of course, no computer system will be indefinitely upgradeable; at some point you have to purchase a new computer to benefit from certain technological advances.
When assessing a system, some aspects can be more important than others, depending on a user's needs. The perfect system likely doesn't exist. However, it's still worth performing due diligence to evaluate systems as completely as possible before making a purchasing decision. It usually isn't necessary to review all system components, but it doesn't hurt. You don't want unanticipated problems later.
The issue of degree of openness is the crux of the current battle between the Free Software Foundation's insistence on GPL v3 adoption and the desire of other parties to continue to use GPL v2. GPL v3 aims to insure true openness for the entire software stack, from operating system to drivers (especially drivers), to system software and user applications. The camp forming around GPL v2 wants to allow proprietary software components to operate within an open environment. Both sides have strong arguments for their positions. It will be interesting to see the outcome.
In the end, open source software covered by BSD style licenses may emerge as the real winners. Apple Computer would benefit from this situation, should it occur. Apple has done perhaps the best job of creating a proprietary product (Mac OS X) from open source components, enabled by the very liberal terms of the BSD software license.
Computer manufacturers can use proprietary components to their advantage, and often do. Usually, their goal is to get you to buy a new system, rather than allow you to upgrade your current one. One of their tactics is to offer a system that is standard and open in all but one or more key areas. When it comes time to upgrade hardware or software, you discover that it isn't possible, due to a dependency on first upgrading a proprietary component, which the manufacturer refuses to do. To enjoy the new version, you must purchase a new system. There are cases where, due to significant technological changes, this is indeed necessary. Unfortunately, many times it isn't.
Another type of proprietary snare involves using proprietary software in an open operating system. When changes occur to the operating system, the proprietary software may no longer work properly, or at all. This gives the proprietary vendor leverage over the open one, especially if users find the proprietary software more attractive than the operating system. GPL v3 advocates hope to eliminate this scenario.
Related to this is when an open source system incorporates patented proprietary technology. The Novell/Microsoft partnership is a great example of this. Microsoft took advantage of Novell's use of .NET technology to leverage Novell into a partnership. Now, proprietary Microsoft technology will become a critical component of one of the premier Linux distributions. From a marketing standpoint, Microsoft gets to tell people they can enjoy all the advantages of Linux, while enjoying interoperability with MS Windows systems running .NET for web services.
It appears that Microsoft's proprietary technology ensnared Novell. Now, as partners, they can proceed to snare their customers into using nonstandard technology. It reminds me of a vampire movie, where the victim also becomes a vampire and joins the family. I would have preferred to see Novell challenge Microsoft with Mono, using it as an adapter between open components and .NET (the original plan), but that is difficult and costly to do and Novell didn't have the resources for it.
Another snare is the issue of companies placing proprietary system monitoring software in open source operating systems to enforce digital rights management. This particular topic is of great concern to GPL v3 advocates and is a very explosive and divisive issue right now.
There isn't any reason why an open source platform can't license proprietary technology, with contingency clauses in the licensing agreement protecting the open source developers. For example, some system developers negotiate agreements with proprietary software vendors that require the vendor to provide source code in the event the product does not receive regular, scheduled maintenance, or if the vendor goes out of business. There is still risk associated with this approach, so it is no substitute for using open source code from the outset. These types of agreements could create a new niche business, for software custodians (similar to a custodian of a trust fund). However, even trusts occasionally suffer tampering and trouble, so pure open source is still a better solution.
One of the most potent forms of control exercised by companies wanting to lock in customers, is proprietary data (including digital media) storage. Microsoft's .doc document storage format has been ubiquitous for about 20 years. Open document storage formats, notably Open Document Format (ODF), are finally challenging Microsoft's hegemony and have an excellent chance of succeeding.
Proprietary data formats have long been the norm in virtually all vertical software markets. I've had my share of work over the years, liberating data from proprietary formats and migrating it to open forms of storage (mainly relational databases).
Digial media storage formats present a much greater challenge. The music and film industries need to control copyright infringement. Their approach is with some type of digital rights management (DRM) technology. Advocates of completely open software vehemently oppose any type of closed software, especially when placed within an open computing environment. Another problem is fair use. DRM software often prevents people from making a copy of media they rightfully own, for purposes of backup or for use on a different player. DRM is perhaps the main impetus behind GPL v3.
Computer companies use proprietary digital media formats to lock customers into certain platforms. For example, Apple provides QuickTime only for Mac OS X and Microsoft Windows 2000 and XP.
There has been a small amount of progress recently in the area of digital media. RealNetworks won the use of a Microsoft codec as part of the Microsoft anti-trust settlement. RealNetworks has licensed this codec (as part of RealPlayer) to Novell and Red Hat, for inclusion in their Linux distributions.
Regardless of form, proprietary snares are important to consider when evaluating the openness of a system.
Degrees of openness are at the heart of the debate over how companies actually make money offering open source products. What it comes down to is that, to stay in business, companies must find ways to make money offering open source solutions. They often resort to proprietary methods to do so, trying different business models with varying degrees of success. The basic problem is that when you try to collect money for things people can acquire for free, they tend to take the free stuff and not pay you. Even when you try to add value to the free stuff, people tend to take only the free part and look for other ways to acquire your additions.
First, Linux distributors sold boxed Linux sets containing documentation, along with technical support and consulting. This worked until affordable broadband Internet service made it possible for people to download Linux and write it to CDs. Next, companies continued to try selling boxed sets of their Linux distros, but allowed people to download the distro free of charge, charging fees for technical support, training, and consulting. Finally, the most common model today is where a company offers two different but closely related versions of its distribution, a free of charge community version and a paid commercial version. The Linux distributors sponsor the community development groups, then use the community's work as the basis of the paid commercial version. The paid commercial version usually contains software not found in the community edition; this extra software is often proprietary. The commercial version also comes with some form of technical support. The distro vendor also charges a subscription fee for updates. Today's Linux distributors emphasize certification, training, and consulting services heavily.
The problem with these business models is they have no way of assuring the customer won't find other ways to satisfy the tech support and training components. Oracle recently started providing support for Red Hat Linux, at greatly reduced cost, as a means to disrupt Red Hat. Many Red Hat customers are at least considering this new service offering. Regardless, companies such as Red Hat and Novell are working hard to make the model work and are meeting with some success, but it appears unlikely they will grow into behemoths. Red Hat seems comfortable with this; its founder Bob Young once stated that his goal was not to grow Red Hat as large as Microsoft, but to shrink Microsoft until it is as small as Red Hat. All rhetoric aside, it is much easier for a large company to provide a high level of tech support to many users than it is for a small one. Economies of scale are still important in an open source world.
Open source application software companies, such as relational database developer MySQL AB, add a slightly different twist to dealing with the issue. MySQL is available under the GPL, but there is also a commercial license available for people who do not wish to licence and distribute their source code under an OSI-approved license.
The two companies credited with most effectively leveraging open source software are IBM and HP. IBM has created a suite of software by integrating open source components into existing product lines. IBM also derives a significant portion of revenue from consulting services, which also use open source solutions. Finally, both IBM and HP sell a lot of hardware that runs Linux. These companies are successful offering open source solutions for several reasons:
In short, these two companies have heft. This doesn't mean other organizations can't participate successfully in the market. Companies such as Canonical and Linspire show great promise in working with smaller hardware vendors to service niche markets. Penguin Computing has enjoyed success in the server market, by offering high quality systems built with open source software and industry-standard hardware components. System 76, a newcomer, sells laptops and desktops running Ubuntu Linux and pure open source applications.
Open source users and software developers also need to keep an eye on business-related issues in the open source community. The health of organizations supplying open source technology is critical to the success of open source application developers and users. Oracle's recent acquisitions of Inno Oy and Sleepycat Software cast a pall of uncertainty over the future of MySQL, which depends on Inno Oy's InnoDB engine for important features. Sleepycat was the backup solution for MySQL AB, to provide a new engine had Oracle denied MySQL AB use of InnoDB. Then, Oracle acquired Sleepycat. In the open source world, project forking is the solution to these types of problems. Project forking can succeed (and has), but there are only so many developers to go around and forking a major project causes at least temporary disruption. Novell's acquisition of SuSE and subsequent partnership with Microsoft will provide a fascinating case study of a proprietary company's integration with an open source one.
It is unlikely the average individual consumer will apply a comprehensive understanding of openness to his computer purchasing decisions, though these issues can and do effect him. Assessing degrees of openness is most useful to organizations purchasing large numbers of systems and to developers wanting to create sustainable products. Purchasing a large number of bad systems can have an adverse effect on computing capability, operational efficiency, and capital expenses.
System developers face a different set of criteria and challenges. Choosing the wrong set of software and/or hardware components can later cripple an otherwise well designed product. Sometimes you have to be pragmatic and take a chance, based on present requirements and availability. Expediency is often necessary, but can later interrupt your progress and require unanticipated work. An excellent example of this was Linus Torvald's decision to use Bitkeeper as the source code control system for Linux. Bitkeeper's owner later decided to invoke licensing privileges, causing Linus to interrupt his Linux work to develop his own source code control system (called Git). The current conflict between advocates of GPL v2 vs. GPL v3 threatens to create a similar situation, of much greater magnitude. It could derail Linux's current momentum.
The computing landscape is a much different place than it was a few years ago. Open source software has presented both huge opportunity and difficult challenges. The major challenge is the conflict between proprietary, and nonproprietary products. Compromises have resulted in a rather messy entanglement. Users and developers get caught in the middle, often bewildered by the complexity of licensing and technology. Technology itself gets caught in the center of this conflict. The politics of today's computer industry would have delighted Machiavelli. Any methodology or way of thinking that can delineate and define these complex relationships will empower users and developers to arrive at better decisions. There are many aspects to the openness and propriety of computer technology. It pays to consider these before making commitments.
The examples used in this article are not a comprehensive list of all possible combinations of open, closed, proprietary and nonproprietary components. These examples serve to illustrate key aspects to consider. Companies continue to introduce novel combinations of licensing, openness and propriety in their technology.
Perhaps the final question is whether a pure non-proprietary open source software marketplace is possible.
Adrien Lamothe developed his first computer program in 1976 and never looked back.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.