"At OSI we have seen that the process of growth in Open Source is more evolutionary than revolutionary. We invite public debate with each successive wave of newcomers to start the process to close the gap between what they imagine Open Source to be and the reality of what is required (and why)."
Danese Cooper, Board Member of the Open Source Initiative
The Open Source Initiative or OSI and the Free Software Foundation or FSF share a common goal: that everyone should be free to modify and redistribute the software they commonly use. 'Should' is of course a normative word. For the FSF, 'should' is a moral imperative. Anything else is an immoral restriction on people's activities, just as are restrictions on speech, press, movement, and religion. For the OSI, freedom is a necessary precondition for a world where "software doesn't suck", in the words of a founder of the OSI.
The FSF started from its founder's GNU Manifesto widely published in 1985. Given the manifesto's hostility to copyright, and given the failure of the Free Software Foundation to gain any traction amongst commercial users of software even with a 13-year head start, a group of people gathered together in 1998 to talk about a new strategy to get the corporate world to listen to hackers. They were impressed by Eric Raymond's Cathedral and the Bazaar's take-up among business leaders.
Origins of the Open Source Definition
The term 'open source' emerged from the efforts of this group of people frustrated by the multiple meanings of 'free' and its failure as a marketing term. On the one hand, 'free' is good, because everybody wants to get something for free. To the Free Software Foundation 'free' does not mean the absence of a price tag; they want 'free' to mean freedom. Further, when businessmen look at what they get for 'free', they may think 'worth what I spent' and equate zero cost with zero value. The term 'open source' aims to lose that luggage.
The other source of frustration has been the insistence that the free software movement is about morality and that 'free' software is the only moral choice. As soon as you say that, you put off people who disagree. "Oh, you mean I'm a bad person?" "No, you're just doing a bad thing." "As if that's any better!" If you want to sell a foreign idea to people, you have to start by not judging them as immoral.
Two members of the group that picked the name open source as a marketing term for free software were more excited than the others: Eric Raymond, author of the Cathedral and the Bazaar, and Bruce Perens, former leader of the Debian GNU/Linux project. They wanted to be an organization, not just two individuals, so they sought board members to guide an organization to stand behind their efforts. As a marketing term, 'open source' is great; they decided to harden its meaning a bit, by seeking a trademark to be licensed to anyone who met a fixed definition. Bruce had put a lot of effort into Debian's Free Software Guidelines or DFSG, so he imported those guidelines into the Open Source Definition or OSD. In time, the decisions to seek a trademark and be based on the DFSG would be seen as flawed. The United States Patent and Trademark Office objected to 'open source' as being too descriptive, and refused to grant the OSI a trademark. As the OSI discovered, a trademark cannot simply describe the good or service being trademarked; there needs to be more creativity involved. While open source is very descriptive, which is part of its power and attractiveness, a good trademark it is not. Instead, the OSI established the "OSI Open Source Approved License" standard.
Reuse of the DFSG has also proved problematic. First, it created resentment on the part of Debian, whose members felt it was improperly reused. Second, it was never meant to be a bulwark against hostile redefiners. Many would-be open source abusers have pointed out that the OSD doesn't require distribution of the source code. In the form of guidelines for Debian, the DFSG never needed such completeness. Due to its culture and underlying philosophy, the Debian project would never begin to consider the inclusion of software without source code.
Since its inception, the OSD has needed some terms added to it, and some terms revised. For example, when some open sourcers threatened to require that redistributors acquire positive acceptance of the license by click-through, we added OSD #10, which prohibits license stewards from requiring any particular technology in licensing. The difficulty from the licensor's point of view is that court precedents existed to defend click-through licensing. The difficulty from the licensee's point of view is the impossibility of clicking through every license in a distribution. Some would-be software distributors thought that they could simply not include the source, and still use the open source label. We clarified our intent in OSD#2 which states that "The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed."
OSD#9 originally stated that the "License Must Not Contaminate Other Software". However, what does "Contaminate" mean? It sounded like imprecise language, so we changed it to say "Restrict" instead.
Even Debian has seen the need to change their DFSG. Their community process is such that any change would be painful. So, rather than change the text of the DFSG, the people on the debian-legal mailing list have added extra requirements which exist as a form of case law. If you try to submit software that only complies with the DFSG, it still might not get into Debian because of these extra requirements.
There was a private effort made, a few years ago, between Software In The Public Interest (the legal owner of Debian) and the OSI to try to reconcile the DFSG with the OSD. This failed because of the conflicting goals of the two documents. Although textually similar, the DFSG is used to decide what software goes into Debian, while the OSD is used to decide what software gets to claim to be open source software. One thing that readers must know is that while the OSI tries to work with license stewards to get the best possible license, we don't require it. We've approved licenses where we've all looked at each other, shook our heads sadly and said "That license just isn't gonna be widely used." But we're not infinitely wise, so we gave the license its due as abiding by the definition of open source.
Sometimes, license stewards approach the OSI with flexibility in mind. I recall a conference call with the lawyers at NASA. They worked with us to ensure that the NASA Open Source License would work not just for NASA, but for any U.S. Federal Government agency wanting to release software as open source.
Microsoft, to their credit, produced a fairly open-source-sounding set of licenses in their Ms-Pl and Ms-Cl without needing to consult with us. They did ask about any speedbumps when they submitted their licenses for approval. Of course they know full well their reputation in the open source community, so they didn't want to make any trivially avoidable mistakes in their submission.
Beyond the Definition
Open source has proven to be such an alluring concept that you see open source hardware, open source radio, and open source movies. The concept is applicable to anything which has separable design elements. So open source hardware would be fully documented, modular, with separate parts available for sale. The Lego Group has adopted this idea with its Lego Mindstorms and NXT products. People have created alternate devices and even alternate firmware to download into this hardware. Open source radio acknowledges that radio, while a stream of audio, occurs in a context, and the quality is improved when that context is open to contributions from all listeners. Open source movies such as Elephants Dream, consist of many elements such as audio tracks, animation models, textures, and plot. By distributing the movie not just as a finished product, but in separable design elements, watchers can contribute changes, or even compose their own movie from the elements.
Our success in promoting open source processes is a blessing and a curse. The more people who understand what open source means, the less likely anyone is to succeed at corrupting the term. On the other hand, we risk losing control over the use of the term and thus the meaning of it. That's why we have the "OSI Approved Open Source" program.
We've been so successful in propagating the open source brand that some people say there are too many open source licenses. From the perspective of somebody who wants to redistribute a distribution, this makes sense. They have to do the due diligence of researching the import of every license on every piece of software that the distribution includes. We appreciate both views: that there aren't enough open source licenses and that there are too many licenses. Even Microsoft wants their own open source license pair (public and community) approved. We try to seek a balance by assigning attributes to licenses depending on what categories they fit into. We've even convinced some license stewards to deprecate the use of their licenses; they're still open source licenses, but they shouldn't be used. All this open sourcing is also at risk from patents on ideas rather than mechanisms. Software being fundamentally an idea, it seems improper to patent it. Yet that's where we are, and the patent juggernaut seems to roll on. The patent system is supposed to be used to protect mechanisms, so that people who invest in building these mechanisms can have exclusive rights to these mechanisms. Unfortunately, in the USA, that a mechanism which can be built using software has been interpreted to mean that software can be patented. Unfortunately, many previously invented software mechanisms have been patented. Software patents are allowed even when they are obvious to any skilled practitioner of the art. This is very bad when software patents get written into standards documents, because that prohibits open source implementations. We're pushing back with our "Open Standards Requirement for Software". This is a new program whose details are not completely settled yet.
You can help us. Look for the OSI Open Source Approved License on your software. We're a non-profit charity, so you can contribute, which helps our advocacy efforts. And when the Open Standards Requirement is firmed up, you can ask for the Open Standards Requirement for Software when you adopt standards.
Perens, Bruce, The Open Source Definition
Stallman, Richard M., Why "Free Software" is better than "Open Source"