Cloud Nitty Gritty

The cloud industry is in the process of defining itself. Experts are organizing seminars and presentations to discuss best practices for the cloud business. This is true for the legal industry too, but the legal issues commonly discussed for clouds are similar to the issues seen in connection with service bureau, outsourcing and software as a service initiatives: Privacy, Security, Ownership, Intellectual Property, Jurisdiction, Applicable Law, Service Levels, Export Compliance. While these issues present unique concerns in a cloud context and are worthy of significant discussion, I would like to focus on a less discussed issue: how open source might be implemented within a cloud computing context.

Two important questions come to mind: (1) When does distribution to a cloud trigger the viral source code disclosure obligations under the GPL?; and (2) What is subject to the viral source code disclosure obligations under the Affero GPL?

1. Distribution to the Cloud

Consider what would happen if a developer creates a proprietary application, incorporates code licensed under GPLv2, and distributes the combined application to a cloud provider. We can narrow the answers down to 3 possibilities: yes, no and maybe. I'm not trying to make a joke ... this circumstance is not well settled from a legal standpoint and each of these answers might be valid.

a. Yes - viral obligations should apply because code distributed to a third-party is a "distribution" for purposes of the GPLv2.

b. No - Using a cloud to host an application is no different than using a leased server to provide end users with access over a network or hiring a service provider to act in the same capacity as the developer itself. In such cases, the cloud provider is nothing more than an extension of the developer itself. While this conclusion makes logical sense, it's not clear whether the Free Software Foundation would agree with the end result.

c. Maybe - Because both the yes and no answers can be legally supported or refuted, it would help to clarify the legal treatment in some way. Because the cloud provider would be the only party with standing to demand source code in this case, one option might be for the cloud provider to add a clause to its service agreement stating that it will not require disclosure of source code for applications submitted for operation on the cloud. The Free Software Foundation and a significant portion of the free software community would likely object to a cloud operator's affirmative refusal to enforce the freedoms provided by theGPL.

I believe "Maybe" is likely the right answer because it makes the most sense from a practical perspective. Operation of GPL-licensed software on a leased server does not interfere with any of the freedoms that the Free Software Foundation intended to promote with the GPL. This argument is strongest when the developer's cloud code is an application that could just as easily be operated on the developer's own requirement. By contrast, the argument is weaker the more the developer's cloud code relies on the infrastructure provided by the cloud operator such as in a "platform as a service" model.

2. Scope of Affero GPL Coverage

While end user interaction with applications licensed under GPL and hosted on a cloud do not trigger any source code disclosure obligations, use of the Affero GPL code instead of GPL leads to a different result. Such end user interaction occurs over a network, which constitutes distribution for purposes of theGPL. Clearly, the developer application containing AGPL code would need to be available for disclosure on request in that case.

One of the advantages of the cloud for developers is that cloud providers offer much of the software and hardware infrastructure needed to run developer applications. Consider whether any aspects of the cloud code itself should also be subject to the AGPL's code disclosure requirement. The "Maybe" answer above likely applies here as well, but for different reasons. Cloud components that are integrated with developer applications such that the cloud component and developer application are deemed a derivative or a work based on the developer application would also be subject to theAGPL's viral source code disclosure obligation. This is similar to the the type of GPL analysis we typically see in determining whether a derivative work is covered. Operating systems available on the cloud likely would not be at risk, but libraries and utilities essential to the operation of the developer application could be.

The emergence of cloud computing not only places the freedoms identified by the Free Software Foundation at risk, but it potentially undermines the ability of open source vendors to maintain a viable business strategy as their applications move to the cloud. In this context, it's clear whyFabrizio Capobianco, Funambol's CEO, is such an advocate for use of the AGPL instead of the GPL as new projects are rolled out ... not just for each open source vendor, but for the industry as a whole.

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.

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.