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.

The Obligatory End of Year Blog Post

Virtually all media elements engage in the age-old ritual of summarizing the year that was, and looking ahead to the year that will be. Though the number of blogs dedicated to open source, or even those that mention open source on a frequent basis, is extremely small in the blogging universe, my open source compatriots are doing the same ... look at Matt Asay's The Open Road, Zack Urlocker's Open Sources, and Dana Blankenhorn's Linux and Open Source, to name a few. Each of these writers have provided valuable insight into the important open source events of 2008 and areas of focus for 2009 and I encourage you to read their posts.

I do not presume to add much to what these writers have already provided, but I would like to make a few observations. First, I see 2008 as a great success for the open source movement both on an industry-wide basis, and from my personal perspective. The industry as a whole has gained acceptance to the point that it is viewed as an important consideration in the business strategy of all software companies. On a personal level, not only was I privileged to be part of MySQL at the time of Sun's acquisition, but I also started this blog and made more than twenty postings.

Second, I believe 2009 has a strong chance of being the year that open source achieves critical mass not only of mind share, but of economic sustainability. While it's true that several open source companies are making in the tens of millions of dollars in revenues, the economic pressures that hit hardest at the end of 2008 could result in significant gains in revenue opportunities for these companies in the coming year. The economic pressures might be so severe that all IT spending is burdened throughout 2009, but the important point is that in the near future, the cost-conscious thinking arising in these times will likely lead to a radical change in the view of what constitutes value. No doubt, the open source industry will benefit.

The only prediction that can be made with any certainty is that few predictions become reality. In any case, I wish everyone all the best in 2009!

Making Money with Open Source

The question of whether a business can make money with open source software has most often been answered with an uninformed "no," at least until recently. As open source becomes mainstream and an integral part of the software industry, the common answer to this question is becoming, "yes, but I'm not exactly sure how." This was the topic that Joyce Chow (Apple Inc.) and I addressed in our presentation on Open Source Business Models at the Practicing Law Institutes seminar on Open Source Software in San Francisco earlier this month. Here is a brief summary of the highlights of our presentation.

To start, calling open source a "business model" is not accepted by everyone. Open source is clearly a development and license model, but it does not directly derive revenue. It is best viewed as a tool or strategy that can be used to generate revenue, much like any other business strategy. For the sake of simplicity, this post will treat use of open source in any meaningful way as a strategy that is an open source business model.

Open source business models are best considered as a spectrum of strategies using open source, from a 100% open source software model, to a pure proprietary model (though some might argue that "proprietary" is not the opposite of "open source" ... we will treat it here as the other end of the spectrum because it indicates that revenue is generated with no reliance on open source software). Along the spectrum are various combinations of development, licensing, services and other strategies with different triggers for generating revenue. Some of the most well know, starting from pure open source and moving to pure proprietary, are:

• 100% Pure Open Source - This is not a business model in the sense that entities in this category are typically non-profit entities that collect donations for the purpose of furthering the goals of their chosen open source project rather than profit-seeking. Entities like the Apache Foundation and Free Software Foundation fall into this category.
  

• Open Source as a Lure - Companies like Google and Sun Microsystems (my employer) employ this strategy. Google hosts its own open source code repository and open source applications (such as Android) optimized to its search results framework to generate higher web traffic and resulting ad revenue from developers and application users. Sun optimizes its hardware-dependent open source applications (such as Open Storage, xVM Ops Center, and MySQL database software) so they work extremely well on Sun's high-performance servers. In both cases, revenue is not derived from the open source software directly, but rather from the increased sales of related activities and materials.

• Aggregation and Services - These are really two separate models, but aggregation is not a viable business opportunity on its own and the two models are well matched. In consideration of seemingly infinite amount the open source code available on sites like Sourceforge or Launchpad, pulling related code together into a fully functioning application is a real value. Red Hat's ability to compose Linux from multiple sources with many copyright holders into an enterprise-friendly, reliable operating system is a perfect example. Providing services (including training, support, maintenance and professional consulting) is a very compelling revenue opportunity. Services are a natural addition to aggregation because of the expertise and knowledge gained in the process of aggregating code and ensuring it works properly. Red Hat also enhances its offering by providing a full spectrum of services to customers.

