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 different restrictions.

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 not yours.

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 national-security implications.

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.