Warranties and Service Agreements Can Be Open or Closed
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.
Cost Is a Form of Openness
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.
Standards, by Their Nature, Are Open
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 Critical
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.
The Openness Stack
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.
Degrees of Openness
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.