decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
Microsoft's Customer Lock-in and Competition Lock-out
Friday, November 21 2003 @ 03:37 AM EST

You may have noted Cringeley's column about Microsoft and its DRM plans. If even half of what he writes is true, then it represents a clear picture of the real reason why people and businesses and governments are switching to GNU/Linux.

By the way, just today the San Antonio Business Journal reports another big switch:

"The Administrative Office of the U.S. Courts has awarded Fairfax, Va.-based PEC Solutions Inc. (Nasdaq: NM: PECS) a $9 million contract to provide technology support to the government.

"Specifically, PEC Solutions will help the federal courts migrate its national information technologyinfrastructure to a Linux/Intel platform.

"Professional services will be provided at the Administrative Office in the U.S. Court's Washington D.C. offices, its national technology, training and support facility in San Antonio and the government's independent test facility in Phoenix."

In case you were the least bit influenced by the nonsensical reports of SCO needing bodyguards, you might be glad to know what this Linux company specializes in:

"PEC Solutions specializes in providing secure, interoperable technology solutions for clients in law enforcement, intelligence, defense and civilian agencies at the local, state and federal government levels."

Because the issue of DRM and customer lock-in is facing everyone thinking of upgrading to Microsoft's newest announced offerings, we thought it would be useful to explain exactly how it all works. Paul Rouleau has produced exactly such an analysis for Groklaw. As you will see, if you are ever thinking of switching to Linux, now is probably a good time.

For those interested in a study done on interoperability between Word, Excel and Powerpoint and open source office applications, there is one here, in addition to the study Paul mentions in his article.

You can read more on Microsoft's plans for Longhorn and for DRM here and here and here and here and here and here and here and here and here. I believe after you take a look at all the links and then read the article, you will not need anyone to tell you what advantages open source provides to its users. Here, then, is Paul's article, "Microsoft Customer Lock-in, Lock-out Analysis."

***************************

Microsoft Customer Lock-in, Lock-out Analysis
--- by Paul Rouleau

Why would Microsoft tacitly support SCO? Does the SCO case fit into a grander scheme of things at Microsoft? Let's take a look at some publicly available information on customer lock-in and competition lock-out. A picture will emerge and SCO's role will explain itself.

For starters, let's look at how effective Microsoft customer lock-in currently is. A good source of reference material is the European Union migration guidelines. They have conducted extensive research on how European administrations could migrate to a Free/Open Source software environment and there is no reason why their research could not be applied to other organizations.


File Format Lock-in

Customers are sometimes said to be "locked into" the Microsoft Office suite by the format of their document. Is that so? Not really. See the European Union migration guidelines, referenced above, Section 11.1 Page 35:

"OpenOffice is quite good at reading and writing Microsoft Office documents and can be used with confidence. Most incoming or archived documents are intended only to be read and not edited, which reduces compatibility problems further. The few documents that are not compatible with OpenOffice can be converted to PDF format; a server running a single copy of Microsoft Office can be set to perform this function."


The report mentions a few problematic cases. Templates and VBScript macros must be converted. In collaborative projects sometimes a third party insists on using Microsoft Office. In these cases some anomalies may occur in  documents that are authored in both Microsoft and OpenOffice. These problems are rarely serious and can be considered as a typical migration issue.

Conclusion: at present, file format lock-in is more a matter of customer perception than a technical reality.


Application Lock-In

This is the lock-in caused by the need to continue to run the customer's required applications in any alternative environment. How effective is it? On the server, Microsoft never had a monopoly and Linux is winning the battle. On the desktop their lock-in is still somewhat working but it is far from being as effective as it used to be.

See the European Union migration guidelines, all of chapter 13 starting page 59. They mention a whole range of options available to migrate Windows applications to Linux. Let's take a look at a couple of them.

Some applications have Open Source counterparts and can be replaced. Other applications have a Linux version and cause no problem. Wine and Crossover Office are effective in many circumstances and come in handy when they are applicable. But they are not comprehensive solutions.

The thin-client approach based on products like Citrix is quite robust because Windows applications would run on a Windows server and not on some re-implementation or emulation of Windows. Desktop users remotely access the applications with Citrix. This approach is being by used by Telstra. There are limitations: Not all applications work in a thin-client environment; for instance, desktop video editing applications require direct access to peripherals such as video and sound cards, which is not compatible with thin-client products.