• Embedded Use - Open source software licensed as embedded components is another viable business model, but the revenue generating potential lies in the use of a dual-license model rather than the value of the open source software itself. An embedded component licensed under a permissive open source license (e.g., BSD, MIT, Apache, etc.) will not generate revenue because users have no incentive to pay for the freely available software with broad license rights. By contrast, an embedded component licensed under a restrictive or viral license (e.g., GPL) forces a potential OEM or system integrator to purchase a commercial license to the same software. Of course, this requires full ownership (or at least broad license rights) of all rights in the software. The MySQL database is an example of this model.

• Tiered Product - Tiered open source software offerings include two basic types of models. First, an open source offering could be an entry level version of a product, much like the evaluation or "light" version of a proprietary product, with a more fully-featured version available for a fee. However, the open source vendor has an advantage over the typical proprietary evaluation product because the source code is freely available for modification and customization. Funambol's open source and carrier grade editions illustrate this type of tiered product well. Second, an open source offering could be fully featured with no separate enterprise version of the product, and the open source vendor can compel purchase of a commercial license by offering additional tools or add-ons that make the open source software more valuable either by making it easier to use or enhancing its efficiency. In both cases, we come closer to a pure proprietary model in that revenue is generated by the value of the software itself either alone or in conjunction with other software or services.

• Incidental Open Source - Many of the most useful and reliable software tools, components and subroutines are available under open source licenses. As a result, virtually all software developed and distributed today contains open source software to save time and resources. However, the mere inclusion of open source components in a software product does not mean that a software vendor is engaged in the open source business. As a result, the incidental use of open source should not be seen as a means of generating revenue through the use of open source.

• Pure Proprietary - The name says it all. Distribution of software containing no open source components, and with no connection to other open source software is in no way an open source business model. This model was common 10 - 15 years ago with most software vendors such as Microsoft, Oracle and others, though all of these vendors not use open source materials at least on an incidental basis and are actively participating in other open source business models.

This is not an exhaustive list by any means. Each business entity must consider its goals, strengths, and the multitude of variables of each development, license, go-to-market element and revenue trigger for each open source strategy to ensure it finds the best point along the spectrum for it's unique needs. Moreover, these business models should be combined to achieve maximum effectiveness.

Open Source Legislation and Budgeting

California's fiscal health is in a downward spiral with no end apparently in sight. But when that end comes, the crash will be a doozy. After enduring California's longest budget stalemate in history, a time period spanning July to September 2008, the legislature and governor agreed upon a budget that was almost immediately torpedoed by the nation's economic crisis.

Now California legislators are arguing virtually around the clock from their entrenched positions (Democrats primarily advocating tax increases, with Republicans primarily advocating spending cuts) to find a way to plug a budget gap likely exceeding $40 billion by next year. The current proposal would impact Californians with massive additions to and increases in taxes, surcharges and fees including a 2.5% income tax surcharge, an additional $0.10 (possibly more) per gallon fee on gas purchases, and numerous other increases. It would also include dramatic cuts and work stoppages in infrastructure projects.

The budget stalemate not only illustrates the disconnected between political parties, but the disconnect between the politicians and their constituents. The citizens of California deserve to have a stronger voice over their politicians and the policies that impact them directly. You are surely asking, "what does this have to do with open source?" Well, nothing directly, but the ideals of open source (as identified by the Open Source Initiative and the classic text "The Cathedral and the Bazaar", as well as concepts drawn from the book "Wikinomics") provide an excellent starting point for changing the budget and legislative processes to better serve the state. Consider these advantages found in the open source model:

• More brain power means more diversity of views and better ability to solve problems
  

