Licensing Risks, Not Revolutions

Bryan J. Smith

The primary role of IT is to mitigate risk to corporate investments in information. Simple labels on software like "open" or "proprietary" do little to classify risk to an organization's data and IP. In this article, I'll examine these labels and suggest some new ways to define software types.

One-Dimensional Thinking

"Is it open or proprietary?" How do you define open or proprietary? The concepts themselves are relative to differing viewpoints. Such one-dimensional variables with only two extremes offer a poor way to categorize software and their licenses.

Some may argue these two extremes are enough. As you read this, you may associate these terms with the flagship licenses of the open and proprietary world, the GNU General Public License (GPL) and the Microsoft End User License Agreement (EULA), respectively. Other examples may come to mind, but the categories seem distinct enough to most. But what about for other, lesser known licenses? Do these extremes of "open" and "proprietary" represent them well?

The term "open" is very relative, especially in terms of marketing. Some consider it to mean "open source." Others consider it to mean "open standard," or possibly the older concept of "open systems." What about "open IP"? Does open IP offer freely redistributable derivatives? Is it merely royalty-free for specific uses? Or is it only under "fair and reasonable" licensing terms? Viewpoints will be relative.

Putting those arguments aside for a moment, it is easy to forget a major role of IT and IT policy. A major role of IT is to mitigate risk to data -- data that represents hundreds, thousands, possibly even millions of man hours in creation. The actual risk to data is the ultimate consideration in IT. So the one-dimensional terms "open" or "proprietary" when labeled on software and their licenses do little to represent an adequate assessment of their risk in deployment at an organization.

Two-Dimensional: Fidelity Squared

By merely adding another dimension to the argument, we add far greater fidelity and square the number of categorizations. The question is, then, what two variables should we use for software? I suggest these two:

• Variable: source code availability
• Variable: standards compliance

All software has available source code, at least at some point in release. All software conforms to some set of standards. What values can we now associate to source code availability and standards compliance? Let's revisit the terms of original, one-dimensional argument:

• Value: open
• Value: closed (proprietary)

Using the 2D model, we can move from two categories to four as illustrated in Figure 1:

• Open source, open standard
• Closed source, open standard
• Open source, closed standard
• Closed source, closed standard

The concept of using a 2D model for social constructs is nothing new. Software licenses are 100% social construct, so they tend to follow social tendencies.

As an analogy, the values of "conservative" and "liberal" applied to the two axes of "individual" and "fiscal" have been used to categorize American political parties more effectively than just the one-dimensional values on their own. Even though most Americans associate "conservative" and "liberal" with the two most popular American political parties, by merely adding the second dimension of thought, we can now categorize other parties such as the American Libertarian party ("fiscally conservative, individually liberal"). Of course, the values will always be relative. Continuing our analogy to the American political system, both of the two popular American political parties tend to be "conservative" compared with various European viewpoints.

The same is true of software licenses. The terms of "open" and "closed" mean different things from different viewpoints, especially from the ultimate consideration of risk. To begin, let us consider the three of the four licenses that are at least "open" in one form or another, breaking down both their categorizations and risk of deployment.

Categorizing Open Software

Consider the viewpoint of an "open source" advocate. Now consider the viewpoint of an "open standards" proponent. And, consider the viewpoint of a proprietary software vendor who offers some level of "open standards" support. Next, explain the term "open software". And to throw yet another popular term into the mix, describe "vendor lock-in", given these varying levels of "open software".

Instead of using these popular and varying terms of "open software," I think it would be more effective to define a new set of terms based on our 2D standards versus source code model. Let's begin with these three "open software" types: open source, open standard; closed source, open standard; and open source, closed standard.

As much I admire Richard Stallman, I do not admire his insistence in using the term "free software." I can understand his reasons for the same reason others use the term "hacker" to profess technical prowess. Unfortunately, like the modern definition of "hacker," the majority viewpoint defines what the term "free software" means, not the minority one. The majority considers the term "free software" to mean free of cost, not freedom. Some even refer to Linux as the "shareware version of UNIX". The term "freedom software" is a bit long, and "freeware" has all the original connotations of being free of cost.

So, let's build on an obvious idea and call "open standard, open source" software freedomware for short:

• Freedomware: open source, open standard
• Freedomware must be free to use, free to modify, and free to redistribute.
• Freedomware must be free of IP restrictions and requirements.