Although none of the migration approaches is perfect, it is still possible for a Microsoft customer to migrate a large number of users to Linux by using a combination of all applicable approaches. The method requires three major steps.
  1. To make an inventory of the users and identify the applications each user is using.  
  2. To identify which application can be migrated and assign to each application the appropriate approach to do so.
  3. Then to identify those users that can be migrated based on the application they use. Users that require one or more non-migratable application must be left on Windows for the time being. 

Telstra is aiming to migrate 85% of its Windows desktops in this fashion.

Conclusion: There is still customer lock-in for some applications where none of the above approaches currently work, but nevertheless a large proportion of users can be migrated without any problem.


Software Vendor Lock-In

This is the flip side of application lock-in. This time we concentrate not on the applications that are installed but on the applications available in the market. Several customers are reluctant to purchase any OS other than Windows because they want to have access to the widest choice of applications in the marketplace. On the other hand, commercial developers support Windows because this is what customers have. This is a well known catch-22.

The thin client approach allows Windows applications to run on a Windows server and still be accessible by Linux users. Customers may require that new applications must be thin-client compatible. So the impact of this particular lock-in has been severely weakened as well. If customers migrate a portion of their users to Linux, then the software vendors will start to support Linux and the lock-in would vanish.


It would appear that Microsoft's customer lock-in is crumbling, although Microsoft's market share has not been affected by the lack of lock-in yet. Still, enterprises have much more flexibility to migrate to Linux than most people usually think. How might Microsoft be planning to counter this? We can't read their minds, but we can look for clues in the public record.


A Note on Interoperability and Reverse Engineering

The European Union migration guidelines, page 19, indicates that migration plans whereby all users change to open source software on the same day are to be avoided for all but the smallest organisations. This so-called "Big Bang" migration requires too much in the way of resources in the changeover and there is too great a risk of bringing havoc to the entreprise. A much preferable strategy is to transition users in smaller and more manageable groups.

This kind of migration requires some form of coexistence of Microsoft products with the open source software during the time period where both systems are in simulatenous use. This need is further emphasised by the number of Windows applications that are not migratable to Linux and that may require some users to stay on Windows until a migration strategy becomes available. Coexistence implies a need for interoperability between Microsoft products and open source software.

A recurring theme in customer lock-in attempts is to place obstacles to developers of interoperability products, or at least to put some form of burden that increase the costs and risks of implementing interoperability solutions. If there is no reasonable mean to implement interoperability, then Microsoft customers have no practical migration path to alternative solutions, even if such alternatives exist in the marketplace.

Proprietary and confidential file formats and APIs are examples of obstacles impairing interoperability. Developers need to perform reverse engineering to overcome these obstacles. Anything that delays or impose a burden on developers performing reverse engineering contributes to increased Microsoft customer lock-in. One must pay particular attention to various forms of burdens specifically applicable to FOSS development. This type of burden escapes the attention of regulators and business analysts because practices that are intolerable to FOSS are often acceptable in the commercial world. However the current weakness of  Microsoft customer lock-in is primarily attributable to the vitality of the FOSS alternatives. This kind of selective burden impacts Microsoft's primary competition while retaining a varnish of legitimacy.

Without discussing the legalities, the question here is simply whether Microsoft customers have or do not have a usable migration path and if developers can or cannot develop interoperable software.



File format lock-in : Office 2003

After a period of relative stability in the Office file formats, Microsoft again began playing the incompatible file format game. Although the file formats were based on the XML standard, they used an undisclosed and proprietary schema (as opposed to, for example, the OpenOffice.org format which is a published schema.) Files using  this format could only be manipulated using the Microsoft Office API. The EULA for this API contains interesting clauses:

you must not permit further redistribution of the Redistributable Components by your end-user customers; ...

4. LIMITATIONS ON REVERSE ENGINEERING, DECOMPILATION, AND DISASSEMBLY. You may not reverse engineer, decompile, or disassemble the Software, except and only to the extent that such activity is expressly permitted by applicable law notwithstanding this limitation.

The restriction on redistribution effectively prevents distributing any software that uses this API under any form of FOSS license. The limitations on reverse engineering need not be discussed again. Together, the two clauses help enforce a file format lock-in.