• Speedy fixes to problems and resolution of issues
  

• Lower overhead by outsourcing difficult issues to those with expertise and interest
  

• Creating a closer tie between companies (politicians/government) and customers (constituents)
  

• Better responsiveness to customer feedback and needs
  

• Facilitating a sense of inclusion and legitimacy of decisions and actions

The idea that government activities would benefit from more transparency to and direct involvement from involvement of constituents is not new. An organization known as MorePerfect.org has had its website running since 2006 offering a platform for anyone to voice there opinion, and draft and modify legislation on any issue (including revising the US Constitution). This is but one example, but imagine how effective such an idea could be if both the legislature and constituents committed to it.

Maybe the politicians could set aside their entrenched positions by listening to the priorities and needs of citizens, which would not only lead to a budget aligned with the state's needs but would also help win the trust of citizens.

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.

For All the Law Students Interested In Open Source

I recently met several law students who are interested in intellectual property law and the open source business. I was impressed with their awareness of the impact of open source on the technology industry, and happy to see how interested they were in learning more. In response to their questions on how to develop the skills needed to focus on open source, I have advised students that no pre-defined path of classes or experience leads to expertise, but there are several activities to emphasize as they progress in their journey towards finding their niche in the legal community.

A. First and foremost, all students interested in open source must have a solid foundation in intellectual property law. Open source business models arose as novel ways to utilize traditional proprietary rights. For example, the GNU General Public License ("GPL"), the most well known and widely used open source license, relies on a liberal grant of the rights held exclusively by a copyright owner to ensure that software users have a maximum amount of freedom to use open source software. A thorough understanding of copyright law is critical to understanding the impact of "copyleft" licensing.

