Of cabbages and kings � Or why Shared Source is not for you
Sankarshan Mukhopadhyay [sankarshanm@softhome.net]


"The time has come," the Walrus said,
"To talk of many things:
Of shoes--and ships--and sealing-wax--
Of cabbages--and kings--
And why the sea is boiling hot--
And whether pigs have wings."

[Through The Looking Glass: Lewis Carroll]

�Over the last few years there has been increasing interest in the multiplicity of software models. Much of this has focused on Open Source Software (OSS)� a label applied to what is in fact a range of models, all of which include the publication of source code. Many of Microsoft's customers and partners have asked us about our source code philosophy and how it compares to other models in the industry today � specifically the OSS model used for such software as the Linux operating system. Microsoft has heard our customers' requests, and we have been studying the OS S model.�
[www.microsoft.com/licensing/sharedsource/philosophy.asp]

Since November 2002, the Microsoft publicity spiel- manufacturing machine has been on the move trying to 'educate' its customers, both existing and potential as to how its Shared Source philosophy is the way out in the clutch of licensing models available and prevalent in the commercial market. What this article proposes to establish is that the licensing paradigm/philosophy so gloriously championed by Microsoft is not a competitor to Open Source Software (hereinafter referred to as OSS) model and neither does a customer benefit from alliance and allegiance to such constrictive model based on restricted and conditional rights.

An overview of the licensing models in vogue is required for any discussion on the above. Thus, although not proposing to be exhaustive, the following definitions are to be adhered to throughout the article (for further information link to www.flora.ca/russell/drafts/license.html for a synopsis of the models).

Shared Source and Open Source are available in different flavors, but the licences in vogue can be generally classified as five different philosophies based on source, which can be defined as:

� Public Domain � everyone has access (help yourself), there are no implicit conditions/strings attached;
� BSD-like (or �CopyCentre�) � everyone is granted right of access to the source, but the acknowledgement of authorship is required;
� GPL-like (or �Free Software�, �CopyLeft� or �Software Libre�) � everyone is granted right of access to the source but distribution of binaries makes it compulsory for the source to be distributed (or at least a commitment of providing access to the source when asked for);
� Shared Source � Microsoft owns it, but you can have a peek if you meet certain stringent conditions, although you generally can't change it or compile it;
� Closed source (or �Proprietary�) � the creator/author owns it, and the sale transaction is based on mutual commercial considerations

These five flavors thus represent a reasonably broad spectrum of control, ranging from none by the author, unrestricted use by the client (Public Domain) to total control by the author, limited rights to run binaries for the client (Closed). And although Shared Source is still proprietary, it manages to apparently tread the fine line between GPL and Closed Source. However, the GPL model of licensing is designed to (protect and) promote the code itself, as opposed to the author's rights to it. This can be analogous to a free-sampling mechanism for the author leading to a future commercial transaction.

http://www.microsoft.com/licensing/sharedsource/ describes Shared Source as "a source-licensing framework that makes source code broadly available while preserving the intellectual property rights". The Shared Source model is a result of Microsoft's 'learning and understanding' of the OSS model and applying them to their business domain. By means and through its Shared Source model, Microsoft aims to allow communities (of customers) a window of opportunity to share the secrets of its code while at the same time maintaining the intellectual property rights required to ensure a monopolistic hold on the business.
A strong and vibrant matrix exists between software and technological usage and the organizations existing in a social setup. This software ecosystem (as defined by Microsoft) consists of the government, the academic institutions, the R&D facilities, the business & commercial community. The Shared Source program aims to empower the communities by providing access to leading development models, improve feedback mechanisms, nurture a healthy industry and protect software/intellectual property rights. Noble aims, yet unfortunately not served due to the nature of conditions imposed by the Shared Source program. Microsoft terms GPL as viral. However, the most controversial and damaging aspect of its own Shared Source program can lead to a different conclusion.

The Shared Source program contains a Non-Disclosure Agreement. Effectively put it prevents a software developer (involved in the Shared Source program)to work in a similar non-Microsoft project. Thus, Shared Source does 'taint' or infect software development process much more effectively and the model is even more stringent than commercial proprietary licensing paradigm. The rights granted by the Shared Source program are:

� Licensees may read and reference the source code but may not modify it;
� Licensees may debug their internal applications that run on top of Windows using Windows debugging tools to make calls into the Windows source code;
� The license term is one year.

Thus, as can be seen from above, the model effectively limits the user/customer under the Shared Source model to be a tester under the licensing agreement, without the ability to modify/apply own fixes. It does not change the vendor-centric model of software development, yet adds stringent conditions that manage to stifle growth. Shared Source leaves the client almost completely deprived of control, Open Source, especially GPLed Free Software, gives the client a great measure of control

i. All the different versions of Shared Source explicitly reject the notion of redistribution or sharing of with third parties, a scenario absent in OSS model.
ii. At a commercial or governmental level, the Shared Source program forbid modification to the code, thus preventing access to solve problems. This read-only access does not in any way help in bug fixes and/or patch development as such activity is solely the right of Microsoft. With open source, such restrictions on the right to implement fixes are completely absent. The OSS model, being based on a globally distributed active and vibrant developer community, leads to a wider access to knowledge without strings attached.
iii. 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 competitive with its code.

Shared source, therefore, behaves like a virus. Thus being part of a Shared Source program ensures that projects/developer teams need to be shielded from being exposed to the knowledge that comes as a part of the package. Intermingling of such knowledge with existing products/projects can lead to violation of copyright and IPR laws leading to subsequent lawsuits. Since IPR laws more often than not do not offer protection to monopolistic knowledge bases, the Shared Source model actually restricts and hinders software development. On the other hand, no such problems exist with OSS and this is well suited and adapted to the current practices of software development.


- posted by sankarshan @ 3/01/2003 11:08:00 PM