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.

No Preliminary Injunction in Jacobsen Case

Those who follow the Jacobsen v. Katzer case know that it likely will have a significant on how US courts view open source licenses and what legal remedies are available when they are violated. The latest twist in the case, as reported on the Madisonian blog, is the decision of the US District Court for the Northern District of California to deny Jacobsen's request for a preliminary injunction. On its face, this decision might seem like a setback in the ability of open source licensors to ensure the terms and principles of the open source licenses are enforcable. However, my view is that the facts of the Jacobsen case are unique enough that this ruling will not significantly interfere with the efforts of other open source licensors to obtain injunctions.

For an excellent summary of the history of the Jacobsen case, including all the legal developments up to and including the Federal Circuit's ruling in August, please see Larry Rosen's excellent article "Bad Facts Make Good Law: The Jacobsen Case and Open Source". The particular fact of importance here is that Jacobsen requested a preliminary injunction based on Katzer's failure to comply with the terms of the Artistic License requiring the licensee to "duplicate all of the original copyright notices and associated disclaimers". Compare this to the Free Software Foundation's claims against Cisco, which include allegations that Cisco failed to comply with the GPL and LGPL obligations to distribute source code to modifications made by a licensee.

This distinction important because the types of harm likely to result from failure to distrbute source code are easier to identify and articulate than the types of harm from failure to reproduce copyright notices. Under the 2008 US Supreme Court opinion in Winter v. Natural Resources Defense Council, the Court elaborated on the well-accepted requirements for granting a preliminary injunction with a particular emphasis on the point that plaintiffs must show more than a mere possibility of harm, but must actually back up the claims of harm with meaningful evidence. Here is criteria cited by the Court for all US courts to use in deciding whether a preliminary injunction request should be granted:

"A plaintiff seeking a preliminary injunction must establish (1) that he is likely to succeed on the merits, (2) that he is likely to suffer irreparable harm in the absence of preliminary relief, (3) that the balance of equities tips in his favor, and (4) that an injunction is in the public interest." (I added the parenthetical numbers for easier identification in this blog post. The Court cites multiple cases on this point going back to 1982 including another 2008 opinion.)

Elements (2) and (4) are the most important for our purposes. With respect to element (2), meaningful harm from a failure to maintain proper copyright notices in publicly available software seems difficult to prove, and proving that the harm is irreparable is even more difficult. At worst, a recipient of the licensed software would receive the proper copyright notice after the software is distributed, but this would not result in any change in use or non-use of the software. By contrast, a failure to distribute source code could change the way a recipient uses the software, which is central to the purpose of the open source license.

Element (4) is particularly interesting as applied to open source software which, by its very nature, is intended to benefit the public. The public does not necessarily benefit from knowing whether a particular copyright notice is accurate, but the public cannot take full advantage of the software made available under an open source license unless it receives the actual source code.

Setting aside variations in application of the law across jurisdictions, a plaintiff is a more likely to be able to present evidence adequate to support a preliminary injunction when a case revolves around availability of source code under an open source license as compared to a claim of failure to adequately comply with copyright notice requirements. In my opinion, cases like the FSF's claims against Cisco are the types of cases we are most likely to see in enforcement of open source license terms. As a result, plaintiffs should not let the Jacobsen case discourage them from requesting preliminary injuctions, particularly when the plaintiff's claims are based on failure to distribute source code.

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.

Silicon Valley Cocktail Party Small Talk

Whether you scan the newspaper headlines once in a while as you pass the newsstand, or multitask with NPR in your headphones, New York Times RSS feeds to your laptop and CNN Headline News ported to your mobile phone via Slingbox, it's important to have a few interesting tidbits of recent information readily at hand if you happen to attend a cocktail party or other social gathering.

While the subject of open source software might not be the key to climbing the social ladder in many places, it would be a clear hit in Silicon Valley Extended (e.g., beyond the San Francisco Bay Area to include the Raleigh-Durham Research Triangle, Bangalore, India and other places that live and breath technology). With that in mind, here is a list of 5 important issues in open source that will likely continue to heat up over the coming months (in no particular order) and that are worthy of discussion with your tech colleagues:

1. Security of Open Source Software. When Fortify Software released its report on security in the open source software industry, it created an immediate reaction. Fortify noted that typical community open source development models and projects often do not incorporate the types of security safeguards that enterprises like to see. It was a critique of process more than security features of the software itself. While the underlying message was sound, it created an immediate reaction from (a) the open source development community, which took issue with the implication that open source software is not secure (in fact, a pillar of open source adoption has always been that it is more secure precisely because it is open and subject to constant testing), and (b) anyone else who wanted to spread fear, uncertainty and doubt ("FUD") about the open source industry. Commentators like Dana Blankenhorn recognized the overreaction by the media and others in their blog posts. Bottom line: While open source software processes are not always at the level of security typically employed by enterprises, the software itself is largely secure, and likely more secure than its proprietary counterparts.

2. Cloud Computing. Cloud computing is the availability and use of computing resources over a network when the actual machines used for processing tasks are not specifically identified ahead of time and are reassigned frequently. One fear for users of cloud computing (like Amazon's EC2 offering) is that the cloud will break and the one vendor that controls it will not be able to fix it. Even worse, user data will be stuck in the cloud. Classic vendor lock-in. As noted by the 451 Group, many believe that an open source cloud platform would reduce these risks and a number of alternatives to Amazon and the other big name cloud vendors. Bottom line: As in all other segments of the software industry, cloud computing vendors need to be aware of the disruptive capabilities of open source.

3. Mobile Infrastructure. Apple has been getting virutally all the buzz in the mobile market because of its release of iPhone 3G. While the closed nature of the iPhone's architecture has drawn heated criticism from the Free Software Foundation, it has gotten at least a temporary pass from the type of widespread critical commentary you might expect from others in the open source community. In parallel, the open source community is looking forward to LiMo and Android as the first true open source alternatives. Out of nowhere, Nokia's recent acquisition of the outstanding stake in the Symbian mobile operating system added even more strength to the mobile open source movement. In addition to the platform, we also have companies like Funambol, which has already brought a level of freedom to the mobile market that was previously unheard of. Bottom line: Open source will see rapid adoption in mobile, and they are just now getting their ducks in a row.

4. Virtualization. The recent emergence of virtualization technology presents a significant challenge to open source licensing. Virtualization enables the creation of software appliances, which combine software components into a finely tuned package. According to rPath, a one of the thought leaders in software appliances, virtualization can be used to combine operating systems, open source software and proprietary software into a single package without violating open source license obligations or subjecting proprietary code to copyleft. While the legal analysis is too new to have been well tested, it is easy to foresee scenarios in which virtualization is used to avoid they types of product interaction that would have been deemed a modification or derivative work of an open source work, and be subject to copyleft. Bottom line: The industry is just now starting to apply deeper levels of creativity in how virtualization is used, and the impact on all types of software license models, including open source, needs to be carefully considered on a case by case basis.

5. Standing to Sue in Open Source. From the open source perspective, one of the biggest limitations on enforcement of copyleft open source licenses is that the entire responsibility of enforcement falls on the copyright holder. If the copyright holder either doesn't want to pursue a license violation, or doesn't have the resources to do so, no one else can undertake that responsibility on behalf of the community. An enforcement mechanism that enables community members who lose access to source code that otherwise would have been available would solve this problem, but this would likely require a change to the copyright statutes themselves. Another option would be for the open source community to use its collective influence to urge copyright holders to either enforce their rights, or assign them for others to enforce. Bottom line: Nothing is likely to change any time soon on the legislative front, but a community body might be able to find alternative means of enforcement.

BONUS

6. Software/Platform as a Service. GPLv2 and v3 are extremely effective in applying copyleft to software distributed in the standard ways (through online download or on physical media). These licenses, however, have no effect on software used solely over a network connection without any distribution. The Affero GPL was created specifically to address SaaS and PaaS models by applying copyleft to software accessed over a network. The Affero GPL has seen modest adoption (125 projects, according to Palamida ), and Funambol CEO, Fabrizio Capobianco has been a fantastic advocate for the license including by adopting it for Funambol open source projects. Bottom line: With the growth of SaaS/PaaS, coupled with the growth of open source, more service providers will take a serious look at AGPL, which will likely increase adoption.

Please share your thoughts on the key trends in the technology industry that will impact the open source world.