I was reading this interview with Richard Stallman on KernelTrap today. It's always interesting how a Stallman/GNU article brings out all the zealots, both for and against free software. The comments about the interview were of course even more voluminous than the actual interview itself. I have watched the FSF develop for decades now and this has always been the case from the very start. I remember reading some of the first Stallman writings in the 1980s and thinking, "Hmmm... this guy is probably crazy, but if he pulls it off, wouldn't that be interesting?" Here are some other thoughts on GNU, Open Source, and Free Software, formed over a very long period of time (in other words, if you write to me to debate these, you're unlikely to change my mind unless you happen to come up with something very incisive that I have somehow not considered ;-):

First, let me say that the one thing I disagree with very strongly is RMS's statements that non-free software is immoral and "antisocial." Proprietary software is what it is. If you don't want to buy it because it doesn't meet your need for having the source available and being able to hack on it, fine, but don't go around suggesting that other people are stupid for doing so. As long as nobody is forcing people to use non-free software, all software licenses are just options in the market place and will be adopted by various people depending on what they offer. The freedom to hack source code is just one more "feature" of the product, nothing more.

Similarly, don't suggest that corporations that produce non-free software are somehow evil and corrupt. Again, as long as they aren't somehow forcing people to buy their products, they are just one option in the market place. If they can make money selling non-free software, then obviously "freedom" isn't all that it's cracked up to be. Whenever anybody writes the phrase "corporation producing non-free software," most people think specifically of Microsoft. Note that I don't begrudge Microsoft their ability to field a product in the market and charge whatever they think their customers will pay for the product. However, some of Microsoft's past business practices were definitely oriented toward limiting competition and choice of consumers and I think they have gotten off pretty light in return for decades of anti-competitive behavior. The point is, when you hear the phrase "corporation producing non-free software," it's much better to think of somebody like Adobe, Macromedia, etc., than Microsoft.

Whenever one starts discussing free software, GNU, or Stallman, it's important to remind everyone that "free" in this context means "as in speech," not "free as in beer." Stallman is not saying that you can't charge for bits, just that once you have sold those bits, you can't prohibit somebody from taking the same bits, possibly with modifications, and propagating them downstream for whatever price they want, possibly for zero cost, and so on... In other words, RMS isn't suggesting a software economy where no money ever changes hands; rather, he's advocating an economy where source code always changes hands and people have the freedom to make alterations to a product and then redistribute the resulting hybrid product.

Whenever RMS gets interviewed, somebody always starts throwing around the "communist" label and suggesting that such subversive ideas will lead to the destruction of the software industry. I think such fears are overblown. However, I also think that the FSF's economic theories have a couple problems. Here's the way I see it:

• Freedom to innovate on top of other people's work is a good thing. It's certainly the case that a group of talented people can do more than a single person and that you can't ever predict where the next talented person will come from. By allowing information to flow more freely, you allow it to reach those with the talents and dispositions to use it to build something better than what has gone on before.

• Now, that's great for raw ideas, but ideas are not software. Ideas are abstract things that, while they take talent to conceive of, take far more effort to reduce to practice. For instance, I have "designed" many, many computer programs in my head that I have never reduced to running code. Producing running, debugged code is hard. To be awarded a patent for anything (ignore the sensitive issues surrounding software patents here and focus on even hardware patents), the patent office requires an inventor to reduce it to practice. In other words, raw ideas are great, but an embodiment of those ideas is actually something of value because it required lots of effort to perform that reduction to practice. Simply thinking, "Wouldn't it be great if there was a piece of hardware/software that performed function X?" isn't the same as actually building such a thing.

  So the question here is how people working to reduce great ideas to practice are going to eat in the mean time. Every economic theory has to answer this question. All philosophy about the exchange of knowledge and ideas will lead absolutely nowhere if you can't answer the question of how people eat.

• The thing I like about the GPL and FSF is that it does promote the ability of people to build onto the work of others. It says, "Hey, it's a great thing to have the source code/schematics/plans/internal details for a widget available such that if it doesn't work quite the way I want as a consumer, I can modify it to do what I want." That's a nice feature of a product and promotes innovation on top of the product. I don't believe that the "has source code available" feature is required in every product, however, or is somehow a right of a consumer. I do believe that it is a right to be able to choose such, however, as long as there is a producer willing to give it to me.

• The main problem that I see with the GPL economically is that it then allows somebody to redistribute the original work without giving any economic benefit to the original creator of the work. The way to look at this is with the concept of a value chain. In the world of physical products, producer A creates widget A. Producer B buys widget A from producer A and transforms it (modifies it, incorporates it, etc.) into widget B. Producer B then sells to C, and so on, until the good is finally consumed by somebody at the end of the chain. The important concept here is that in the world of physical goods there is money flowing back from the consumer to everybody along that chain.

  With the GPL, producer A can make software and even sell that software to producer B. Producer B can take that software and create a modified product, but then producer B can sell that code to producer C without any obligation to pass on any of that value to producer A.

  The FSF theory states that this is okay, since producer A is entitled to get any modifications of its software from producer B and sell them for any price it wants. In other words, you get my stuff, but I get yours, so it all works out. I can't limit your freedom and you can't limit mine. I view this simply as a software version of mutually assured destruction. In practice, bits become free (as in beer) as a result. This is not necessarily a problem as long as we can still find a way for the developers who wrote the original code (or even the modifications by B) to eat.

  FSF advocates respond to the charge that bits become free by suggesting that people will then derive compensation for their work by doing other things like support, training, selling documentation, etc. This is problematic for a number of reasons:

  • Development is difficult and support is a necessary evil. As a business, I'd rather spend all my time developing my product and as little time supporting it as possible. If I do the reverse, it means I have lots of customers with issues and my product is stagnating in the market. If I'm deriving my revenue from support, I'm actually incentivized to spend as much time on support as possible and as little on development as possible, leading to exactly the reverse of what we'd like as consumers.
  • It is difficult to differentiate on support. There are many organizations that can support all sorts of different products. This is particularly the case with open source where the source code is available. As the developer of that product my revenue stream is being undercut by competitors that are not burdened with my development costs. Put another way, in this model, another business is actually incentivized to let everybody else do the development and then come in and skim off the support revenue (say business C comes in and supports the system created by A and B and doesn't give anything back to either one).
  • At this point, people often speak up about "community" and giving something back. Business C is bad, they would contend, if it simply reaps the rewards without doing some innovation itself. While I'm all for developing a good community and fostering community spirit, let's de-cloak that word and call it what it really means in this context: charity. While business C might have some sort of tacit moral obligation to not simply ride somebody else's coat tails, it is under no legal obligation to do so. In practice, there will always be at least one business like C, which will then gain competitive advantage by not shouldering the development costs. Whether C is ultimately successful depends on how much the "community" values "community spirit" (do they buy from C or avoid C because it is riding coat tails and therefore C is populated by bad people).
  • In summary, if you're going to create a sustainable system, you need to find a way to tie revenue to effort as directly as possible. Any model which says "give this away and make it up over here" is going to create stresses on the system which can eventually cause it to fail. Can sustainable "loss leader" systems be produced? Yes, they can and there are many examples, but they need to be very carefully thought out and I don't think most FSF advocates have done much more than a hand wave here. In other words, certain product categories will do better here than others. Examples supporting the case include complex systems like JBoss where people inherently need training, etc. Examples against include anything that will be used by consumers who don't have time for training and don't want to be calling a 1-900 number for support.

Whew! So what does all this mean? Am I down on either free software, the FSF, the GPL, or RMS? No, not at all. I think free software is a great thing, but I think there is definitely a place in the world for non-free software. I don't buy into the ideology that non-free software is morally wrong and "anti-social." I believe that the amount of free software will reach equilibrium in the market according to the revenue that people are able to derive off of other sources associated with it. In short, if everybody spent all their time writing software for which they didn't derive compensation, they would shortly not be able to eat, they would die off, and would be replaced by developers with a better understanding of economics. Insofar as people want to contribute their work to the market place under various open source terms and conditions (the GPL, Apache, BSD, and even public domain), I think that's a great thing. But we need to recognize that this is a gift from such developers and not expect it as a fundamental consumer right.

As a last point, let me suggest that free software works best for more fundamental pieces of technology that are commoditizing and have an inherent need to be low cost in order to achieve widespread adoption. Things like web servers and operating systems are good examples. More specialized applications which generate lots of downstream revenue dollars for their users are more willing to be paid for. Whether source code comes along with those applications as a feature of the product sale is just that, a feature to be negotiated between the producer and buyer. An example here might be a specialized piece of video editing software used by a movie production company where the company derives millions of dollars of revenue from such a product.

Finally, let me note that it's interesting that some of the free Lisp implementations out there, notably CMUCL and SBCL, are public domain, with no license whatsoever (use the code in whatever way you wish).