More Open Than Open

Today I sat on a panel with Matt Asay of Novell, Dan Frye of IBM and Tim Witham of the OSDL – three deep thinkers on the topic of OSS and people for whom I have a great deal of respect. We were speaking to an audience of CIOs in Portland, OR – my home town. The panel discussion was fine, a pretty standard set of points were made about the nature of open source and how it is going to affect decision making for CIOs. I’m sure my blog will eventually have my normal shtick about the commercialization of open source – but for now I would like to talk about something that Matt, Dan, Tim and I talked about before we ever got on stage.


What is “open?”            


After literally thousands of discussions, panels, debates, arguments, commiserations, smoke signals and some lewd sign language, I am constantly amazed at the flexibility of this single word. There are open systems, open sciences, open standards, open architectures, and open source licenses. There are some open source licenses that are more open and some less. I think Orwell would have loved this – after all, some animals are more equal than others. Can one open source license be more open than another open source license?


Yes, it can.


I went to the Encarta website and looked up “open.” Wouldn’t you know it, it prints off to 7 pages of definitions. Hmmm, this might be more of a challenge than I thought. I like definition #2 from Encarta, “allowing access to the inside: with the lid, cork, or other device removed or in a position that allows access to the inside.” This seems to fit well. At the heart of the discussion of open source as a licensing model is the idea of transparency. Can I see the source code – is it available to me to review? I think #8 layers on nicely, “receptive: ready and willing to accept or listen to something, for example, new ideas or suggestions.” I think the source access should give me a creative boost, a set of information from which new ideas and options may flow. #22, though, is where things start to run afoul: “not having legal restrictions: not having restrictions that limit activities…” The most common argument for reciprocal licenses is that you must limit rights in order to guarantee freedoms. In other words, make use of legal restrictions in order to enforce openness. (I’ll get back to this.) Of course, if you follow many software projects (open source or not), they seem to adhere more to #18, “empty bowels: to cause the bowels to evacuate.”


I think there are three core layers of source licensing. Reference (review-only grants), Permissive (attribution derivative grants), and Reciprocal (restrictive derivative grants). Each has a purpose and a time for use. In Microsoft’s work on the Shared Source Initiative, we have never limited ourselves to using only one of these models. There is beauty in diversity, and our approach to source licensing is completely in line with this thought.


Reference grants are “open” in that they give access for viewing the code, but they’re closed in that they place restrictions upon the licensee to use that code as they would an encyclopedia. They can help licensees do their work more effectively but not modify the original work. From the Microsoft perspective, this is what we have done with our core assets: Windows and Office. I argue that this is what the Linux source code is good for as well. Most Linux support contracts specify that no modifications of the source are allowed. Well in excess of 99 percent of developers who look at Linux source code will never modify it – but they will absolutely use it as a reference mechanism. But I digress – clearly the source licenses in Linux (check out Matt Asay’s March 3rd, 2005 break down of licenses in SuSE) permit the modification of the code – it just is not practical that people would or want to.


Permissive grants are generally based on the BSD style of license. There are terms that cover attribution, but that’s about it aside from CYA disclaimers. To me these are the most “open” of licenses because they provide the ability to view, modify and distribute as the licensee sees fit. In other words, they can take that code and possibly use it in a private manner, for commercial gain, and not share it back with the community. They can modify the code and contribute it back for everyone to see and use. They can use it as a paper weight – as long as they give proper attribution. Back to Encarta #10, “not enclosed: having no boundaries or enclosures.” I fundamentally disagree with the idea that the creation of boundaries or disclosures in order to maintain openness is the most open path you can take.


Reciprocal grants are generally based on the GPL style of license. Microsoft has a colorful history with this license, but the fact remains that this is a pervasive form of licensing. If one is to deeply understand the nature of OSS, one has to think through reciprocal licensing. In fact, we have three Shared Source projects (WiX, WTL, and FlexWiki) under a reciprocal license, the Common Public License. From a strategic business use point of view, reciprocal licenses are interesting in that you can make sure a piece of code put into the community cannot be picked up by your competitor to be used against you in a way that you won’t also be able to use to your own advantage. At a simplistic level, there is a fairness to a reciprocal grant: if you want to play with my toys, I get to play with yours (and you always have the option not to play with my toys at all if you don’t want to share yours). Yet, these licenses are predicated on the idea that you must restrict rights in order to accomplish the goals of the philosophy behind the license. Thus, they are not as open as the permissive grants.