Its appears that Microsoft have now changed their mind. They seem to no longer want to keep the schema secret. On Monday November 17th 2003, Microsoft has allowed the publication of their schema, thereby effectively opening the Office file formats. However, this publication has strings attached. For instance, the schema may be patented:

"Microsoft may have patents and/or patent applications that are necessary for you to license in order to make, sell, or distribute software programs that read or write files that comply with the Microsoft specifications for the Office Schemas."

Does Microsoft own patents on the schemas or not? Are schemas patentable? A schema is a data format, not an algorithm or process, so the question deserves to be raised. There is more. If a developer makes use of the schema, Microsoft requires the resulting software to be licensed from them:

"If you distribute, license or sell a Licensed Implementation, this license is conditioned upon you requiring that the following notice be prominently displayed in all copies and derivative works of your source code and in copies of the documentation and licenses associated with your Licensed Implementation:

"This product may incorporate intellectual property owned by Microsoft Corporation. The terms and conditions upon which Microsoft is licensing such intellectual property may be found at http://msdn.microsoft.com/library/en-us/odcXMLRef/html/odcXMLRefLegalNotice.asp?frame=true.


"By including the above notice in a Licensed Implementation, you will be deemed to have accepted the terms and conditions of this license. You are not licensed to distribute a Licensed Implementation under license terms and conditions that prohibit the terms and conditions of this license. You are not licensed to sublicense or transfer your rights."

The BSD-style advertising clause is well-known to be incompatible with the GPL but that is the least of the problems.

• The developer is required to acknowledge some undisclosed "intellectual property" that may or may not be present in his own code.

• The developer is not licensed to transfer or sublicense his rights. The recipient of the software must obtain a license directly from Microsoft under terms and conditions that may be found though an hyperlink. Microsoft has complete control on the page referred to by the link. Might they change it? Can they stop offering the license, thereby halting the licensees from further distributing their products? What guarantees are there?

• Note also that the developer is not licensed to distribute software that prohibits Microsoft's own terms and conditions. Would Microsoft choose license terms and conditions to invalidate any distribution license they dislike? Combined with the hyperlink, does that mean Microsoft has some kind of after-the-fact veto power on the developer's preferred license?

• Now that the specifications are public, how could developers code applications without requiring Microsoft's license? Does this publication impose on developers some burden to prove clean-room reverse engineering? Is Microsoft positioning itself for future litigation?

A patent available under a royalty-free license is better than a patent that requires a royalty. But there is more than a patent involved in this license. Under the guise of promoting openness, they seem to have created a legal quagmire that may put in jeopardy any software using the schema. The file format may no longer be secret, but using it will scare your lawyer. These terms are  most damaging to FOSS developers. I don't see a way to write open source code under these conditions.The Open Source Definition clause 3 states:

"The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software."

How could that be, if Microsoft can change the terms and conditions at will? Read also clauses Clause 7:

"The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties."

This is clear. Microsoft is attempting to force the execution of an additional license on top of the base, open source license. A true open source license can't allow that. For those of you that prefer the concept of Free Software, the FSF puts it this way:

"In order for these freedoms to be real, they must be irrevocable as long as you do nothing wrong; if the developer of the software has the power to revoke the license, without your doing anything to give cause, the software is not free."



Windows Rights Management

Microsoft Office 2003 supports an add-on called "Windows Rights Management" that provides DRM features. This means files subject to rights management are "protected" using cryptography, more specifically PKI. Anyone developing code to support interoperability with WRM is also entering a legal minefield. In the US and elsewhere, there are laws against circumvention of access-restriction devices, including cryptography. The DMCA has a safe harbour allowing circumvention for interoperability purposes, but what if some user relied on DRM to restrict access to content and the circumvention code is used to break the restriction? Could the user sue the developer? Would the DMCA safe harbour apply if the restriction is not enforced? How would a judge view open source in this context? The code has been published. DeCSS anyone?

This appears to be fertile ground for lawsuits; any developer would be advised to budget appropriately.


Patents and Licensing Attacks

Last time I checked, PKI meant patents. This means independent developers are locked out unless they are properly licensed. It could be argued that Microsoft would be forced to provide the license because of the anti-trust settlement. You can see how that worked out if you read Groklaw's October 31st article on Microsoft's API licensing offers that were required by the anti-trust settlement. The story is also covered here.