Another obvious term comes from the shortening of "standards-based software". Such standardware is software that has "closed (proprietary) source", but adheres to "open standards". This is a gray area, and some implementations may be considered more moderate than near the extremes of standards or source. For example, does potential standardware merely export/import standards? Or, worse yet, does it embrace standards but modify them in a way only the product works with its own implementation? At what point does it implement a "closed (proprietary) standard" and not an "open standard"?

• Standardware: closed source, open standard
• Standardware must either follow strict standards or fully publish all new standards as implemented and can be re-created in another product.
• Standardware must produce data that can be read fully read into another product, ideally one that already exists.
• Standardware that introduces new standards or new data format may not be encumbered by any additional license or IP restrictions.

And last of the "open software", a rarer implementation is sourceware. A variation of freedomware, sourceware offers "open source" code with "closed (proprietary) standards". At first this may sound like an oxymoron, but sourceware is very common. Vendors are free to put restrictions on software, even when source code is released into the open, in a variety of ways:

• Sourceware: open source, closed standard
• Sourceware allows vendors to "open" source code but restrict the ability to publicly distribute derivatives or otherwise freely redistribute the software.
• Sourceware could be freedomware that requires a non-freedomware library or support module, or that uses IP that does not have an "open" license.
• Sourceware could be freedomware that has been modified in a way that cannot be redistributed publicly.

To reiterate, I offer these categorizations for "open software" to simplify discussions, such as mitigating risk.

Mitigating Open Software Risk

Adoption of the terms freedomware, standardware, and sourceware is a risk to corporate investments in data. Looking at each, let's consider four factors of risk: standards compliance, support and modification, exit strategy, and software or IP requirements.

Standards Compliance

When considering standard compliance, we can think in terms of the following. Is it inherent to the software (base formats); is it done simply for import/export; and how common are the formats?

Standards compliance is a consideration of utmost importance for mitigating long-term risk to data and corporate investments in data. Even the most proprietary of software vendors claims "standards compliance" in their products. But standards themselves are hard to define. Consider this a major risk.

Freedomware, standardware, and sourceware should use existing, well-established formats. If they define their own, are they standardized with another party, or are they supported by other applications? Many people consider freedomware and sourceware to be self-standardizing, but if no other application supports the format, this could be an area of major, potential risk. In fact, freedomware can and sometimes does result in eccentric formats; although one could argue that's how some of the greatest software innovations have come about.

Documented standards are one thing, but proliferated standards with documentation greatly reduce risk. Source code itself is not an ideal method of documentation or standardization (although it can expose differences between the documented standard and actual software).

Standardware has no source, so it is not self-revealing. Standardware then becomes a matter of independent verification and possible testing to be compliant with well-established and "open standards." If it's not compliant, it is not standardware. Beware of software that does not use "open standards" by default in its inherent format, but only offers limited support, possibly only as an import/export function. Such software is not standardware.

Also know that XML on its own is not an "open standard". XML is merely a standard for creating new standards -- largely to answer vendor complaints that standards organizations, such as the World Wide Web Consortium (W3C), are too slow in adopting. HTML is an instance of XML from the W3C. HTML provides support to XML to fully define itself. So, if a vendor claims to use XML, inquire whether they have they registered their entire XML standard, including all document type definitions (DTDs) and support XML schema with well-established, independent organizations like the Organization for the Advancement of Structured Information Standards (OASIS), considered the primary registrar of completely documented XML instances.

Support and Modification

Ultimately any software is under the support and maintenance of one or more entities. But what if changes are needed to the software -- patches, fixes, special needs, etc.? For each license, you should consider support and modification.

Freedomware may be released by a commercial entity, by the community, or a combination. If a commercial entity is involved, a profit motive must be considered. Do they rely on other markets (hardware) or dual-license the software as non-freedomware? Or does the software prefer non-standard formats by default, which is not freedomware (or "open software" at all).

Ideally, various support offerings should be available, from per incident to SLAs (service level agreements). What if your organization modifies the software but does not want to distribute the changes? Is it allowable under the license to turn the freedomware into internal-only, corporate-specific sourceware (which is allowable under the GPL)? Or can organizations license such modifications, if they're not publicly distributed?

