Expanding Open Source Enforcement Strategies

What comes to mind when you hear "open source enforcement"? Probably the names "Busybox" and "Software Freedom Law Center". These organizations are good examples of the "cease and desist" style of enforcement in the open source context. But an enforcement strategy should go beyond "cease and desist" to also include other considerations such as alignment with business strategy, product development and business model considerations, and promotion of open source education.

A. Aligning Enforcement Strategy With Business Strategy

Enforcing intellectual property rights always sounds like a good idea. Unfortunately, the typical cease and desist and litigation strategy has significant pitfalls including requiring vast resources and risking the loss of goodwill with customers, partners and the community. Aligning enforcement strategy with business strategy clarifies which enforcement activities will have maximum impact while minimizing risks. The question is, how do you align these strategies?

Looking at the size and goals of a company is one place to start. Many open source vendors today are relatively small and privately held. These companies prioritize rapid growth, building adoption and proliferating products over converting customers to cash. These companies could reasonably choose to avoid tricky enforcement issues under the theory that any customer, paying or free, in or out of compliance with a license, is one more customer that can be converted to cash sometime in the future.

By contrast, other open source companies are either publicly held, or privately held and on the verge of generating a return on investment. Accumulating customers is not the focus of these companies, but the traditional cease and desist and litigation approaches to enforcement of unauthorized copies could be seen as a quick way to make money for investors.

B. Building Enforcement Success Into Your Product

Enforcement begins with the choices you make as to features to include, the license that applies and the business model. For example, DRM (digital rights management) is a dirty word in the open source community, but it can be a valuable tool in enforcement. Companies with a subscription model can use DRM tools, such as a digital fingerprint, to track subscription periods and to confirm whether particular installations are eligible for support and services.

Licenses make a difference in enforcement too. The popularity of GPLv2 is due in large part to its viral terms, which make the mere threat of enforcement enough to drive compliance, particularly with traditional proprietary software companies. GPLv3 offers an even more intriguing range of enforcement options because it allows licensors to easily apply their own conditions for enforcement opportunities.

A company's chosen open source business model makes a difference too. As mentioned above, companies with a subscription model often worry about enforcement because they want to ensure the services and tools they provide are only available to licensed servers. By contrast, companies with an open core model might not be as concerned with unauthorized availability of the software because they make their money by enabling additional features or functionality.

C. Safety in Numbers

One of the most successful enforcement strategies adopted by proprietary software companies could be a model for open source enforcement strategies too. Many of the leading software companies are members of the Business Software Alliance (BSA), an organization that not only organizes anti-piracy and license compliance programs, but also promotes public policy initiatives including intellectual property and development policies. Possibly the greatest advantage of the BSA is that it allows licensors to pursue enforcement strategies collectively, thus allowing enforcement resources to be pooled while avoiding the risk of individual members losing goodwill. The uniformity in approach also creates predictability in license rights and when enforcement is appropriate.

Open source companies could come together to form their own Open Source Software Alliance (OSSA) and realize the same benefits. Ideally, the proposed OSSA could also partner with the Free Software Foundation to add credibility to the positions it takes and bridge the gap between the open source and free software movements. Unfortunately, the gap between open source and free software is likely too big for the FSF to endorse an organization like the OSSA.

These are just a handful of ideas that I hope will help open source companies break out of the "cease and desist" box to realize that enforcement means so much more than adversarial confrontations and litigation.

Who Has a Shaky Foundation?

The commercial software licensing business as we now know it started with the move from mainframe computers to affordable personal computers and has been around for at least 20 years. Similarly, open source licensing as we now know it arguably started with release of version 2 of the GPL just a few years later.

Even though these software license and distribution models have been in effect for roughly the same period of time, "conventional wisdom" (the Freakonomics definition) appears to be that the proprietary software license model is built on a solid legal foundation, while the open source model is filled with legal uncertainty. Recent developments on the legal front for both business models remind us that these stereotypes often do not hold true.

