First, he says, section 2(b) of the GPL has not been tested in court. Epstein believes that courts are likely to enforce section 2(b) with copyright remedies rather than with contract remedies, meaning that a violator would be enjoined from further distribution until the offending code is removed and would have to pay damages to the copyright holder. The GPL would not have what Epstein claims is its promulgators’ “apparent intention” — to “infect” proprietary software and force it to be licensed under the GPL.
But the Free Software Foundation, promulgators of the GPL, have no such intention. Indeed, they see the GPL as a pure copyright license, not a contract. This means that if GPL’d code is incorporated into a proprietary product, a license is violated but no contract is breached. Under the terms of the GPL, all rights to use the GPL’d code terminate when the license is violated, and any further distribution is copyright infringement. At that point, the violator certainly may release the product under the GPL, curing the license violation, if that’s cheaper than rewriting the misappropriated code. But the violator can also just pull the product from the market, or rewrite the offending sections. The GPL Police don’t show up, seize CD-Rs full of source code, then dance in a circle singing victory songs. These are perfectly ordinary remedies, and the Open Source community is operating on the assumption that Professor Epstein is right — that the GPL is a license, not a contract, and that copyright remedies will suffice.
Second, Professor Epstein argues that the structure of Open Source projects is unsustainable. As he says:
The open source movement shares many features with a workers’ commune, and is likely to fail for the same reason: it cannot scale up to meet its own successes. . . . The bottom line is that idealistic communes cannot last for the long haul. The open source movement may avoid these difficulties for outside contributors who work for credit and glory. But how do the insiders, such as Linus Torvalds, cash out of the business that they built? And in the interim, how do they attract capital and personnel needed to expand the business? Traditional companies have evolved their capital structures for good reason.
Though he minimizes it, Professor Epstein recognizes the central feature that separates the open source movement from a workers’ commune. The point of a workers’ commune is that everyone is an insider, sharing equally in the monetary profits reaped through their collective labor. And when an insider wants to leave an organization, there has to be some way to separate out her share. But open-source projects are fundamentally different from workers’ communes in a number of ways that allow them to avoid the problems Epstein lists. Most importantly, where in a commune everyone is an insider, in an open-source project, everyone is an outsider. Everyone has the same rights to the code, and everyone has the same right to “fork” the project, using the same GPL’d code to create a new, improved, or different version of the program. The only thing that separates Linus Torvalds from any other kernel contributor is his reputation. People like using his version of the kernel more than they like using someone else’s, because they like the choices he’s made about what code is and isn’t incorporated. Epstein notes that organizational difficulties may be avoided with regard to contributors who work for “credit and glory”. But as far as the project maintainers know or care, everyone is working for credit and glory. Patches from people who IBM pays to hack the kernel for a living aren’t treated differently from patches submitted by any other talented kernel hacker. There is no central body handing out rewards.
And this is the reason the Free Software Movement won’t collapse under its own weight. When IBM or Red Hat or TiVo hire programmers to work on open-source projects, neither the companies nor the programmers expect to be able to appropriate any portion of their contribution. This is not to say they are acting altruistically, but only to say that the corporations believe — rightly — that under certain circumstances they can maximize their profits by waiving proprietary rights to certain code written by their employees. If corporations continue to provide institutional support for high-profile open source programmers for these reasons, the present model is sustainable. If they cease, the worst that could happen is a return to the old, pre-boom open source development structure, where things moved a little more slowly, but everyone played for the love of the game.