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.

FSF Motives in the Cisco Case

One of the comments I received to a recent post questions the motives of the Free Software Foundation ("FSF") in its complaint against Cisco, and whether the FSF is overreaching in the remedies it proposes. Specifically, the comments reference The Software Lawyer blog posting entitled Free Software Foundation Sues Cisco: Some Criticism. To summarize, the blog post questions whether the FSF would accept GPL compliance as a solution to the disagreement with Cisco and goes further to say that "[the FSF] wants to push Cisco around and it wants money."

I think these views are overly cynical of the FSF's motives. I also disagree that endorsing the FSF's actions results in granting a licensor power to choose substitute license terms. Below, I discuss my reasoning for these conclusions in more detail in hopes of illuminating the issues in the broader discussion around the meaning of license compliance and the role of license enforcement in the open source world. Please also note that I am not concluding that the FSF will be successful in its litigation either through a judgement on the merits of the case or a favorable settlement. Instead, my intent is to illustrate that the FSF's actions appear reasonable.

[Note: I have no knowledge of the FSF's or Cisco's thoughts, reasoning or internal discussions on these matters - all of my comments are based on the complaint and public statements by these entities and commentators.)]

FSF Motives

The views presented in the comments and blog post suggest that the FSF motives are pointed more towards self interest than support of the goals of the free software movement. To the contrary, the FSF's actions indicate that it is legitimately trying to enforce the principles of free software by ensuring that Cisco honors the freedom of its users to have access to source code. No doubt the FSF would like to make an example out of Cisco and would like to see onerous penalties (including monetary damages) imposed for failure to comply as a means of discouraging other potential infringers, but this is consistent with enforcing the principles of software freedom.

The commentary also cites the FSF's requirement that Cisco appoint an open source officer as a potential remedy outside the scope of the complaint. While this might seem unusual, it is consistent with a common litigation strategy in which plaintiffs ask for more than they might be entitled to from a court. This tactic helps push settlement discussions and alternatives to litigation remedies. In fact, FSF is not the first to use this approach. Similar terms have been agreed upon in the string of Busybox cases, which were also litigated by the Software Freedom Law Center. These actions indicate a good litigation strategy rather than impure motives or overreaching.

Motives of a Large Company as an Alleged Infringer

The commentary also assumes that large companies in Cisco's position, would necessarily do their best to comply with license terms as fast as possible, and that such a company would not continue shipping an allegedly infringing product unless absolutely certain of ability to comply. In turn, the commentary suggests that this indicates the FSF has unreasonably deemed Cisco's proposed compliance activities as inadequate. This conclusion is not supported in my view.

It is fair to assume that a company in Cisco's position would perform a risk analysis based on the FSF's stated concerns and could reasonably decide to respond by engaging FSF directly. This strategy would permit the company to work through compliance options over an extended time period. From a purely utilitarian standpoint, this approach seems more favorable than immediately pulling a product suspected of GPL infringement without first consulting the FSF, which would result in further difficulties. No doubt in the multiple years of discussion between Cisco and the FSF, both parties understood that some sort of compliance actions were appropriate, but they had differing interpretations on the types of remedies and time frames for resolution. As a result, it appears that the FSF likely has a reasonable basis for its conclusion that Cisco was not acting fast enough and the use of litigation was a way to stress the importance of compliance is justified.

Remaking the Rules

The claims that FSF's proposed remedies are "remaking the rules" and that it "gets to choose the terms of reinstatement" also are not warranted. The GPL and LGPL licenses immediately terminate once a licensee violates their conditions. Once termination occurs, a licensor can choose to enforce an infringement claim and use the threat of damages awarded by a court as leverage to negotiate a settlement that includes more than monetary damages. This is the approach the FSF is taking with Cisco and it seems consistent with good litigation strategy.

In fact, the FSF has also chosen to work with Cisco for several years to obtain compliance without litigation, which further indicates the reasonableness of its actions. The FSF's proposed remedies are separate and distinct from the rights available to Cisco and all other potential licensee under the GPL. The FSF could not remake the rules of litigation remedies even it wanted and it doesn't seem fair to conclude that the FSF is trying to remake the rules or make up substitute license terms.

In short, whether the FSF will be successful in reaching a favorable judgment on the matters in the complaint or obtaining a favorable settlement with Cisco remains to be seen. Even so, the FSF's motives and actions seem reasonable in the context of the allegations in the complaint.

Jump On the Bandwagon

Last week I attended a very informative CLE on Open Source Software 2008: Benefits, Risks and Challenges for Software Users, Developers and Investors, and was lucky enough to join Joyce Chow from Apple in presenting a session on Open Source Business Models. What made the seminar so useful was the breadth of topics it covered … everything from the nuts and bolts of open source licenses, to the technical details of linking and derivative works, and even ethics in open source (presented in part in a very entertaining fashion by Dave Marr, one of my colleagues at Sun). Bob Pierce, a former colleague of mine at Adobe, provides an informative review of the presentations on his blog.

In talking with other presenters and attendees, it became clear that the law surrounding open source software has reached a milestone. The skills needed to support an open source software business are no longer practiced by a handful of attorneys, and instead are skills that every attorney should have. Examples of the importance of understanding open source appear almost daily:

• Current economic troubles make the low cost and convenience of open source software particularly attractive to IT departments and businesses of all sizes.
  

• Cisco has been sued by the FSF and SFLC for failure to comply with the GPL - having a effective open source management process, knowing how to comply with open source licenses and ensuring such compliance occurs is critical to virtually all software businesses.

• The Open Inventions Network is pooling patents and prior art to protect Linux and the open source community from patent lawsuits - the open source community controls intellectual property rights for the benefit of the community.

• Gartner research shows that 85% of enterprises currently use open source software and the other 15% will within the next 12 months - even if you think your client doesn't use open source, it almost certainly does.

These are but a handful of examples, but searching everything from broadly circulated business periodicals to the most narrowly pointed open source geek blog will yield a virtually limitless supply of information on the growing importance of the open source model.

In short, this is the time to jump on the band wagon or be prepared to be left behind.