* Microsoft Shared Source Initiative
Jason Matusow, director of Microsoft’s Shared Source Initiative, reminds me a lot of some 17th century French missionaries – his employer expects him to go out and convert the natives, but his real contribution may be in the discoveries he makes rather than the converts he claims (e.g., Jacques Marquette, http://www.virtualology.com/virtualmuseumofhistory/hallofexplorers/jacquesmarquette.net/). Matusow is a missionary for Microsoft’s SSI, who goes among the “natives” of the open source community extolling the virtues of Redmond’s technologies. He also makes valuable discoveries, such as IronPython, as we saw in the last issue.
Jason Matusow, director of Microsoft’s Shared Source Initiative, reminds me a lot of some 17th century French missionaries – his employer expects him to go out and convert the natives, but his real contribution may be in the discoveries he makes rather than the converts he claims (e.g., Jacques Marquette, https://www.civilization.ca/vmnf/explor/marqu_e1.html). Matusow is a missionary for Microsoft’s SSI, who goes among the “natives” of the open source community extolling the virtues of Redmond’s technologies. He also makes valuable discoveries, such as IronPython, as we saw in the last issue.
When not engaged in missionary work or voyages of discovery, though, Matusow has to explain, interpret and administer SSI’s licensing program. For those familiar with Microsoft licensing, you’ll understand that this is not an easy task.
SSI, in a nutshell, allows people to see, and in some cases modify, Microsoft source code. But what you can see, and what you can do with it, varies from group to group.
There are six main groups that can license source code under SSI: governments, enterprise (i.e., corporations), Microsoft MVPs (Most Valuable Professionals – volunteers who do peer-to-peer support of Microsoft technologies), system integrators, researchers (generally in the education community) and OEMs (Dell, HP, Sony, etc.).
MVPs, for example, are generally allowed to view source code of the services and applications they support but cannot publish, modify or incorporate it into any writing or programming. Systems integrators, OEMs, researchers and, to some extent, enterprises can see and reuse some source code as part of non-commercial, non-distributable software and can view other source code in an effort to better understand how their code interacts with Microsoft’s.
An interesting case is that of governments. That is the only sector that can see source code that deals with security inside applications and services. But governments have to do this in Redmond under strict monitoring to be sure that none of this code escapes “into the wild” where those of malicious intent can acquire it.
According to Matusow, most – with the major exception being MVPs – only want to see small snippets of very specific portions of code. Developers need to know how their code can be optimized to run with Microsoft’s. And as far as I can determine there is no “standard” license agreement – each is tailored to the specific licensee based on the group they are in and the code they want to have access to.
If your organization does in-house development for Microsoft applications and platforms, you probably should investigate the SSI to see if it would help your developers better understand the environment their applications were running in.
