More Open Than Open

<p>对开源协议的一些看法，from微软。 <p>Today I sat on a panel with Matt <br />Asay of Novell, Dan Frye of IBM and Tim Witham of the OSDL – three deep thinkers <br />on the topic of OSS and people for whom I have a great deal of respect. We were <br />speaking to an audience of CIOs in Portland, OR – <br />my home town. The panel discussion was fine, a pretty standard set of points <br />were made about the nature of open source and how it is going to affect decision <br />making for CIOs. I’m sure my blog will eventually have my normal shtick about <br />the commercialization of open source – but for now I would like to talk about <br />something that Matt, Dan, Tim and I talked about before we ever got on stage. </p> <p> </p> <p> <p>What is “open?”            </p> <p> </p> <p> <p>After literally thousands of <br />discussions, panels, debates, arguments, commiserations, smoke signals and some <br />lewd sign language, I am constantly amazed at the flexibility of this single <br />word. There are <b>open</b> systems, <b>open</b> sciences, <b>open</b> standards, <b>open</b> architectures, and <b>open</b> source licenses. There are some <b>open</b> source licenses that are more <b>open</b> and some less. I think Orwell <br />would have loved this – after all, some animals are more equal than others. Can <br />one <b>open</b> source license be more <b>open</b> than another <b>open</b> source license? </p> <p> </p> <p> <p>Yes, it can.</p> <p> </p> <p> <p>I went to the <a href="http://encarta.msn.com/dictionary_/open.html">Encarta website and looked <br />up “open.”</a> Wouldn’t you know it, it prints off to 7 pages of definitions. <br />Hmmm, this might be more of a challenge than I thought. I like definition #2 <br />from Encarta, “allowing access to the inside: with the lid, cork, or other <br />device removed or in a position that allows access to the inside.” This seems to <br />fit well. At the heart of the discussion of open source as a licensing model is <br />the idea of transparency. Can I see the source code – is it available to me to <br />review? I think #8 layers on nicely, “receptive: ready and willing to accept or <br />listen to something, for example, new ideas or suggestions.” I think the source <br />access should give me a creative boost, a set of information from which new <br />ideas and options may flow. #22, though, is where things start to run afoul: <br />“not having legal restrictions: not having restrictions that limit activities…” <br />The most common argument for reciprocal licenses is that you must limit rights <br />in order to guarantee freedoms. In other words, make use of legal restrictions <br />in order to enforce openness. (I’ll get back to this.) Of course, if you follow <br />many software projects (open source or not), they seem to adhere more to #18, <br />“empty bowels: to cause the bowels to evacuate.”</p> <p> </p> <p> <p>I think there are three core layers <br />of source licensing. Reference (review-only grants), Permissive (attribution <br />derivative grants), and Reciprocal (restrictive derivative grants). Each has a <br />purpose and a time for use. In Microsoft’s work on the <a href="http://www.microsoft.com/sharedsource" title="">Shared Source</a> Initiative, we <br />have never limited ourselves to using only one of these models. There is beauty <br />in diversity, and our approach to source licensing is completely in line with <br />this thought. </p> <p> </p> <p> <p>Reference grants are “open” in that <br />they give access for viewing the code, but they’re closed in that they place <br />restrictions upon the licensee to use that code as they would an encyclopedia. <br />They can help licensees do their work more effectively but not modify the <br />original work. From the Microsoft perspective, this is what we have done with <br />our core assets: Windows and Office. I argue that this is what the Linux source <br />code is good for as well. Most Linux support contracts specify that no <br />modifications of the source are allowed. Well in excess of 99 percent of <br />developers who look at Linux source code will never modify it – but they will <br />absolutely use it as a reference mechanism. But I digress – clearly the source <br />licenses in Linux (check out <a href="http://asay.blogspot.com/">Matt Asay’s <br />March 3rd, 2005 </a>break down of licenses in SuSE) permit the modification of <br />the code – it just is not practical that people would or want to. </p> <p> </p> <p> <p>Permissive grants are generally <br />based on the <a href="http://www.opensource.org/licenses/bsd-license.php">BSD <br /></a>style of license. There are terms that cover attribution, but that’s about <br />it aside from CYA disclaimers. To me these are the most “open” of licenses <br />because they provide the ability to view, modify and distribute <u>as the <br />licensee sees fit</u>. In other words, they can take that code and possibly use <br />it in a private manner, for commercial gain, and not share it back with the <br />community. They can modify the code and contribute it back for everyone to see <br />and use. They can use it as a paper weight – as long as they give proper <br />attribution. Back to Encarta #10, “not enclosed: having no boundaries or <br />enclosures.” I fundamentally disagree with the idea that the creation of <br />boundaries or disclosures in order to maintain openness is the most open path <br />you can take.</p> <p> </p> <p> <p>Reciprocal grants are generally <br />based on the <a href="http://www.opensource.org/licenses/gpl-license.php">GPL <br /></a>style of license. Microsoft has a colorful history with this license, but <br />the fact remains that this is a pervasive form of licensing. If one is to deeply <br />understand the nature of OSS, one has to think through reciprocal <br />licensing. In fact, we have three <a href="http://www.microsoft.com/sharedsource">Shared Source </a>projects (<a href="http://sourceforge.net/projects/wix">WiX</a>, <a href="http://sourceforge.net/projects/wtl">WTL</a>, and <a href="http://sourceforge.net/projects/flexwiki">FlexWiki</a>) under a reciprocal <br />license, the <a href="http://http//www.opensource.org/licenses/cpl1.0.php">Common Public <br />License</a>. From a strategic business use point of view, reciprocal licenses <br />are interesting in that you can make sure a piece of code put into the community <br />cannot be picked up by your competitor to be used against you in a way that you <br />won’t also be able to use to your own advantage. At a simplistic level, there is <br />a fairness to a reciprocal grant: if you want to play with my toys, I get to <br />play with yours (and you always have the option not to play with my toys at all <br />if you don’t want to share yours). Yet, these licenses are predicated on the <br />idea that you must restrict rights in order to accomplish the goals of the <br />philosophy behind the license. Thus, they are not as open as the permissive <br />grants.</p> <p> </p> <p> <p>I suppose it is worth noting here <br />(with a nod to the <a href="http://creativecommons.org/">Creative Commons</a>), <br />that public domain grants are the <u>most</u> open in that they have no <br />limitations on use. </p> <p> </p> <p> <p>The most important factor to me is <br />that a developer or organization has the freedom to choose what type of license <br />works best for each individual project. In <a href="http://www.microsoft.com/sharedsource">Shared Source</a>, we have 17 <br />offerings, and we use all three types of licensing. Our focus is not on whether <br />or not something meets the OSI definition of “open source.” The focus is instead <br />on whether or not, for that given technology, the community most interested in <br />working with the source code has the ability to accomplish what it needs <br />to.</p> <p> </p> <p> <p>So what is the most “open” for you? </p> <p> </p> <p> </p> <p> <p>This posting is provided "AS IS" <br />with no warranties, and confers no rights.</p>