In the case of standardware or sourceware, is the vendor the sole maintainer? Partnerships with industry developers or the community are ideal, because they help distribute the burden of support. Vendors (and partners) should offer SLAs, which may be part of their profit strategy. Dual-licensing is a key consideration, especially if the standardware or sourceware is also available as freedomware. Always consider how patches, fixes, and other changes are made, and whether that release model is sound. The need to maintain additional, internal staff for internal structure to ensure configuration management is vastly underestimated, especially in the case of more eccentric freedomware. Many freedomware adoption projects fail because organizations assume they will save on the costs of release and configuration management as well as licensing. Nothing is further from the truth.

Exit Strategy

No one should assume that freedomware is self-maintaining or perpetual from a risk standpoint. If the maintenance behind freedomware or sourceware dissolves, is there an internal or community effort to continue development of the project? Additional mitigation costs are often overlooked in risk assessment. In the case of sourceware, does the vendor plan to offer the source code under a different license if they discontinue the product?

If the commercial standardware vendor dissolves, lack of access to source code becomes a major risk. Is the standardware already available as compatible freedomware or sourceware? Standardware that is also available as freedomware or sourceware reduces this risk. Of course, the ideal standardware is one that is not discontinued, because the costs ultimately fall onto the few (or many) who continue to use it. Proliferation, or lack thereof, of any "open software" heavily influences the amount of risk in any software adoption.

In all cases (and most locales), understand that copyright law is the ultimate rule, and the copyright holder reserves all rights. Copyrights are the key issue when it comes to exit strategy. An exit strategy should be defined by the copyright holder in the license should the software ever be discontinued. Do not assume any exit strategy from the copyright holder(s) unless explicitly stated. Otherwise the software is a major risk in the absence of any other, compatible solution.

Software or IP Requirements

Software that relies on platforms, libraries and other components, especially those that both technical and licensing requirements that are incompatible with the software license, introduce a major, but often overlooked, risk. A company cannot afford to use any "open software" when both technical and licensing requirements are not met. Much software requires support beyond the control of the entity actually licensing the software. No recourse with the copyright holder may be possible if these requirements go unmet, as they are external to the software purchased and under contract.

Freedomware that requires software or IP licenses (e.g., non-open patent licenses) should be considered sourceware. If the sourceware relies on software that is not "open", such as OS, libraries, databases, or other system/network interfaces, what steps can be made to mitigate the risk of these requirements not being available? Is the sourceware also available as freedomware whereby it does not require these "closed" capabilities? If so, why is it not being implemented as such? This risk may even transgress into the realm of indemnification, whereby software has external requirements, which are unlicensed by the organization deploying it.

Standardware risk mitigation should avoid these external requirements as well. If it does not, has the commercial entity guaranteed access to these requirements? Have they explained why they are required for the system and why they are not using "open" requirements? Do they offer or is there equivalent freedomware that does? Nothing is worse from a risk standpoint than licensing and implementing a product that does not contain everything necessary to function, and where the licenser cannot be held liable for those other requirements. Indemnification is a real issue for entities, regardless of software license.

Examples of Mitigating Open Software Risk

The theory and discussion is nice, but examples go a long way toward explaining how real-world "open" software mitigates corporate risk. Let's consider an "open" office suite, document/print rendering language, Web browser, and Web authoring tools.

OpenOffice XML -- Freedomware, Standardware, and Sourceware

The "open" office suite is highlighted by and starts with Sun's acquisition of Star Division. Sun released the source code of StarOffice 5 to the community under a dual-license strategy of freedomware LGPL (Lesser GPL) and sourceware SCSL (Sun Community Source License). To protect its copyright of the software, under the OpenOffice.org project, Sun recommends all developers who submit more than 10 lines of code sign over a non-exclusive copyright to Sun. The eventual result of the community-driven development (with half of the OpenOffice.org team being paid employees of Sun) was a complete set of XML standards that have been fully standardized by OASIS as OpenOffice XML. The end-user products include the freedomware LGPL OpenOffice.org suite and the standardware StarOffice product.

Considering the factors of risk, the OASIS standardization of OpenOffice XML was supported by not only Sun, but also by Corel (another suite developer) and Boeing (the de facto standard setter in the engineering world for corporate-wide documentation, from office to factory floor). In addition to the OpenOffice.org and StarOffice products, the LGPL license on the code means any and all commercial software is free to use the code for either inherit or import/export support. This has occurred in many products, from AOL's office suite to the WordPerfect series of products from Corel (discussed below under "closed software"). Likewise, under the LGPL license, any changes to the functionality of the code responsible for OpenOffice XML (not necessarily other components) must be shared with the OpenOffice.org project. In addition to Sun, these LGPL and SCSL licenses are also providing their own support.

