Wednesday, January 05, 2005
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).
I dont want flame with you, but just add a comment because your entry make me think about it.
- The right to have source code
Having the source code is not only meant as to develop on it, but also to study it. In old-economy industry i can ever study the widget i use(because i see it), so i can be sure that this widget is not harmful for me. Where not, law tells producer to publish information on their widget (don't you consider that is it your right to know the ingredients of what you eat?). Source it isnt an added value for hackers, but an insurance(warranty) for all.
(Reply: Ok, but to have it, we need only a sort of qmail license)
Furthermore ClosedSource with the net strategy drive us toward the monopoly (think about macromedia flash and microsoft word). When a closedsource spread around the world, you are constrained to use and buy it.
(Reply: ok but the problem is the protocol sws communicate, not the way the work)
- Custom Software
I think you should consider the concept of custom software (you can find it on gnu site). For Custom Software there isnt free/non-free problem.
- Chain of Value
Ever consider the nonfree-scenario:
a or b or (everyone working) could get paid for their work. That is free market.
Non Free Software
only 'a could sell and modify sw, he sold. Less people/value/money/food moves. That is monopoly market.
Sorry for my english
At last i want to congratulate with you for your blog, your site and your activity for lisp and free software. i am just another lisp-lover
This isn't an attempt to change your mind about Free Software! But I think there's one mistake in your account. You write:
"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 embodyment 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."
As far as I can tell, at some point Congress pretty much tossed out the "reduce to practice" requirements in patents, or perhaps the new software and business practice patents effectively provided such loopholes as to trash it. But it seems like one of the problems of the current U.S. patent system is that you can file a patent just on the basis of some wifty idea. The patent examiners are too swamped to pay much attention, and challenging them is too hard.
On the other hand, in the old days, when there were no software patents, it seemed like the tradeoff was better. A lot of times it would just be cheaper to buy software from someone else because, as you point out, developing good software is expensive and hard. But if the seller was charging an exorbitant price, or trying to hold some innovation off the market, you could legally reverse engineer it.
Software that's ONLY copyright protected, and not patented, provides a situation offering much more freedom to innovate, and consumer freedom to use.
Nope, the patent office still requires you to reduce an invention to practice such that a person of average skill in the art can reproduce what you are patenting. Naturally, this is subject to some interpretation, but generally most patents are fairly detailed. If you think about the intent of a patent, to grant the patent holder a limited monopoly in return for putting the knowledge into the public domain, you need things to be at a level where the patent application is useful to the public after the patent expires. Because of this, there has to be enough detail in there. So, the requirement still exists, but I don't deny that some patents don't necessarily live up to the ideal.
Post a Comment
Links to this post: