 Licensing
Risks, Not Revolutions: Part II
Bryan J. Smith
Part I of this article focused on redefining software licenses
beyond the one-dimensional, non-descriptive values of "open" and
"closed" (proprietary). It expanded the categorizations, applying
the values to axes of "source code" and "standards compliance."
It also considered the factors of risk in adopting the three,
common types of software that may be considered "open" under this
model:
- Freedomware: Open source, open standard
- Standardware: Closed source, open standard
- Sourceware: Open source, closed standard
This leaves one remaining categorization, or so it would seem.
Not all closed software vendors consider their software truly proprietary
and of long-term value to their customers.
Like the term "open software", "closed software" is also relative.
For the purpose of this article, closed software is software that
does not use an open standard for its inherent data storage format,
although it may support open standards (such as through import/export
of open formats). This is the essence of proprietary, which is not
necessarily anti-consumer, but simply means the copyright and all
IP holders assign a value to the software that inhibits its full
non-disclosure.
Categorizing Closed Software
To begin, the most obvious categorization is the fourth extreme
not listed under open software previously. Such software is commercially
valued software, or commerceware, for short:
- Commerceware: Closed source, closed standard.
- Copyright and other IP of considerate value to, and not disclosed
by holders.
- Software prefers proprietary standards that are of value to
holders
- Proprietary source code that is well protected and maintained
by holders.
Again, commerceware is not anti-consumer. Commerceware must offer
the consumer value -- and repeat value -- or it will not sell, at
least not long-term. As such, most viable commerceware is well maintained
by its proprietary holder, including making newer versions being
backward compatible with older versions. This is because commerceware
does have a well-maintained set of source code and standards because
they are of great, proprietary value to the holders.
This is in stark contrast to the software approach and license
that does not belong on our chart and will now be discussed as the
other closed software. Although profitability is the main incentive
to commercial software development, and commerceware is driven by
offering proprietary value, sometimes existing market share and,
more importantly, control of the distribution channel dictates this
alternate closed software development. Such commercial entities
do not concern themselves with offering the customer value, but
rather with making sure control of their distribution channels cannot
be circumvented by reverse engineering of their formats. The result
is that such software inherently lacks even proprietary standards,
as the software must constantly be changed to prevent breaking the
vendor lock on market share.
Any time software is unable to maintain any standard, source code
also becomes impossible to maintain. The plot of such software requires
not merely a 2D plane, but a 2D surface area plotted on a sphere
as illustrated in Figure 1.
Closed software that costs the consumer can result in an unmaintainable
set of source code and/or standards, as much so as poorly maintained
open source or standard. The result from a 100% risk-mitigation
standpoint is that the software now becomes software holding data
and corporate IP hostage, or "hostageware." Brendan Scott first
coined this term, albeit under a different argument and viewpoint
(i.e., he did not differentiate between hostageware and commerceware).
David Billsbrough first suggested to me the concept where the two
extreme values of one axis could "wrap around" and meet at the same,
negative result. His specific example was to suggest an axis on
a cylinder where "too free" vs. "too totalitarian" met in the same,
political result of "anarchy".
- Hostageware: Unmaintainable source or unmaintainable standard.
- Constantly changing source and/or standards; no long-term open
or closed standards.
- Open or closed software that is little proliferated, poorly
maintained, and uses eccentric standards.
- Closed software designed to maintain a massive market share,
sales based on control of distribution channel (e.g., OEM, bundling),
not retail value.
Closed hostageware is the most well-known commercial software,
even though it only exists from a very small subset of vendors.
Although few in numbers, vendors who control distribution through
the PC OEM control up to 90% of the end-user's software choices.
Other vendors have made significant investments in computer superstores
to assert the same control over after-market purchases as well.
Typically two strategies result in closed hostageware -- "Backone"
and "ArchPI" -- which will be analyzed shortly.
Mitigating Closed Software Risk
Adoption of commerceware may be as little or as much of a risk
to corporate investment in data as "open software" licenses. But
in the case of commerceware, the factors of risk now change because
both source and standard are considered proprietary. Risk factors
cannot be mitigated when moving from commerceware to closed hostageware,
which will be discussed shortly.
Vendor History -- Does the Vendor Have a Reputable History
of Customer Support?
With closed software, the software becomes more about the vendor
and IP holders, not the software itself. If the commerceware vendor
and partners place value in both their proprietary source and standards,
how do they present this proprietary value to the customer? The
commerceware vendor must do this in a way that proves to the customer
that all past and future formats will be interchangeable. A vendor
who has a history of long-standing support of older formats mitigates
risk of commerceware deployment, sometimes far better than even
"open software".
One common mistake and completely incorrect assumption to make
is to assume proprietary standards will eventually be reverse engineered.
Newer U.S. federal laws like the Digital Millennium Copyright Act
(DMCA), and U.S. state laws like the Uniform Commerce Information
and Technology Act (UCITA) extremely limit such newer developments.
While some commerceware vendors do nothing when their proprietary
formats become "open standard" by reverse engineering and may even
offer sourceware license in exchange for compensation, closed hostageware
vendors fight it.
"Backone", discussed in the following section, is an intentional
closed software strategy designed to fight reverse engineering,
with the added profit bonus that requires consumers to upgrade every
version. Such closed hostageware vendors have used the DMCA in litigation,
even to protect reverse engineering of high-markup accessories and
consumables (e.g., printer cartridges). This is the ultimate form
of "vendor lock-in" by closed hostageware vendors, which should
be differentiated from ethical commerceware vendors.
Closed hostageware vendors are also notorious for requiring licensees
of their IP that waiver all rights to suing the hostageware vendor
over IP infringement. Many licensees are OEMs or distributors with
profit based heavily on the bundle and sale of such closed hostageware.
Thus, these licensees sign these agreements, despite the resulting
IP theft by the closed hostageware vendor. Sadly enough, because
of strategies like Backone, even a licensed, proprietary standard
behind closed hostageware still rarely offers full specifications
that are of any long-term use to the licensees. The resulting risk
cannot be mitigated by end-users.
Support and Modification -- Who Supports the Software and Maintains
Changes?
Support also becomes a vendor-centric consideration with closed
software. Written Service Level Agreements (SLA) are of the utmost
importance because they make vendors legally liable for failure
to support the customer. Commerceware vendors that offer SLAs and
other support contracts -- especially those that allow customers
to make direct software modification requests the vendor will service
-- are keys to mitigating risk of deploying commerceware. Once again,
these select vendors can and do offer significant value and risk
reduction versus even some "open software".
Not surprisingly, in the case of closed Hostageware, vendors rarely
offer SLAs and written support contracts directly to consumers.
Because they control the OEM or distribution channel, the OEM or
distributor becomes the point for any SLAs or other, written agreements.
Even when the vendors offer extensive development capability, they
still require modification to come through a partner or other entity,
and never directly from the customer. And through these other entities
there is not only a liability buffer, but when pressed, the OEM,
distributor, partner, or other third party will always admit the
closed hostageware has absolutely no liability -- assumed or written
-- under the agreement.
Only when an enterprise is significantly large enough does the
closed hostageware even begin to offer SLAs and modification of
the software, and then only under significant and repeat pressure
of massive purchase withholdings in the tens or even hundreds of
millions of U.S. dollars. This approach, although well known by
blue chip companies when dealing with Microsoft, seems to have escaped
the largest Microsoft consumer -- the U.S. federal government. It
seems only one major political figure has publicly suggested that
the U.S. federal government use its enormous purchasing power as
a consumer to enforce its will on Microsoft, instead of as a regulator
with anti-trust lawsuits. Indeed, the recurring theme of this article
is that consumers have a choice in their own mitigation of risk
and should not blame anyone but their own risk analysis (or any
lack of such proper risk analysis) to their data.
Vendor Roadmap -- Has the Software Shown a History of Portability
and Forward Direction?
One of the major arguments used by "closed software" vendors against
"open software" is the product roadmap for purposes of strategic
planning. Commerceware vendors who value their proprietary source
and standards recognize the importance of innovation and value of
what others do not offer. Like the other two factors of risk in
adopting closed software, commerceware vendors will show a history
of under-promising and over-delivering, including hitting not only
target dates, but delivering the software completely as promised.
This includes being able to port software to new platforms as they
become popular or more effective. With the dollars to fund less
commodity research and development (R&D) and stay ahead of competitors
and even open software, commerceware vendors that have solid roadmaps
with a history of such "delivery integrity" mitigate the most risk
in adoption by organizations.
Unfortunately, select closed hostageware vendors have the worst
roadmap histories. They have not only shipped products late, but
not as originally advertised. These vendors and their products quickly
become obvious because the developer release versions of their software
lack the technologies advertised. Because they control the OEM and
distribution channels, there is little reason for them to include
promised features because most consumers accept what is available
through these channels.
Closed Hostageware: Backone and ArchPI
A closed hostageware vendor will only maintain full backward compatibility
with one version, changing binary data fields every version so they
are incompatible with versions more than one version back. The latest
version only saves all data into the new format; saving in an old
format is unsafe/incomplete. Remember, closed hostageware vendors
are more interested in maintaining control of existing market share
and/or distribution channels, so they do not have to sell a product
on merits at the retail shelf. In fact, most closed hostageware
is typically outsold by competitor's products on the retail shelf,
but that is only 10% of the total market.
- Backone allows customers who upgrade with every version to
still read their immediately preceding version documents.
- It penalizes customers who do not upgrade every version, as
binary data fields two versions back now conflict with new ones.
- A Backone-wielding vendor may not even differentiate versions,
calling them all "97 format", but actually implement this strategy
with each release.
- Backone also keeps the binary data format a moving target,
inhibiting reverse engineering.
- By the time the format is reverse engineered, it is two versions
behind and useless for companies who constantly upgrade the hostageware
for the previous reasons of last release compatibility.
- Third-party vendors who attempt to support the Backone formats
must not only identify and parse the correct, version-conflicting
data field formats, but do so at a far greater R&D cost than
the original, closed hostageware vendor.
ArchPI is an unintentional strategy, found largely on software
developed for the IA-32 (x86) platform, where the vendor writes
code that is tied to the offerings of a particular architecture
that is not implemented in others. In the case of IA-32, use of
binary records and total ignorance of data alignment, endianness,
and byte order is absolute. The developers at such closed hostageware
vendors are not aware of such details that affect the portability
of their own software.
- Software becomes not only processor specific, but Application
Programmer Interface (API) changes are impossible unless they
are architecturally compatible.
- Portage of software is a major undertaking, requiring major
new code to be written to handle data alignment, endianness, and
order requirements. (A discussion of these concepts is beyond
the scope of this article, but understand that even some IA-32-only
developers have no idea what I am talking about, hence the root
problem.)
- A port is often incompatible with the original version; you
may be able to send documents to the port but going back to the
original is difficult.
- A change or patch to how a compiler (turns programmer source
code into machine-usable object code) optimizes the organization
binary data can render even the same version incompatible.
- A compiler may now want to change the storage order of a binary
data record for performance improvements.
- Library translators and run-time implementations can simulate
the original environment, at a massive performance hit.
Examples of Closed Software Risk
As with open software, theory and discussion is nice, but examples
go a long way toward explaining how real-world closed software goes
about mitigating corporate risk. Consider closed office suites of
both commerceware and Backone strategy -- a Backone suite for Web
browsers and authoring tools, and the resulting ArchPI OS despite
two attempts to resolve the development issues, and Corel WordPerfect
Office and Suite commerceware. Corel has maintained a long-standing
commerceware suite of products, from WordPerfect to various Borland
application acquisitions (its graphics suite that now includes integration
of former Micrografx products).
Backward compatibility is nearly absolute, and several of its
formats have been openly reverse engineered. Proprietary standards
and maintainability of formats have always been key, as Corel has
always allowed end users to see even the format codes directly in
WordPerfect. Newer versions support import/export of both OASIS
OpenOffice XML (which Corel also sponsored at OASIS), but has used
its R&D funds to reverse-engineer older MS Office versions (8.0/97,
2000/9.0, and even XP/10.0) better than Microsoft's, as verified
by independent media research.
Regarding roadmap, Corel has maintained cross-platform, portable
code since near-inception. In more recent, Win32-centric years,
Corel has still maintained a code base that is WINELIB (a porting
library to Unix platforms with 0% legacy Windows code) compatible,
making it easy to port to several other platforms if necessary.
Newer Corel code development uses pure .NET, which will allow easy
porting to not only other platforms, but future Windows platforms
(such as Win64). Of all commerceware office suites, Corel continues
to offer the best risk mitigation of any commerceware (or hostageware)
vendor.
Microsoft Office and Suite Hostageware (Backone and ArchPI)
Although assumptions and IT media speculation still surround Microsoft's
XML moves, the history and current offerings do not match those
assumptions and speculations to date. MS Office is closed hostageware
because of both its intentional Backone and unintentional ArchPI
issues. Regarding Backone, DOC 8.0/97 is the supposed "unified format"
for all new MS Word versions, but attributes consistently change
with each new version. Tag reuse every two versions is how reverse
engineering is prevented in newer versions, besides forcing users
to upgrade every version or otherwise lose formatting and data in
older versions. Even its supposed ANSI-standard Rich Text Format
(RTF) export is full of non-RTF, DOC-only tags (and many other office
suites detect this, and use their DOC import, not RTF).
Regarding ArchPI issues, relying on the flexible organization
of IA-32, binary record read/writes are used heavily in the MS Office
suite and not byte. Such issues of data alignment and organization
are completely ignored by the Microsoft application and tool divisions,
basic concepts at the heart of any coding standard outside of the
Windows platform. Total ignorance of other organization becomes
an issue for the MacOS/PowerPC ports of MS Office.
Even though the non-Win32 versions include custom import routines
to parse and discover the ever-changing binary format output by
MS Office for Windows so that MS Office for MacOS X (for example)
can import the format, it is very difficult to output back the exact
format that MS Office for Windows will expect. This is why MS Office
for MacOS X (or any other office suite) can read documents from
MS Office for Windows users, but once they are modified outside
of MS Office for Windows, they cannot be read on MS Office for Windows.
In fact, as the IT media constantly clings to the hope of a MS Office
port to Linux, any MS Office for MacOS X user can attest that document
compatibility would still be a major issue better solved by adoption
of suites designed for cross-platform deployment, such as OpenOffice.org
or StarOffice.
Additionally, various Win32 libraries, such as data access, are
also unavailable under non-Win32 versions. The MacOS X Entourage
application of the MS Office suite is completely independent from
the Windows Outlook application in MS Office, because the code for
the former is completely platform-specific (Win32). This is discussed
further under the ArchPI issues of the Win32 API.
Because of the Backone and ArchPI issues, continued use of MS
Office quickly becomes a risk that cannot be mitigated. The only
way out is to continue to use an older version without upgrading
and wait until other solutions (freedomware through commerceware)
reverse engineer older formats significantly. Microsoft has tried
to inhibit such strategies by introducing "software assurance" licensing,
but some studies have shown the costs of "software assurance" to
be more than 100% of retail list price as of mid-2004 (largely due
to failure of Microsoft to ship newer products on time, after the
expiration of the free upgrade agreement).
Microsoft Internet Explorer and Frontpage Hostageware (Backone
and ArchPI)
Although MS Internet Explorer started adopting many World Wide
Web Consortium (W3C) standards in version 4 onward and, at one point
during version 5, could claim better W3C standards compliance than
Netscape Communicator version 4 (prior to the release of the Gecko-Mozilla
code base), Internet Explorer has always favored its own hostageware
standards by default. This is proliferated in its suite of Web authoring
programs such as Frontpage. Sites that employ such authoring tools
are often called "Internet Explorer-only" content and sites, but
as we shall see, this would require proprietary standards that MS
Internet Explorer does not offer because of Backone and ArchPI.
Regarding Backone, to proliferate usage of the latest Internet
Explorer, Microsoft started releasing run-time libraries as part
of Internet Explorer instead of updates to Windows itself. Newer
Visual Studio and other Microsoft partner development tools then
depended on these libraries. This resulted in the installation of
newer software requiring an install of the latest version of Internet
Explorer, thus allowing Microsoft to change attributes in its hostageware
tags as necessary to prevent reverse engineering and more updates.
Regarding ArchPI, as always, the problem is these tools are Win32
API-only. As such, MS Internet Explorer for MacOS and Unix (Solaris)
are extremely standards-compliant, but do not read supposed "Internet
Explorer-only" content and sites.
Conclusion
Software adoption is a risk. Risk must be mitigated for an organization
to survive. The primary role of Information Technology (IT) is to
mitigate risk to its organization's data. This role is best filled
by careful analysis of actual risk to data on a per-product basis,
not by revolutionary ideals or blind vendor-alignment. The four
software categorizations using two obvious variables that I have
presented go a long way to helping organizations better consider
their risk of adoption:
- Freedomware: Open source, open standard
- Standardware: Closed source, open standard
- Sourceware: Open source, closed standard
- Commerceware: Closed source, closed standard
Furthermore, this article has presented the specifics of why and
how select software becomes:
- Hostageware: Unmaintainable source, unmaintainable standard
Closed hostageware not only does not apply "proprietary" standards,
but this article explicitly details how no source code can be maintained
in the long term by a vendor offering such hostageware. This is
of the ultimate risk to any organization that chooses to adopt hostageware.
A policy of HAIT (Hostageware Avoidance in IT) must be maintained
at all times in corporations for their own long-term survival. Data
longevity issues of applications and Internet security issues of
closed hostageware platforms pose significant problems for the underlying
operating system. As such, future risk mitigation also must extend
to moving data to platform-agnostic applications.
Engineering is the application of modern science in our capitalist
world. IT is the technical and practical extension of engineering
in any modern business. Since IT departments are the foremost instrument
in mitigating risk to business data, and IP in that data, they must
reduce arguments to principles such as business risk based on long-term
engineering planning principles to ensuring data access beyond 3+
years of typical business consideration. Business managers listen
to talk of risk, not revolution.
References
Windows 'Lock in Software,' not 'Proprietary Software', Brendan
Scott, OSTS, Inc., 2003 March 22 -- http://www.newsforge.com/os/03/03/18/1230223.shtml
Businesses are under attack, says MS security head, Scarlet Pruitt,
IDG News Service, 2004 February 24 -- http://www.infoworld.com/article/04/02/24/HNunderattack_1.html
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,
maintain their permanent residence in Orlando. He can always be
reached at: b.j.smith@ieee.org. |