OpenOffice XML has become the standard for mitigating risk in documentation, from small offices to engineering giants like Boeing. The standardware StarOffice product includes release and configuration management component and support offerings from Sun. Many components are self-requiring and platform agnostic, reducing reliance on other system/library components. Thus, freedomware OpenOffice.org and standardware StarOffice are of minimal risk to adopt.

Adobe Postscript/PDF -- Freedomware, Standardware, and Sourceware

For non-editable documentation and print publication, Adobe's Postscript language is considered de facto standard freedomware and sourceware, depending on Adobe IP (patents) involved. Freedomware can write PostScript and PostScript-derived PDF files that are free of Adobe IP. Various standardware and sourceware can write both IP and IP-free PostScript/PDF formats. Not surprisingly, OpenOffice supports direct export to PostScript/PDF.

Adobe sells most of its software based on the capabilities of the end-user applications in comparison to freedomware and other standardware equivalents, and not by hording specifications of its document formats.

Documentation rendered in IP-free PostScript/PDF should be considered low-risk, although only for non-editable documentation (use as appropriate). IP requirements may introduce some risk because they may not be viewable under IP-free freedomware. Adobe's financials are extremely positive, and the focus of their software is on offering value over freedomware and other equivalents. They are currently platform-centric to Win32 and MacOS X, however.

AOL-Netscape -- Freedomware, Standardware, and Sourceware

Like Sun's office suite, AOL-Netscape's browser is highlighted by the release of its source code. The result was the Gecko engine, which is licensed under a dual-MPL (Mozilla Public License)/commercial license. Gecko is embedded into countless devices and software, from phones to development suites. Unlike AOL-Netscape's prior version 4 and earlier browsers, the resulting Gecko engine and Mozilla source code complies fully and to the letter with many XML W3C Web standards, such as HTML, CSS, XHTML, and others. It also defines several new XML, OASIS-standardized formats. The end-user products include the freedomware Mozilla suite, individual software components (i.e., Firefox, Thunderbird, Sunbird, etc.), and the standardware Netscape browser. Neither implements platform-specific capabilities, such as Win32 ActiveX, which coincidentally makes them lower risk from a network security consideration -- regardless of platform, as the code is very platform-agnostic.

Newer developments in both products include release and configuration management tools, and support is available from AOL-Netscape for standardware Netscape. Freedomware Mozilla and standardware Netscape should be considered low-risk.

Macromedia Standardware and Sourceware

Macromedia's suite of products -- Dreamweaver, Fireworks, and Flash -- inherently support "open" standards also supported by various other freedomware, standardware. and sourceware. This includes many well-established XML standards, such as HTML, CSS, PHP, and other industry organization standards like Javascript. Macromedia also offers a proliferated, fully documented, self-standard in Flash sourceware (which was not always the case), and increasing support for XML equivalents like Scalable Vector Graphics (SVG, which also offers motion vector graphics). Macromedia sells its products based on inherent features and project management capabilities, as well as end-user features, and not by hording specifications of its document formats (not even Flash).

Using Macromedia products is low risk, depending on what features are utilized. IP requirements (largely Flash) increase risk. Financials are extremely positive, with standardware products offering value over freedomware and other equivalents. They are currently platform-centric to Win32 and MacOS X, however.

Conclusion

The risk to an organization's long-term investment in data must be mitigated for an organization to survive. A successful IT professional must always discuss software adoption in terms of detailed risk reduction, not of revolution. In this article, I introduced three "open software" categorizations and dissected their factors of risk:

• Freedomware (open source, open standard)
• Standardware (closed source, open standard)
• Sourceware (open source, closed standard)

In Part 2, I will expand on not only the remaining categorization, commerceware (closed source, closed standard), but will discuss a fifth categorization that may result from any type of software. Such software holds the data of an organization hostage, and is of the ultimate risk. Our graph can still represent it, just not in its current form.

Bryan J. Smith has an educational background in engineering (BSCpE, UCF) and has spent much of his 12-year career applying engineering principles of risk mitigation to corporate investments in the aerospace, civil, educational, financial, semiconductor, and software industries. For the past 4 years, he has provided engineering, IT, and training services to a variety of clients, including managing financial network security at two Fortune 100 companies. Mr. Smith and his wife, Lourdes, live in Orlando. He can be reached at: b.j.smith@ieee.org.