B. Of equal importance to students is understanding contract law and having strong contract drafting and interpretation skills. Using the GPL as an example again, the copyleft effect only works because the license is drafted in such a way that passing along the rights granted under the license to subsequent licensees is a condition of the license grant. (See Mark Radcliffe's commentary on the Jacobsen v. Katzer case, which hinged on the "conditional license" issue.) In other words, the contract is written to enforce the viral nature of copyleft licensing. The conditional nature of most open source licenses means that contract interpretation skills are critical. A legal interpretation of a particular open source license must take into account the contractual conditions and obligations along with the broader context in which the licensed components are used.

C. As in any endeavor requiring legal analysis, a lawyer must always look beyond the relatively narrow context of "the law" to recognize and understand the bigger picture and real world consequences of legal conclusions. This is particularly true with open source businesses because the goal of businesses to generate revenue contradicts the act of giving something away for free does and open source technology must be used to generate revenue in other ways. In addition, open source businesses are heavily tied into their corresponding development communities and open source solution partner networks. The choice of an open source license, or a division of features between open and closed source versions of a product, and other such decisions open source companies must make have significant impacts on the viability of an open source business.

D. A more practical point for law students is to look for internships and clerkship opportunities with companies and law firms known for open source expertise. My employer, Sun Microsystems, for example, is a leader in the open source community and typically offers internships to several law students each year. These students get to see the details behind the hard decisions that business units make in guiding their open source activities. They also get to research details of the law as applied to open source issues, which gives them a level of expertise in a particular subject matter that can follow them the rest of their career.

E. Attend conferences and talks about open source law, as well as trade shows featuring open source businesses. The open source business has become big enough that a multitude of conferences and trade shows are presented virtually every week across the country and around the world. Events like OSCON and the OSBC are fixtures in the open source world, as are conferences like the MySQL User Conference and SugarCon for SugarCRM, to name just a few. Look at the upcoming Continuing Legal Education calendars to see how many seminars are devoted to open source or spend at least an hour on open source. (Shameless plug: I will be presenting a talk on open source business models with Joyce Chow from Apple Inc. at a December 10 PLI conference in San Francisco.) These are all great opportunities to learn how open source works in the real world, and students sometimes get free or reduced fee admission.

F. As a final note of encouragement, do not get discouraged by a lack of technical background (such as engineering or computer science) because this does not need to be a barrier to understanding open source technology and businesses. My college degree was in government and economics with no formal training on how software is written or even the difference between source and object code. While it is true that many law students start with a technical background, it is common for a lawyer in the tech industry to not have a deep technical background. (See the blog of one of my colleagues at Sun who did a survey of college majors of those within the Sun legal group... the results are very interesting.)

Innovation in Open Source Licensing

The constant drive for innovation is one of the distinguishing factors of the technology industry. Even the most significant technological inventions can become virtually obsolete in the span of only a few years. Until recently, the longevity of the most familiar open source licenses stood in stark contrast to the the rapid pace of change in the technologies licensed under their terms. But is the pace of change growing for open source licensing too?

Evidence of the longevity of open source licenses is easy to find. The Mozilla Public License 1.1 was created in the late 1990s. It has not only survived in the same form to the present day, but it remains one of the most popular and well respected licenses. The Apache license, originally released in 2000, has been consistently used in the same form since it was updated to version 2 in 2004. Until the recent release of version 3 of the GNU General Public License, version 2 survived as the most popular and longest lasting open source license of all time, remaining unchanged for more than 15 years. The stability of these licenses over time spans of more than 10 years is impressive when one considers that most proprietary software vendors revise their end user license agreements every one or two years with each new release.

On the other hand, recent developments might be an indication of innovation in open source licensing. The release of version 3 of the GPL in 2007 indicates that the open source marketplace needed a license that performed essentially the same functions as version 2, but refined the application of those functions to the new realities of the software industry, such as the rise in importance of patents, and the awareness that use of GPL-licensed code is prevalent in embedded hardware components. The Affero version of GPL (treating network access to an application as a form of distribution that triggers application of the GPL's source code distribution obligations), a seldom used option for GPL users, was originally released in 2002, but it too has been revised in connection with the release of GPLv3. (Note: The 2006 release of the Honest Public License by Funambol CEO Fabrizio Capobianco directly equated "network communication" with "distribution", whereas the Affero GPL v1 itself used different terms but probably had the same effect.)

Other, more significant types of license innovations are occurring. Consider the Cilk Arts Public License, a newly created license made pubic in November 2008 by a company named Cilk Arts, which provides multiprocessor application platform performance optimization. This license is intended to address the "loophole" in the GPL concerning the fact that users of GPL-licensed software can modify and use the software internally without any obligation to release modifications to the public. This concept truly is an innovation when you consider that the right to use software internally without obligation is one of the inherent freedoms the Free Software Foundation tries to protect. Whether it will be adopted to any significant degree by the open source community remains to be seen.

It is also important to point out that not all of the recently released licenses are necessarily innovative. Consider approval of the Microsoft Public License (Ms-PL) and Microsoft Reciprocal License (Ms-RL) in 2007 by the Open Source Initiative as meeting the OSI's definition of open source (though the licenses have been in use since 2005). These licenses are not innovative in that they operate much like the new BSD, Apache 2.0, and MPL. In fact, these licenses turned out to be quite controversial, not because they contradicted the norms of open source licensing, but because people feared Microsoft was attempting to gain an unfair advantage by having its own version of open source licenses while many other comparable, popular licenses already existed.

In recent years we have seen new open source licenses released to, among other things, address changes in the software industry (GPLv3), address perceived deficiencies in existing open source licenses (Cilk Arts Public License), and to spin existing open source license templates to address a particular company's business needs (Ms-PL and Ms-RL). In my view, of the licenses discussed above, only the Cilk Arts Public License represents true innovation in the field of licensing. The others are simply incremental improvements applying the same license features to new situations. Maybe there are other "out of the box" attempts at creating a new license out there and I would love to hear about them (please send your comments). At the same time, however, we should all consider whether we truly need license innovation and at what point a company-specific twist on open source licensing transforms from addressing a legitimate business need, to being nothing more than a vanity license.