The GPL: Understanding the License that Governs Linux -Part 2
Novell Cool Solutions: Feature
By Matt Asay
Digg This -
Posted: 11 Feb 2004
Editor's Note: This is the second in a three-part series in which Matt explores the GPL (GNU General Public License).
Americans have long believed property rights to be essential to development of that property; that ownership invites an incentive to improve one's property. As an example from the world of real property, if you felt that someone could arbitrarily take your home tomorrow, you likely wouldn't invest the time and sweat to finish the yard, paint the walls, etc. Intellectual property is the same. The Constitution allows limited monopolies (through patents and copyright) to provide incentives to authors and inventors to create new works. Innovation is born as the owners of this intellectual property develop and extend this property, just as ownership of my home can inspire me to make it better.
However, things are a bit different in the world of the GPL, and hence, with Linux. As noted in last month's article, the GPL creates a world of "anti-property." In this world, I only get if I in turn give all derivatives away (i.e., "open source" my innovation). (We'll bracket the issue of what constitutes a GPL derivative for a moment, to help Microsoft make their argument.). In this de-propertized software world, there seems to be a valid concern (most vociferously raised by Microsoft) that good software won't be created so long as no one person or company owns it, because there is no property incentive to induce innovation
Microsoft's Economics Lesson
Ever since Linux became a clear and present danger to Microsoft, they have filled computing magazines with stern warnings as to the GPL's stifling effects on innovation in software. As they (and other prominent legal scholars) have correctly argued, intellectual property law must balance between incentives to the producer of information and the consumers of such information. Too little protection (Microsoft's argument against the GPL), and nobody has an incentive to create new products, leaving an innovation vacuum for end consumers.
So much misinformation has proliferated about the GPL that commercial developers have tended to steer clear of it, leaving it to the uber techies who, as noted Open Source luminary Eric Raymond argues, find ego satisfaction and reputation among other developers to be sufficient incentives to induce participation in development of GPL code. Maybe. This is hard to prove and, in my experience, is only sometimes true. Software developers are human beings: they need money, just like I do, to buy that Lord of the Rings DVD.
More pertinently, even if true, there remains the question as to the general utility of the innovation their ego satisfaction/reputation pushed them to create. Unfortunately for you and me, these are the same developers who sport bumper stickers that say things like "Real geeks use command lines" and "GUIs are for wimps." If you don't believe me, try installing the latest, "user-friendly" versions of Linux, any flavor, as Charles Mann did, and as I recently did. Painful. Possibly fatal. If innovation is happening, you and I are not going to know about it, because it's happening under the hood of a server or an embedded device that we probably can't understand.
The most visible software market - the one that you and I probably care most about - is the desktop market, and on the desktop Microsoft's arraignment of the GPL and Linux appears most damning. Very few desktop applications exist in the open-source world, at least those that would be useful to the average user. Why this dearth of innovation where you and I want it most? The most obvious answer is Microsoft's; that the GPL diminishes the incentive to develop Linux code, since that code must immediately be given away to one's competitors (and only the die-hard techies, noted above, can afford to participate for the sake of reputation). The corresponding "network effect" argument - that GPL/open-source applications would be created if the Linux platform were to become prevalent enough - is not helpful, either, as it is very likely because the GPL scares away potential users/developers that a network effect has not been realized.
But let's bracket commercial developers' mostly misplaced fears about the GPL and Linux. Even without these developers, there remain tens of thousands of the "uber techies" mentioned above - why aren't they filling this application void? Eric Raymond tells us in his classic The Cathedral and the Bazaar that open-source development is superior because it allows a wider range of "itches" (needs in software) to be "scratched" (developed) than commercial development does, which is controlled by one corporation. Assuming this is true, are we to understand that GPL coders have simply not needed a good Excel, Quicken, or Internet Explorer replacement?
I, for one, doubt this. I tend to find Brian Behlendorf, co-founder of the Apache Web Server Project, more persuasive. Behlendorf provides several reasons for open-source software's traditional focus on the infrastructural/back-end side of software, and not on more user-friendly things as desktop applications and graphical user interfaces (GUIs). They are:
- End-user applications are hard to write, not only because a programmer has to deal with a graphical, windowed environment which is constantly changing, nonstandard, and buggy simply because of its complexity, but also because most programmers are not good graphical interface designers, with notable exceptions.
- Culturally, open-source software has been conducted in the networking code and operating system space for years.
- Open-source tends to thrive where incremental change is rewarded, and historically that has meant back-end systems more than front-ends.
- Much open-source software was written by engineers to solve a task they had to do while developing commercial software or services; so the primary audience was?other engineers.
In other words, open-source developers have neither the history of developing applications, nor the future of doing so, given that such expertise is not generally found within the open-source ranks. (Microsoft has made a related argument.) This is so for several reasons, but one (unspoken) reason is that applications are viewed within the software world as "wimpy." Real men (and most developers are, in fact, men) develop the low-level networking layers of code; first-year-out-of-an-undergraduate-degree developers write application code.
More fundamentally, consumer products require an immense amount of unsexy code - open-source developers do not necessarily want to invest their time on such parts of the code base, preferring to spend time on more visible, reputation-enhancing projects. Drivers, compatibility code, etc. make up a significant percentage of a complete software program, but they are the least interesting to write. Open Source must rely on a volunteer army. With no authority figures beyond the package manager for a given bit of code, no one wants to be a private in this army, despite Eric Raymond's "rule" to the contrary. People must be paid to do such "grunt" work.
So, maybe Microsoft is right. Maybe the GPL does stifle innovation, at least with regard to the non-technical use of software that you and I prefer. By smothering the incentive to develop GPL software, because we only like to share if we already have food on the table and five SUVs in the garage, maybe the GPL does relegate itself to the world of the serious developer. And because these highly technical developers tend to have highly technical itches, the GPL makes Linux (and other open-source software) innovative, if at all, only for the "talented tenth" of software users.
Innovation At the Edges
However, Microsoft's argument that the GPL provides anemic incentives to innovate fails to see the other intellectual property pitfall: too much protection. In this instance, no one besides the patent/copyright holder has the ability to innovate upon the product in question. Therefore, the producer has no incentive to innovate, as they can collect their monopoly "rents" from the competitor-free product. (This might explain why Microsoft's operating systems are only now starting to become reasonably stable. Interestingly, Linux has been exceptionally stable for years?.) This overbroad protection ends up hurting not only consumers, but also the producers themselves. Because software producers are also consumers (in that they nearly always compile a work from existing copyrighted works), they also lose out from overbroad intellectual property protection. Professor Larry Lessig has recently made similar arguments before the Supreme Court in Eldred v. Ashcroft, an attempt to find unconstitutional Congress' recent extension of the copyright term by 20 years. No original work is ever all that original, especially in the software world.
To flourish, then, software must have neither too little nor too much protection. Balance is critical. The GPL achieves this balance by encouraging serious software sharing at the foundational code level (the operating system), but not discouraging innovation at the application level. This is the absolute best model for innovation.
Up until now, unfortunately, innovation at the application level has not happened, because commercial developers misunderstood the GPL and its effects on their code. Such developers are starting to realize that applications that run on Linux are in no way affected by the GPL?except that they benefit from running on the best operating system the planet Earth has to offer. Not only does the GPL ensure a robust platform upon which to build "killer apps," but the GPL also frees up resources to work on such apps. Individuals and corporations are enabled to free ride on the platform development (which continues to barrel forth, unfazed by Microsoft's arguments to the contrary), leaving their financial resources available to work on building the superstructure. In this way, the GPL is extraordinarily efficient, pushing innovation up to the end-user while simultaneously encouraging innovation at the platform level by those with no ulterior motive beyond excellent code. Innovation in applications for the Linux platform is on the rise (Sun Microsystem's StarOffice is but one prominent example), and will continue to increase their rate of growth.
I cannot stress enough the importance of having a free (meaning: "open") foundation. A former professor of mine, Larry Lessig, is especially persuasive on this topic, both in his Code and Other Laws of Cyberspace and his The Future of Ideas: The Fate of the Commons in a Connected World. Lessig's basic premise is that innovation flourishes best where it is controlled least. Commercial innovation follows shareholder interests, not necessarily wider, societal interests. If we allow AOL to "own" the Internet, then the Internet will be built in AOL's image. The same is true for Microsoft and software, and was true of AT&T's monopoly on telecommunications services, as Lessig illustrates in The Fate of the Commons (see pgs. 26-48).
Let's stick with the Internet for a moment, as it's an easily accessible example for most people. Lessig argues that the early Internet was free, much as Linux is free today. Conceived in open code (meaning, open standards, rather than proprietary protocols and such), the Internet left control (proprietary "extensions") to the edge of the network (my Netgear wireless router, for example, and the IP software protocols that dictate how my equipment reaches the wider Internet). Everything in the "middle" was left free of control. If you send an email across the Internet, the message transfer protocols don't care about the data they're carrying - they're neutral. They simply deliver a packet of information from one end of the network to another. In similar manner, Linux works because the core (the kernel) is open, with development spurred on by a love of good code, and not by a desire to control the applications that will work best with it (read: Microsoft Windows and Internet Explorer).
In short, all code need not be closed to induce innovation. In fact, much code must be open if it is to thrive. A mix is necessary. Yes, open-source development can only go so far on its own. At some point, the Toshibas of the world will not espouse an open OS like Linux if they cannot link their intellectual property to it to create a hybrid solution. Closed-source (proprietary) development is often needed to create general-purpose applications or code that a super-techie might not need. But closed-source development should not be the only game in town, because it tends to close off promising avenues of development, simply because the corporation lacks the inclination or resources to develop in a particular direction. Just as with the Internet, so, too, do we need an open platform upon which to build, so that consumers can develop for other consumers, rather than having commercial interests dictate the software they use.
Something has changed in the mood of high technology - there are increasingly only two games in town. You are either developing for Linux (or, less likely, some other open-source variant), or you are developing for Microsoft. Very little middle ground remains. As the GPL continues to provide an open platform upon which to develop, innovation in Linux will continue to outpace that of its closed-source competitors. And as people come to better understand the GPL, Linux will find its way onto more and more devices, and more and more applications will be written to it. With a developer pool that dwarfs Microsoft's by many times, it seems a conservative bet that robust, market-ready Linux applications will outnumber those of proprietary operating systems by five-to-one within five years. That is true innovation.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com