Shared Source Licensing

UPDATE - I'm adding some good blog discussions below based on this news.


Open source licenses are source code licenses. Shared Source licenses are source code licenses. Shareware licenses are (at times) source code licenses. And what is a source code license? It is a way for a software creator to place usage terms on their property.  


Source code is property.


How the creator of the software chooses to release their source code has been a very active point of discussion in the industry for years. Today, Microsoft is simplifying its source code licensing so that developers working with our technologies will be able to focus on developing great software rather than understanding a license. Our source code licensing needs to be simple and predictable.


There is no “correct” way to license source code. It is the choice of the author (individual or organization) to choose the license that works best for them. If you would like to release your code under terms that stipulate only people with purple hair who own three-legged dogs can use your code – so be it. Your potential community may be limited, but that may be what you are looking to accomplish with the license.


Today, we are announcing the availability of three new template Shared Source licenses. In this way, all of Microsoft source code releases will be under consistent terms, and thus more easy to 1use and to understand. The licenses are each 1 page or shorter. They are written in simple terms that non-lawyers should be able to follow. They are also reflective of the most modern thinking regarding source code licenses within the legal community.


The three licenses are: (check out for more info)

1) Microsoft Permissive License (Ms-PL)

2) Microsoft Community License (Ms-CL)

3) Microsoft Reference License (Ms-RL)   

The Ms-PL is the least restrictive of the Microsoft source code licenses. It allows you to view, modify, and redistribute the source code for either commercial or non-commercial purposes. Under the Ms-PL, you may change the source code and share it with others. You may also charge a licensing fee for your modified work if you wish. This license is most commonly used for developer tools, applications, and components.

The MCL is a license that is best used for collaborative development projects. This type of license is commonly referred to as a reciprocal source code license and carries specific requirements if you choose to combine MCL code with your own code. The MCL allows for both non-commercial and commercial modification and redistribution of licensed software and carries a per-file reciprocal term.  

The MRL is a reference-only license that allows licensees to view source code in order to gain a deeper understanding of the inner workings of a Microsoft technology. It does not allow for modification or redistribution. This license is used primarily for technologies such as development libraries.


Microsoft has a “spectrum” of licenses under the Shared Source Initiative. But, just as with other individuals and organizations we too have seen the proliferation of source code licenses become problematic. We had 10+ Shared Source licenses and as more and more product groups sought to use source code releases as a means to work with developer communities, this number was only going to rise further.


3 is better than more than 10.


I’d like to thank two great attorneys for their work on these licenses. Steve Mutkoski and J.D. Fugate did a great job of pushing for simplicity and clarity. These guys deeply understand the nature of source licensing and the issues facing developers needing to work with the code. 



Commentary - some good, some bad - but all interesting takes on the same thing.


Comments (6)
  1. First, congrats for the careful and clear wordings of those three licenses.

    I hope, though, that existing MS-copyrighted projects under BSD3 license would not be made to relicense into Ms-PL-only, as although MsPL is indeed permissive, it still seems to be a one-way conversion from BSD3.

  2. How does the Ms-PL interact with GPL licensed code? May they be combined in a single work distributed as source?

    Which license will future versions of IronPython be released under?

  3. Wesley Parish says:

    Firstly, Jason, might I add my voice to those congratulating you and the rest of Microsoft for clarity in licensing? They – for legal documents – are a pleasure to read. And much, much more intelligible than the standard EULA, which probably accounts for the standard behaviour of the standard user – click without reading … 😉

    But I’ve just had a look at the Shared Source Projects List:

    and am wondering how Microsoft is going to bring clarity out of that!

    To take for example the previous WinCE Shared Source License/s, which never impressed me:

    Adopting either the Permissive or the Community Licenses for the WinCE (bad name – it should be shot! 😉 development community – if they deserve that name – would put WinCE on a par with either the Linux or the OpenBSD/NetBSD embedded and real time communities, as far as licensing freedom goes. It would also signal the movement away from selling WinCE as a product to selling a service, based on the reasonable assumption that Microsoft knows the product better than anyone else. (It is after all, the same premise on which Linus Torvalds has built his reputation, and following him Red Hat and others have built businesses.) While adopting the Restrictive License would leave the WinCE development community feeling cheated.

    But retaining the current license on the grounds that nothing’s going to be grandfathered, may well be very unpopular. When you’re as close to the wind as most embedded manufacturers are, the simpler and more concise your licenses are, the less you waste on lawyers, bureaucrats (aka guns) and money.

    Decisions, decisions, decisions! The die is cast – which face will it show now?

  4. Wesley Parish says:

    If I might make an additional comment to the previous one above – the WinCE collection/collation of Shared Source Licenses is an ideal place to start rationalizing the license proliferation and reducing Microsoft’s previous license confetti and spaghetti.

    I take it from the presence of the WinCE Academic License that Microsoft sees the value of reaching students. I can see the value of a relatively open WinCE Embedded System licenses. What I can’t see is the use of them to Microsoft if you need to do some sort of License Hurdling to get from studying the source code in some tertiary institution to working on the self-same code at a manufacturers.

    In addition, Microsoft has come in for quite a bit of flack due to the various non-obvious ways it has changed its API on the way from Win 3.x to Win2k3.

    Might I suggest that Microsoft look very seriously at relicensing the WinCE source tree to all current and future licensees under the Microsoft Permissive License, and at the same time submitting it as the reference Win32 API implementation, to the appropriate standards body?

    I’m not joking. I think Microsoft has a lot to gain from such a move. As indeed the rest of the computing industry and communities.

  5. Port 25 says:

    When I first started writing software, my only understanding of the term ‘license’ was that it was something I needed to drive a car or to catch fish. As my career progressed, I learned that software also has licenses that describe – ideally – how the

Comments are closed.

Skip to main content