Shared Source

In response to the demands of its customers for access to source code, Microsoft created its shared source licensing program. This program allows Microsoft customers to read and examine certain of the company's source code.

The Microsoft Shared Source License is a dramatic leap forward for the world's largest proprietary software vendor, a company that has traditionally kept its source code secret for competitive reasons. At long last, Microsoft's customers may examine some of that company's source code and learn from it. Of course, from the perspective of open source licensing, the shared source concept is a weak alternative that doesn't go nearly far enough to provide software freedom.

The Microsoft Shared Source License has limited purposes:

You may use this Software for any non-commercial purpose, subject to the restrictions in this license. (Microsoft Shared Source CLI, C#, and JSCRIPT License.)

By itself, the "non-commercial purpose" restriction of this license makes it incompatible with Open Source Principle # 1. But this license goes even further, making it also incompatible with Open Source Principles # 2 and 3. Open source software must be available to anyone for any purpose, to create derivative works, and to sell the software. The Microsoft software isn't so available:

You may not use or distribute this Software or any derivative works in any form for commercial purposes. Examples of commercial purposes would be running business operations, licensing, leasing, or selling the Software, or distributing the Software for use with commercial products. (Microsoft Shared Source CLI, C#, and JSCRIPT License.)

In a more fundamental way, this is what the license says you may do ”and what you are forbidden from doing ”when you see Microsoft's shared source code:

You may use any information in intangible form that you remember after accessing the Software. However, this right does not grant you a license to any of Microsoft's copyrights or patents for anything you might create using such information. (Microsoft Shared Source CLI, C#, and JSCRIPT License.)

It is fascinating to consider whether an engineer with a photographic memory is allowed, without infringing Microsoft's copyrights, to re-create Microsoft's software from intangible information that he or she remembers . But that's not the legally interesting question for most engineers. Instead, the effect of this license provision is that engineers /licensees can use the information in some of Microsoft's source code to do practical things but they do not thereby obtain rights under copyright or patent. Source code can help licensees to design interfaces to Microsoft's products and to create programs that read and write Microsoft's data formats. It can be used to validate the security or reliability of Microsoft's products. For some of Microsoft's customers, this availability of source code for limited purposes is sufficient for their needs; they don't really need the software freedom provided by open source licenses.

So if you merely use intangibles that you remember, and if you base your software on those intangibles, you are allowed to do so. Microsoft's source code cannot be used, however, to write software that infringes Microsoft's copyrights or patents.

If you are a software developer who intends to write software that might potentially compete with Microsoft's copyrights or patents, there is great risk in looking at Microsoft's source code. Under the copyright law in the United States, if Microsoft proves that there is "substantial similarity" between your commercial software and theirs, you may be an infringer. You may have to prove that you saw and read Microsoft's source code but that you relied only on intangibles and only on your memory when you wrote your own software.

That's a difficult evidentiary burden . I'm not sure how even an experienced programmer can walk that fine line. Perhaps the best way is simply not to look at Microsoft's source code at all. At the very least, if you are directing corporate projects relating to products competing with Microsoft's shared source software, build a sturdy wall separating those who look at Microsoft's source code and those programmers who might otherwise ”even inadvertently ”create derivative works or any commercial products from that source code.

This risk is not unique to shared source software. Employees can be contaminated by proprietary source code they saw or wrote while working for previous employers . Even open source software contains intangibles that can contaminate the memory of a programmer.

The solution obviously is not to avoid source code entirely, but to build sturdy walls around those in your company who will create proprietary software. Make sure those engineers don't inadvertently create derivative works of any source code they read, because you must honor the conditions and limitations of those licenses.

As for those who create open source software, don't create derivative works of Microsoft's shared source software. The Microsoft Shared Source License ”unlike open source licenses ”doesn't give you software freedom.