The open source community has had a recent string of recent "wins" giving it more credibility from a legal perspective. The continual flow of BusyBox cases, including the recent initiation of an action against Extreme Networks and settlement with Super Micro Computers, Inc., has shown that the GPL can be readily enforced, particularly in cases where GPL-covered code can easily be tracked and where the nature of the software requires the type of linking or integration that would create a derivative work or modification.

In addition, Red Had recently settled a patent dispute and showed that it is possible to successfully negotiate a patent license that protects the open source community as a whole. Both Red Hat's explanation of its strategy, and Mark Radcliffe's analysis of the license terms are fascinating reading for anyone who wants to see the gory legal details that go into making open source work for everyone.

By contrast, a recent case in U.S. Federal District Court in Seattle illustrates that the very foundation of the proprietary license model is still subject to uncertainty. In Vernor v. Autodesk, Autodesk found itself on the losing end of the court's interpretation of the "first sale doctrine," a principle in copyright law that permits purchasers of a copy of a copyrighted to distribute that copy without obtaining additional permission. Another implication of the first sale doctrine is that copyright holders cannot use license agreements to control distribution of copies of their work in perpetuity.

While this Autodesk case was decided in a district court, at least two U.S. Courts of Appeals have made similar rulings, and some others have yet to address the issue directly. The difference in opinion between the Circuit Courts has not been addressed by the U.S. Supreme Court. As another indication of the momentum behind this view, William Patry, Senior Copyright Counsel for Google and author of one of a highly respected legal treatise on copyright law, stated in response to the Vernor decision that to permit a license to circumvent the first sale doctrine "is an absurd position to me, and in such cases, federal courts should take a common sense view of the transaction in order to avoid abolition of the first sale doctrine".

The first sale doctrine is consistent with some of the basic principles of open source, but it does not provide the same level of freedom that copyleft and other open source licenses provide. As a result, the Vernor decision isn't likely to impact the open source model directly.

Instead, the important message here is that no matter how exciting the successes they enjoy or how dire the challenges they face, both the open source and proprietary software license business models as we know them today have solid legal foundations and will certainly survive.

GPL Enforcement, Frogs & Funny Hats

The GPL has become the most popular of open source licenses in large part because of its "copyleft" status. Not only does it virally attach to software code, but it automatically terminates if its source code distribution obligations are not honored. The severe consequences of breach, along with community pressure for compliance are strong deterrents to violations that would require enforcement measures. Even so, every open source company using GPL will be faced with GPL violations and must carefully consider both when enforcement is appropriate and what factors should be weighed as part of that decision.

To those open source companies that assume GPL enforcement is always the quickest, best strategy, I quote the great open source guru Homer J. Simpson: "you're living in a world of make-believe! With flowers and bells and leprechauns and magic frogs with funny little hats." Yes, it's true that enforcement serves a critical function. Not only does it prevent abuse of open source code on a case by case basis, but it also upholds the legitimacy of the GPL as a license vehicle and meets the community's expectations of its fellow members.

On the other hand, enforcement is not a panacea. The community might view inconsistent enforcement as arbitrary and self-serving, or it might have different views on what a company's enforcement priorities should be. In addition, enforcement actions might actually slow the adoption of open source in proprietary companies. A great recent example of this type of unintended consequence is the discussion arising from the recent string of settlements related to the Busybox GPL enforcement cases. Though widely criticized by a number of open source commentators, intellectual property attorney Edmund Walsh wrote an article in which he analyzed these cases and concluded that "for-profit companies [have] new reasons to re-evaluate the ways in which they use open source software as well as the extent to which they use it."

Open source companies should also consider strategic non-enforcement as an option, or take a further step and grant limited exceptions to open source licensing (assuming the company controls adequate IP rights). Among the benefits of these approaches is the ability to encourage specific types of partner and end user activities that would have been difficult to otherwise achieve without radically altering a dual license strategy. However, these approaches should be used with caution because they can easily backfire. The community might view this type of manipulation of open source strategy as counter to open source philosophy. It also could lead to end users using the software in unanticipated ways that negate the perceived or realized benefits of the approaches.

The moral of the story is ... as you consider your options with respect to enforcing the inevitable GPL violations that all open source companies face, avoid the frogs with funny little hats!