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
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
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
"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
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.
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
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.
- To make an inventory of the users and identify the applications
each user is using.
- To identify which application can be migrated and assign to each
application the appropriate approach to do so.
- 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
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
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
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
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
"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
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
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
"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 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
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
And also this one:
- “'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."
- "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
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 here, 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
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
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
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.
- You need a supplier that can sign the contract and provide
indemnification. You can't just download the software.
- Economically, indemnification must be funded like an insurance policy. It
imposes an extra costs on the open source model.
- 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
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
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.