Shared Source: A Dangerous Virus
Microsoft has mounted a PR and marketing campaign intended to
convince people that its "shared source" program is a superior
alternative to open-source software. But to believe this would be a
dangerous mistake, one that could easily expose you to the risk of
lawsuits and anti-competitive intimidation by Microsoft.
As of November 2002, Microsoft's Shared Source
program offering is actually a collection of eight different programs with
All versions of `shared source' deny you the right to redistribute
the code or share it with third parties. All open-source licenses
guarantee this right, sparing you the complications and overhead of
having to track and control who gets access to the code.
The shared-source programs applicable to commercial and government
organizations forbid modification of the code; thus, you cannot
actually use your access to solve your problems. Because you are not
allowed to build, experiment with, or deploy modified versions, your
"read-only" access cannot help you field fixes to Microsoft's bugs any
more quickly. At best, your engineering staff will become free labor
for Microsoft, which will release fixed versions on its schedule and
With open source, on the other hand, you can make whatever modifications
you need to on your schedule and in response to your
business requirements. Further, you can enlist free help from three-quarters
of a million developers all over the world without worrying that doing
so will land you in court.
Shared source licenses include a requirement that the licensor agree
to treat Microsoft's code as confidential proprietary data. It follows
that any developer, once he has seen shared source code, can be enjoined
under trade-secrecy law from any activity that Microsoft considers to
be competitive with its code.
Shared source, therefore, behaves like a virus that infects
developers' brains. Once you let it into your organization, you must
keep careful track of which developers have been contaminated, avoid
deploying them to any projects which might compete with a Microsoft
product, and even erect "Chinese walls" between projects so that no
knowledge from shared source can leak into projects with competitive
implications. Failing to implement any of those precautions could
result in your organization's being sued for ruinous compensatory
damages by Microsoft's armies of lawyers.
If you are an academic contemplating exposing your students to
shared source, consider the risk that you may be making the ones
conscientious enough to disclose this to employers unemployable —
and the others into time bombs that could blow up their employers if
Microsoft ever goes looking for a cause of action.
In a government or military context, cross-training and IP
contamination problems could actually have mission-impact and
Of course, Microsoft doesn't want to be in simultaneous
trade-secrecy lawsuits with the entire world, so these scenarios may
seem unlikely to you. But if you accept shared source, expect to be
asked whether you can verify your compliance with the terms any time
that you are in negotiation with a Microsoft representative. Given
Microsoft's history of using EULA-compliance audits to browbeat
customers into long-term exclusive contracts, it would be foolish to
assume that your exposure to shared source will not be used against
you any time Microsoft finds it convenient.
If you are not convinced of Microsoft's altruism, kindness, and
beneficience, consider the possibility that the viral, poison-pill
side-effects of shared source are actually the main point of the
program — a device to make as many independent developers as
possible vulnerable to intellectual-property blackmail and reduce
competitive pressure against Microsoft's monopoly.
Open source avoids all these problems. With open source, you
— and not Microsoft — are in control.