"To entice more companies to license its technology, Microsoft previously agreed to reduce from $100,000 to $50,000 a prepayment from rivals and reduce the price it charges so that it collects 1 percent to 5 percent of the revenues of the software that includes its technology.

That is it. Microsoft is allowed to collect a tax on the competition revenue. Licensing also brings an implicit requirement that APIs can only be licensed to parties legally entitled to enter contractual agreements. That would rule out all open source projects that have no legal incorporation. Of course one must assume the competition is willing to get a license when they never had to. I guess the effect of patents on APIs would be to legally force them to.

Are the licensing deals public documents? It would be interesting to know if there are some other restricting clauses, like a confidentiality agreement.


Windows Media Player

Microsoft is facing antitrust hearings from the EU for the bundling of Windows Media Player with the Windows operatiing system. See the reports here and here. Does this not seem to be the same technique that was used to establish IE dominance in the browser market and that was found to be illegal in the US antri-trust trial?

If Windows Media Player becomes the dominant player, there is a real possibility that the file format will become the dominant format for video content, resulting into further customer lock-in based on file format. At least this is what the EU research suggests.

Relying on its own corporate survey, the commission argued that once Microsoft Media Player is on every desktop, companies will no longer spend the extra money to offer data that can also run on rival media players, in particular RealPlayer and Apple Computer Inc.'s QuickTime.

The file format is proprietary and includes DRM features. The format specifications have been published, at least partially, here. The specifications are copyrighted and can only be used if the developer accepts a EULA that includes the following clauses:

"(a)    Specification. Provided you comply with all terms and conditions of this Agreement, including without limitation Section 2 below, Microsoft grants you the following limited, non-exclusive, world-wide, royalty-free, non-assignable, nontransferable, non-sublicenseable license during the Term (defined below), under any copyrights owned or licensable by Microsoft without payment of consideration to unaffiliated third parties, to: (i) reproduce and internally use a reasonable number of copies of the Specification in its entirety as a reference for the sole purpose of implementing ASF in your hardware, application, or utilities (your “Solutions”); (ii) reproduce and internally use your implementations of ASF made pursuant to the terms of this Agreement (your “Implementations”) in source code form solely for internal development and testing of your Solutions, and (iii) reproduce and have reproduced in object code form only, your Implementations and distribute, directly and indirectly, your Implementations (only in object code form) solely as part of and for use with your Solutions.... [emphasis added]

"2.    DESCRIPTION OF ADDITIONAL LIMITATIONS.   Without limiting the conditions set forth in Section 1 above, your rights under Section 1 are expressly conditioned upon your compliance with each of the following limitations: (a)    You may not use, nor authorize any third party to use, the Specification to build Solutions whose primary purpose is to distribute content (including without limitation a cache, proxy, gateway or streaming server)." [emphasis added]
 

The Windows Media format is not exactly an open, no-strings-attached specification. The requirement for binary-only distributions and the provision forbidding sublicensing specifically rule out open source implementations. It appears that open source developers would be have to reverse engineer the format to bypass the EULA that comes with the official specifications, and of course, this approach would run into the following provision of the EULA of the player software:

"* You may not reverse engineer, decompile, or disassemble the OS Components, including any codecs or protocols associated with the OS Components, except and only to the extent that such activity is expressly permitted by applicable law notwithstanding this limitation."

This illustrates again how EULAs can be used to turn the development of interoperable solutions into a legal mine field that imposes obstacles and limitations on the developers.


Application lock-in: Longhorn

Gartner Group sums it all up here (also available here as PDF):

"Many of the features Microsoft is adding in Longhorn will result in increased lock-in to Windows. Microsoft has reached its dominant position in the OS and productivity software markets by controlling application programming interfaces (APIs) and file formats...

"Microsoft wants enterprises to write browser applications that take advantage of Longhorn APIs, which means they won't work on non-Longhorn browsers. Microsoft also wants more types of data stored directly in the file system. It envisions address books, calendar events and e-mail as data replicated directly into the file system. While some vendors may appreciate this, others may not, as it means moving data out of their own proprietary store and into one controlled by Microsoft." [emphasis added]


The more things change, the more they stay the same.


Next Generation Secure Computing Base

Longhorn also includes Next Generation Secure Computing Base, aka NGSCB and Palladium. This again is based around strong cryptography, which was discussed earlier. NGSCB also serves as a foundation to DRM.