I suppose it is worth noting here (with a nod to the Creative Commons), that public domain grants are the most open in that they have no limitations on use.


The most important factor to me is that a developer or organization has the freedom to choose what type of license works best for each individual project. In Shared Source, we have 17 offerings, and we use all three types of licensing. Our focus is not on whether or not something meets the OSI definition of “open source.” The focus is instead on whether or not, for that given technology, the community most interested in working with the source code has the ability to accomplish what it needs to.


So what is the most “open” for you?  



This posting is provided "AS IS" with no warranties, and confers no rights.

Comments (42)
  1. Rob Howard says:

    Great post. We’ve constantly battled what the term ‘open’ means with Community Server ( We do a mixture of Reference and Permissive with our application and source, yet some people don’t consider that ‘open’.

    For whatever reason many developers have been conditioned to think that ‘open’ is synonymous with ‘free’, i.e. if it’s not free it must not be open source.

    We’ve tried to straddle this by offering a ‘Community License’ which comes with all source but requires usages to display a logo at the bottom of every web page that uses it. And a commercial license that doesn’t have this restriction.

    For me ‘open’ means a willingness to share and transparency of process associated with building the software; it doesn’t always have to imply free too. A close study of any large open source project usually reveals some interested party who is paying the bills.

  2. Jason Matusow, who is Microsoft’s Director of Shared Source, has started a WebLog. Some initial points: In the early days of our Shared Source Initiative (SSI) there was far more controversy than there is today surrounding our releasing of source…

  3. Brooks Moses says:

    Rob’s point is a good one; it’s nice to hear someone besides Richard Stallman making that distinction.

    Back to the main topic, though, and the observation that the Linux kernel is functionally reference-grant because so few developers modify it. I can’t speak to Linux much, but I can speak to the core TeX processor, which is a very similar sort of thing in that it’s a very complicated code used by many and modified by few. While I have never looked at the code, much less modified it, for me it’s very functionally important that it was released in a form that wasn’t limited to reference-use-only. It’s important, because I benefit significantly as an end-user from the changes that other people have made — changes that (I think) might well not have happened if the ability to extend the code and modify it were limited only to specific licensees who paid for the privelege.

    (Incidentally, if one is concerned about product integrity in the face of allowing other people to freely modify the source and redistribute the product, the TeX and LaTeX licensing schemes are probably well worth looking into, as I think they handle that quite well.)

    Finally, on the actual question at hand: There’s another aspect to openness of open-source that I think is of vital importance, and that you didn’t mention at all: documentation (both as in-the-code comments and clarity of writing, and external documents). If I don’t have the information to understand how a bit of code works, then all of the open-source licensing in the world isn’t going to make it functionally open to me. This is, I think, one reason why doing open-source software right is hard work; it takes time to write thorough documentation, and it takes time to write it so that someone outside the project can understand it. Currently, the research group I’m working with is thinking of releasing a batch of code as open-source free software, and that’s the major barrier in the way of getting things to a releasable state.

  4. I think your blog is going to be a very interesting read… but I think you’re missing some important points.

    The first, and somewhat obvious one, is that open source is more then just two words; it’s a trademark of the Open Source Initiative, who has a pretty specific defintion, and some rather harsh words to say about the Shared Source license.

    While it’s true that most people who look at the linux sorce do not modify, it’s a long way from being effectively reference-only. A good many people do modify it, mostly just by applying patches others have written. A decent number do their own modifications, many of those send them on to other people; a few of them make modifications that eventaully get folded in to the mainstream kernel.

    But most importantly, third-party licenses (read: support contracts) limiting your ability to modify source code is something of a nonsensical argument. Of course, you can always choose to limit your rights, if you wish to. Or you can choose to not have support on some of your machines… but many people do not make that choice, and do not have support contracts.

    Linus puts out a kernel, and gives you recipricoral rights to use and modify it. (Actually, somewhat wider then strictly recriporical, but it works OK as a term.) You can choose to enter into other contracts with other people that are contingent upon not exercising those rights, but you made that chose to give them up, it wasn’t something you had no option on.

  5. EROL MVP SPS says:

    Hello your Blog on a French Blog


  6. Jonas Maurus says:

    You only consider reciprocal licenses from one perspective. From another, it’s also about investment protection. I can always fork, you can never it away from me again. It’s the argument that Mark Pilgrim makes in "Freedom 0". (<a href=""></a&gt; seems to be down, so <a href="">here‘s a Google Cache version</a>).

  7. This article focuses on the word "open" and thus totally misses the point. The term "Open Source" was coined in 1998 by Eric Raymond, Bruce Perens and others as a marketoid-speak with the exact same meaning as what the Free Software Foundation (FSF) calls "Free Software".

    If you examine the Open Source Initiative (OSI)’s definition of an "Open Source" you’ll see that it means practically the same as the FSF’s definition of free software:

    Mind you, the FSF and the OSI have different goals. The FSF people believes proprietary (non-free) software is immoral, whereas the OSI considers proprietary software as simply impractical and/or inferior for most uses.

    Let’s focus on the OSI’s position here: they want to see software as a comodity. They want to allow integrators to provide custom solutions based on a wide veraity of softwares. Linux distributions are the best examples for that.

    Linux distributors take free software packages from a variety of sources and pack them together to get a consistent package. If all of those separate packages were proprietary they would have never gotten the good packaging they get now, because the author cares about writing good software and doesn’t care that every user needs to repeat a number of (documented) steps to install the software on their system.

    As a more concrete example, take Asterisk. . This is a software for operating a PBX ( ).

    Asterisk is quite complicated to install. The authors don’t really mind that it takes a Linux guru to install and configure an Asterisk PBX, but others do care. The "taming" of Asterisk for an easier installation is not done by the core developers but by others. E.g. the company I work for provides a CD with a quick and simple installation of a complete Asterisk system.

    For me "free software" stands for a relatively efficient software development process where the parties don’t expect to earn money from selling software usage licenses (and cheating people into believeing them that they actually buy software) . Instead you can make money from support, serivces or hardware.

    Why the GNU GPL and not BSD/MIT license? because companies are greedy and short-sighted. They ignore the long-term gain from a large repository of free software and instead fork their own copy without giving back their modifications. The GPL (and copyleft licenses in general) have proven themselves over the last 20 years as an invalueble tool for preserving (and thus expanding) the repository of free software. This is a short summary of one of the sides of a long debate, but there is a reason why a considerable number of commercial products are distributed under the terms of the GPL.

    (examples of such producs: the MySQL database, the Linux-Mandrake distribution)

  8. More Open Than Open and all for the development community

  9. Michael Kale says:

    James brings up good points. The distinction between what you call Permissive and Reciprocal licenses is an interesting one, but I won’t get into that. I do think that there is a large difference between what you call Reference licenses and the other two. (And yes, I agree that reference licenses are useful, especially in the context of a product/platform actively maintained by a corporation but used by other developers.)

    I don’t think that the Linux kernel is anywhere near a reference license in practice. Just because 99.9% of people look at the code but never modify it does not mean that they don’t benefit from that .01% of people that *do* modify it. Linux (and BSD) as products exist today largely because of the contributions of those .01% of the people, and I’m guessing that those .01% of the people were at least partially motivated by the "open"ness of the license.

    Sure, corporations benefit from selling support contracts, and to prevent support from going out of control they want to put some limitations on what you can do to the source. That makes business sense, and I’d do it to. Users benefit from those support contracts too, and Linux benefits because of the increased useage, etc. But this is not the essence of what "Linux" is, and propping up RedHat or SuSE or whoever else is nice, but not the reason that Linux exists. Linux owes much of its success to those .01% of the people, and those people are not using it under reference license terms.

  10. Ben Martin says:

    I was tempted to comment on the part about the Linux license, but I think Michael just pretty much said what I wanted to say. I would add that a crucial point is that, regardless of whether anyone modifies the Linux source or not, it is important that they COULD if they wanted to – the Linux source never goes away legally, which positions it much better than the Windows source. And, as Michael said, if even 0.01% of people change it, that can still be significant.

    What I really wanted to say though was….

    I tend to agree with you that BSD-style licenses are the most open (and of course public domain is the ultimate level of open…). HOWEVER, there is one interesting aspect to recirprocal licenses you did not consider that in some ways does make them more "open." With the way the GPL works, it is not just that if I write some code I or my company get to see your code if you modify it, it is also the case that EVERYONE else still has access to the code. Under a BSD license, the licensor can close the code once they change it. Maybe that isn’t so critical, after all, they changed the code, why not get to keep the changes? But it is perhaps more democratic in some ways that EVERY change is open to the community (assuming they were going to distribute it in the first place, as the GPL still lets them use it privately in a closed manner). That isn’t really enough to make the GPL more "open" perhaps, but it is an intersting beneficial effect. If you want to play, you have to play nice with EVERYONE. You sort of addressed this, but I think it is significant that more than two parties are involved. In that sense, it is not so much about restricting YOU as much requiring you to keep the code open to everyone else, so it is sort of protecting other potential users. (I say "protecting" but of course it is much more proactive than that. You get the point though I think.)

  11. In terms of software, this:

    But the point is that "shared source" isn’t really open (bar few meaningless exceptions), given it doesn’t even come close to any of the above.

    To verify the true meaning of open, simply go to:

    This is a community based, fully binary compatible version of Red Hat Enterprise Linux. When you achieve something like that with Windows (I’m guessing around the time pigs start flying), then you can start contemplating the meaning of the word open again.

    Simple, no?

  12. Nektar says:

    What I would like to ask you is why have in your opinion GPL-licensed Linux-based operating systems been so successful, whilst BST-licensed Free / Open BST has not, even though as you say BST licenses are more open. Doesn’t the community take licensing issues seriously. After all, other BST-based projects, such as the Apatche and Mozila ones are very successful. What factors are there behind the building of these communities and to what extent is licensing an issue. Or, are these communities driven by good reputation and leadership rather than by ideological / licensing factors? Why has the GPL been so widely adopted? Has there been enough thought in open source (free source) communities before its adoption?

  13. Ivan says:

    Microsoft wants open source to be BSD, so they can take it and use it in windows, and sell it. If you want to commercial proprietary licencing for GPL code, why don’t you just make a reasonable commercial offer to the copyright holder? You’ll never get Linux that way, but it would seem more fair to me that if someone if going to make money out of code, some of that money should go to the author of the code.


  14. mdew says:

    But is it really more open than Open Source? Do I need to sign my life and soul away just to see and use the source? One thing I’ve loved about Open Source, is that accessability of the sourcecode, free to all, free to look at, and to use, just a small download away.

    What scares me is the longwinded Terms & Conditions Microsoft will set…scares you.

  15. Andy O says:

    I will tell you what open is NOT:

    The Puma about to go hunting in your livingroom.

  16. Jason, Thank you to Ed Daniel for pointing me here. We’re part of the Open Leader network. For us, Open is about active inclusion – reaching out beyond ourselves – so that others might be with us. We have a simple criteria for identifying our own leaders to rally around – those who generate original content into the Public Domain except as it notes otherwise. (See for ethical use of the Public Domain)

    I have submitted "Inclusive Culture" for the Microsoft Research Social Computing Symposium:

    From a business point of view, Microsoft could score big by open sourcing a search engine – allowing people to see how the search is calculated – and allowing access to the API. Currently, Google has in many ways a virtual monopoly which, frankly, I am not happy with. Google caches the whole Internet but does not allow its own pages to be scraped. Google offers an API but does not allow the results to be shown on the web. Google requires non-commercial use which is counter to fostering self-sustainment and social entrepreneurship. Microsoft could do better by creating an open source engine, developer’s kits, etc. Also, the opportunity for peer-to-peer social networking is huge So is the global opportunity for social networking kits optimized for marginal connectivity

    Our lab Minciu Sodas organizes global teams of independent workers I hope we might work together – please contact us through our wiki.

  17. There have been a lot of questions about Microsoft’s Shared Source program&amp;nbsp;and the Licenses that…

  18. In his&amp;nbsp;comment&amp;nbsp;to my last posting Wesley Parish&amp;nbsp;pointed out something worth&amp;nbsp;talking…

Comments are closed.

Skip to main content