| Next: The Economic Engine Behind Up: Giving It Away Previous: The Strategic Appeal of |
NASA, the outfit that rockets people off into outer space for a living, has an expression: ``Software is not software without source code.''
To the engineers at NASA, high reliability is not good enough. Extremely high reliability it not good enough. NASA need perfect reliability. They cannot afford to suffer the ``blue screen of death'' with twelve trusting souls rocketing at a thousand miles an hour around the earth, depending on their systems to keep them alive.
NASA needs access to the source code of the software they are using to build these systems. And they need that software to come with a license that allows them to modify it to meet their needs. Now I'll admit that the average dental office billing system does not need the standards of reliability that NASA astronauts depend on to bill patients for their annual teeth cleaning, but the principle remains the same.
And unlike proprietary binary-only OSes, with Linux our users can modify the product to meet the needs of the application they are building. This is the unique value proposition that Red Hat offers our customers. This is the proposition that none of our much bigger competitors are willing or able to offer.
This is a value proposition that overturns usual notions of intellectual property. Rather than using a license to lock customers in and wall them off from the source code, Red Hat needs a license that embodies the very idea of access to and control over source code. So what is an acceptable license for the purpose of delivering this unique value proposition? Reasonable people in the Open Source community can and do differ in how they answer this question. But at Red Hat we do have our current opinions on the subject and here they are:
The General Public License from the Free Software Foundation is in the spirit of Open Source and, because it ensures that the modifications and improvements made to the OS remain public, most effective for managing a cooperative development project.
Our definition of ``effective'' goes back to the old days of Unix development. Prior to 1984, AT&T used to share the source code to the Unix OS with any team who could help them improve it. When AT&T was broken up, the resulting AT&T was no longer restricted to being a telephone company. It decided to try and make money selling licenses to the Unix OS. All the universities and research groups who had helped build Unix suddenly found themselves having to pay for licenses for an OS that they had helped build. They were not happy, but could not do much about it -- after all, AT&T owned the copyright to Unix. The other development teams had been helping AT&T at AT&T's discretion.
Our concern is the same. If Red Hat builds an innovation that our competitors are able to use, the least we can demand is that the innovations our competitors build are available to our engineering teams as well. And the GPL is the most effective license for ensuring that this forced cooperation among the various team members continues to occur regardless of the competitive environment at the time.
Keep in mind that one of the great strengths of the Linux OS is that it is a highly modular technology. When we ship a version of Red Hat Linux we are shipping over 435 separate packages. So licensing also has a practical dimension to it. A license that enables Red Hat to ship the software but not make modifications to it creates problems because users cannot correct or modify the software to their needs. A less restrictive license that requires that the user ask the permission of the original author before making changes still burdens Red Hat and our users with too many restrictions. Having to ask possibly 435 different authors or development teams for permission to make modifications is simply not practical.
But we are not ideological about licenses. We are comfortable with any license that provides us with control over the software we are using, because that in turn enables us to deliver the benefit of control to our customers and users, whether they are NASA engineers or application programmers working on a dental office billing system.