According to the NGSCB FAQ there are patented APIs in NGSCB:

"The nexus is a new Windows-based component that will be introduced as part of NGSCB. The nexus is essentially the kernel of an isolated software stack that runs alongside the existing OS software stack. The nexus provides a limited set of APIs and services for applications, including sealed storage and attestation functions....

"From a technology perspective, it will be possible to develop a nexus that interoperates with other operating systems on the hardware of a nexus-aware PC. Much of the NGSCB architecture design is covered by patents, and there will be intellectual property issues to be resolved. It is too early to speculate on how those issues might be addressed."


NGSCB also gets in the way of reverse engineering of applications. According to the FAQ, NGSCB provides the following functions:

  • "Strong process isolation. Users can wall off and hide pages of main memory so that each nexus-aware application can be assured that it is not modified or observed by any other application or even the operating system.
  • "Sealed storage. Information can be stored in such a way that only the application from which data is saved (or a trusted designated application or entity) can open it. With sealed storage, a nexus-aware application or module can mandate that the information be accessible only to itself or to a set of other trusted components that can be identified in a cryptographically secure manner.
  • "Secure path to and from the user. Secure channels allow data to move safely from the keyboard/mouse to nexus-aware applications, and for data to move from nexus-aware applications to a region of the screen.
  •  "Attestation. Users have the ability to authenticate software or a combination of software and hardware. With attestation, a piece of code can digitally sign or otherwise attest to a piece of data and thus assure the recipient that the data was constructed by an unforgeable, cryptographically identified trusted software stack."

There you have it. Only the original application can access the data. And there is no way to peek into "secure" program's memory. Those file formats will be impenetrable.

Is it possible that Microsoft will have access to reverse engineering tools that bypass NGSCB? I don't really know but considering that Microsoft has ability to debug the nexus itself, I don't see what would stop them.


The BIOS

According to this story Microsoft has a deal with Phoenix to increase the integration of the BIOS with the OS. This integration is dependent on NGSCB:

"Both Microsoft and Phoenix are currently arguing for closer integration of Windows with PC hardware, and DRM integrated throughout. Microsoft is planning to tie Windows DRM features to the hardware platform via its controversial Next Generation Secure Computing Base (NGSCB) project, formerly known as Palladium."


According to the NGSCB FAQ, the hardware integration would be the following:

"To make NGSCB possible, both the software and the hardware will evolve. On the hardware side, the CPU, chipset, USB I/O and GPU hardware components will be redesigned, and a new component will be added, called the Security Support Component (SSC). On the software side, a new operating system component will be added, called the nexus, along with some associated code to enable the NGSCB environment. Collectively, this software comprises the trusted computing base (TCB) for NGSCB."


Some questions are left unanswered. Would other OSes have equal access to the hardware? If another OS tried to support the hardware, would NGSCB patents get in the way?

The following tidbit of this same story is intriguing:

"Microsoft said integration should mean simpler and more reliable computers. 'This is a pivotal change for the industry, and it will rapidly advance serviceability, deployment, and management for servers, mobile devices, and desktops,' said Microsoft general manager of Windows hardware Tom Phillips, in a statement. 'Effectively, Phoenix is creating an entirely new category of system software.'"


A "new category of system software". What does that mean? Will there be Windows-specific APIs in the BIOS? Are they available to other operating systems? Are these APIs cryptographically hidden from reverse engineering? Legally, do these APIs belong to Microsoft or to Phoenix? Is this a loophole with respects to the anti-trust settlement?

This raises a lot of questions about the ability of hardware that includes this new Phoenix BIOS to run non-Microsoft operating systems. Would they run? Would they be crippled it they run? Would Microsoft customers switching to Linux have to change hardware as well, if their PCs run this BIOS?

This completes the list of customer lock-in and vendor lock-out strategies. As you can see, there is no shortage of items for the list. On top of the usual proprietary file formats and APIs, we have cryptography, legal risks, patents, licensing deals, NGSCB obstruction to reverse engineering, and tighter hardware/OS integration.

However, even if all these strategies were to prove successful, Microsoft can't completely lock the market again until the release of Longhorn. Once customers are upgraded to Longhorn, however, their ability to migrate out of Windows will quickly degrade as they implement Longhorn-specific applications.

