Section 7.3. A New Brand of Intellectual Property Protection

7.3. A New Brand of Intellectual Property Protection

To fully appreciate this trend, it is critical that we better understand the intellectual property regime powering the open source revolution. Intellectual property (IP) law has always been about control. That control benefits creators by holding off would-be competitors long enough to allow the creator to attempt to profit from her innovation. I write a piece of software; I copyright it; I sell it (assuming it is a useful piece of software and I have adequately marketed it so that people know about it). Simple. This has been the software industry's dominant model for decades, and has created a few mammoth software companies that have successfully exploited their IP to generate billions of dollars in revenues. In this model, exclusion (i.e., the ability to keep competitors or customers from copying one's code and distributing it to others) yields profits. In this model, the code itselflocked up and protectedmatters most.

In the open source world, at least as defined by the GNU General Public License (GPL), IP continues to play a critical role, but it is a different kind of IP. Dubbed "copyleft," open source IP focuses on keeping code access open rather than closed. And, unlike in the world of proprietary software, the code matters less than the coderanyone can see the code, but not everyone can replicate the coder's influence on the community to which she contributes her code. By virtue of her contribution, she builds influence in her chosen code community, and this influence translates into a new kind of IP: reputation property instead of intellectual property.

In this new world of open source, reputation property means as much as or more than traditional intellectual property. If I employ the developers on a given project, I have a measure of control over the direction that the open source project will take. But even more importantly, the more developers I employ who work on, say, the PostgreSQL database project, the more likely it is that would-be customers will trust me to be able to support it. Once a company is thought of as the default support vendor for a given project, the harder it becomes to dislodge that vendor. This jibes perfectly with other commodity businesses where brand, price, and service provide the only lock-in, a benevolent lock-in that customers choose instead of one that vendors impose.

In this way, the open source code creator exercises a form of control over her creation, and that control translates into her (and only her) ability to charge a premium for the software. As an open source creator, then, my options for deriving profit from my creation are not more limited, but they are different. Instead of a limited monopoly guarded by law, I have a monopoly guarded by common sense: buyers want to buy from the most qualified source of support. They pay to have access to the source: not the source code, but the source of the code.

This distinction is important. The importance of source code gets trumpeted so often that one would think that every IT buyer on the planet is clamoring for access to source code. They are not. Indeed, Microsoft recently conducted a survey of its customers and found that roughly 60% felt that access to source code was "critical." But when pressed on the matter, 95% said that they would never look at the source, and a whopping 99% said that they would never modify it. (If they did, chances are that such modification would violate their support agreement anyway, whether their vendor was Microsoft, Novell-SuSE, Oracle, Red Hat, etc.) In sum, customers perceive source code access to be important, but are not exactly sure why. As I will detail shortly, the "why" relates to a desire for additional choice and control, and choice and control drive down costs.

Of course, nothing in this chapter should lead one to believe that source code is irrelevant. Source matters. It matters because it lowers switching costs (i.e., the cost of swapping out one vendor's software for a competing vendor's software); because it provides buyers with more control over their IT, as it allows them to shape code to fit their particular needs; and because it provides a mechanism for keeping vendors honest, by forcing them to take responsibility for the quality of their code. In short, source code matters because it shifts control back to the buyer, which forces vendors to offer better software at lower prices. While none of these source code benefits requires the intervention of a vendor, we should not get sucked into the belief that vendors matter but little in the open source world. Instead, open source actually makes vendors more relevant to customers than ever before at dramatically lower prices.

Besides benefiting customers, this GPL licensing scheme offers vendors a way to exercise an incredible amount of control over competitors. By open sourcing my code under the GPL, I push my competitors to follow suit or to increase their R&D efforts to escape commodification. Unfortunately for them, this counterstrategy of a unilateral R&D arms race tends toward paltry results: customers will often opt for the "good enough" product when the price is dramatically lower. Yes, my closed source competitors could simply take my freely accessible source code, "fork" it, and build it into their own products, but they almost never will. Doing so compels them to open source their own software, which they will be disinclined to do. Even if they did so, however, and even if my competitor were not a stodgy old closed source vendor, but rather, an agile open source predator, it would matter little, because open source buyers invariably favor the source of the source, as it were: they trust the creator of the code to support it best.