Degrees of Opennessby Adrien Lamothe
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.
Transparency Not Required
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.
Open Can Still Mean Proprietary
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).
All Things Considered
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.
Licensing Controls Everything (Including Patents)
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.