This gives Microsoft customers two or three years to migrate to Linux.

Of course these two or three years are probably Microsoft's worst fear. They need something to deter migrations in the meantime. This is where we need to recall this bit of the Halloween document VII.

  • “'Linux patent violations/risk of being sued' struck a chord with US and Swedish respondents. Seventy-four percent (74%) of Americans and 82% of Swedes stated that the risk of being sued over Linux patent violations made them feel less favorable towards Linux. This was the only message that had a strong impact with any audience."
And also this one:
  • "Messages that rely on an abstract discussion of intellectual property rights are not effective.
    • "The discussion of IP rights needs to be tied to concrete actions."

Does that sound familiar?

Here we have a motivation for Microsoft. SCO may have their own separate motivations, but they still play into Microsoft's hands. Watch the FUD. What matters is not the exact word that is being said. It is the innuendo. People in the acting profession call that the "subtext" hidden under the text of their script. The FUD is saying to decision-makers something like: "Did you check your liabilities? You are going to be sued. Did you cover your bases?" From this perspective, SCO's lawsuit is a scarecrow to give the illusion that these questions are relevant.

No need to have a viable legal case. Smoke and mirrors will do perfectly well, for this purpose.

We see that subtext recurring in the repeated appeals from G. Weiss, vice-president of Gartner Group to chicken out. For example herehere and here where he says:

So what should enterprises do while SCO's suit winds its way through the courts, a process that, including appeals, could take several years? George Weiss, analyst for high-tech researcher Gartner, advises companies using, or deploying Linux, to keep a low profile and avoid publicizing their use of open source software.

To his credit we can see his opinions changing over time, but it seems Mr. Weiss still doesn't fully understand the game. Which is the greater risk, a SCO lawsuit or a new Microsoft licensing deal? This is no time for indecision. The clock is ticking. Desktop OS migrations in large enterprises are multi-year projects. Gartner's customers must start planning and doing pilot projects immediately or risk facing Microsoft's Next Generation Secure Licensing Agreement a few years from now. CIOs can avoid much trouble if they talk to each other and give references about their Linux experiences. This will ensure they move in a large and visible enough group to attract software vendors and remove one more threathening lock upon themselves. This also means enterprises must talk openly about their successes. Keeping a "low profile" to hide from SCO will indirectly help perpetuate Microsoft software vendor lock-in.

The Monkey and the Peanut

I am reminded of the fable where one tries to capture a monkey. Bolt a vase on a shelf and drop a peanut in the vase. The vase opening is tight; the monkey can slip in an open hand but cannot pull out a closed fist. When he closes his hand on the peanut, the hand is caught into the vase, and the monkey is trapped. Of course he can just open the hand to free himself but that means dropping the peanut. The monkey keeps his hand closed and is caught by his own desire.

The desire to be safe from lawsuits is like the peanut in the fable. Want to seize it? You are caught. Freedom means forgetting about the peanut.

Let's take indemnification for example. Indemnification is not such a bad thing in itself. It is a desirable thing to have someone that takes some legal  liabilities off your back. Arguing to CIOs that indemnification is bad is useless. It is like trying to convince the monkey to free himself by telling him the peanut is no good; any monkey can tell a good peanut when he sees one.

It is much better to talk about the vase. Indemnification FUD tricks the customer into demanding a number of things that lock much of FOSS out of the picture.
  1. You need a supplier that can sign the contract and provide indemnification. You can't just download the software.
  2. Economically, indemnification must be funded like an insurance policy. It imposes an extra costs on the open source model.
  3. The indemnification supplier wants to know what code is indemnified. The customer must agree to restrictions on his ability to change the code or risk the indemnification being voided.

As long as the customer wants indemnification, he will either not be able to get Linux or will get a crippled version and be disappointed. Like the monkey of the fable, the customer is locked into Windows by his own desire.

From Microsoft's point of view, the weakness with that approach is that CIOs don't grab for peanuts just because they are told to. They want to understand the issues, the entire picture. They are briefed by their staff. They can read licensing agreements too. They will ask questions. Why IP indemnification only? Why not indemnifying for virus damage and other security issues? How about liability due to software malfunction? They may even ask about the "vase".

This is why the Halloween document VII says that talk about IP rights must be linked with concrete actions. It helps CIOs to want the peanut.


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )