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.