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.

Prize Fighing in the Clouds

Ding! Ding! Welcome to the main event! In one corner, we have cloud computing heavyweights Amazon, Microsoft, Google and Salesforce ... In the other corner, we collection of cloud computing heavyweight contender including IBM, Sun AT&T, Cisco, EMC and VMware. Let's get ready to rumble!

The rapid emergence of clouds as the next big thing in computing, and the positions being staked out by the participants look more like a prize fight than the garden variety competition we are used to seeing in technology development. Battle lines have been drawn based on the recent release of the Open Cloud Manifesto - a position paper created by a collection of technology companies (IBM and the other contenders above) to advocate for open standards that will lead to open clouds.

Critics of the Manifesto, Microsoft in particular, claim that it was created without soliciting industry-wide input in an open manner, and openness demands the inclusion of all interested parties. In spite of the controversy over the Manifesto, all technology providers would argue that standardization is good for the development of an industry around clouds. Some of the opposing parties have already agreed to "bury the hatchet" in favor of interoperability. It is inevitable that standardization will occur, and the only question is how long it will take, and whether it will occur through a voluntary Manifesto or similar community agreement, through alliances between technology companies , or through a de facto standard resulting from a dominant industry entity. In any case, we are only in the first round of a 15 round marathon.

All the focus on the Manifesto and standardization misses an important broader point. The discussion calls into question how competitive and effective open source can be in an emerging industry. It's clear that open source can create massive disruption in existing proprietary industries, and that closed business models are best at protecting legacy revenue streams from closed source businesses. As Matt Asay recent noted, companies have every incentive to maximize the lock-in of their customers and will be wary of committing to an open standard at the expense of lock-in (the Prisoner's Dilemma). At the same time, it's not clear that being open even solves the problems of vendor lock-in.

Regardless of whether we believe that open source and standardization are the best models for disruption or prevention of lock-in, the cloud industry should embrace open source to promote quality. The fact is that open source produces quality software, and it is quality that will provide the knock-out punch in this cloud battle. As a result, my recommendation is for companies in the cloud space to start with an open platform if they are newcomers, and existing players should move to a more open platform in these early days of the industry. After all, even big punchers like Amazon only address a portion of the spectrum of technologies needed to fully realize the potential of the cloud. This way we can speed the move to standardization and avoid the problems of proprietary lock-in that we have see all to often over the life of the computer industry.

Keep it a clean fight, no hitting below the belt, and may the best fighter(s) win.

In-House Counsel - Managing Open Source

In addition to attending the 2009 Open Source Business Conference in San Francisco, I had the pleasure participating in a legal panel presentation - Managing the Use of Open Source Software in a Proprietary Environment: Lessons from In-House Counsel. Virginia Tsai Badenhope from the Smithline Jha law firm moderated the panel, which included Joyce Chow from Apple, Angela Ziegenhorn from Symantec, and Duane Valz from Yahoo!. We discussed the building blocks of good open source policies and business strategies.

The companies represented on the panel each had a unique perspective on the issue. Apple's open source policies evolved over time from ad-hoc e-mail requests to a fully automated workflow review process. Yahoo! relied on a number of employees who were active and well respected in the open source community to formulate an appropriate open source policy. The importance of cross-product security and technical reviews for Symantec products led Symantec to the creation of an open source review board to address its open source policy needs. Finally, Sun serves as an example of a company that has made open source as a core strategy supported by a robust open source policy, but many details of the policy required significant adaptation after the acquisition of MySQL.

All companies need a strategy for handling open source including bringing open source components in house, distrbution of products as open source, and relationships with the community. The following building blocks are worth considering as a starting point:

• License Matrix: Analyze and categorize common open source licenses to create a more consistent and efficient review process for inbound and outbound open source.
  

• Review/Approval Process and Tracking System: Establish a review process that gathers relevant information and archives approvals including a copy of relevant open source licenses. This process should scale based on need, which could range from a simple spreadsheet to a searchable database coupled with an automated workflow approval tool. Consider whether the review process should also include a separate technical and/or security review of the applicable code.
  

• Written Open Source Policy: A written policy aligned with an organization's business strategy and risk tolerance sets a common set of expectations for everyone. These policies are most effective when developed with input from engineers and business owners.

• Open Source Officer and/or Open Source Review Board. An open source officer is a necessity for any organization that is regularly involved with open source. Also consider whether a cross-functional open source review board is appropriate. Such boards should include business, engineering and legal members. The open source officer or review board often resides in a chief technology office or similar functional group and is responsible for defining high level strategy and initiative, and can also be involved in the review/approval process for particular usage of open source.
  

• Internal Training and Guidelines in Support of Strategy. Formulate internal training materials and guidelines to maintain consistency in application of strategy. This is particularly important in organizations that decentralize decision making authority on open sourceissues rather than centralizing it in a review board or similar body.
  

When considering what to include in a policy, the following principals might help in prioritizing objectives:

• OS policies and processes must continually evolve. Don't assume your policy will serve all your needs indefinitely, and don't be afraid to modify it to address new issues.

• Settings goals and defining strategy are critical to good open source decision-making. Because open source issues are often ambiguous with no inherently right or wrong position, decisions cannot be made in a vacuum.

• No matter how many policies, processes and tools are in place, each open source decision requires the application of independent judgment by someone with a functional understanding of open source issues.
  

I hope this discussion will help clarify thinking and provide some inspiration for finding the right strategy for your organization. Please leave your comments with other ideas that might help in developing an open source policy or business strategy.

Highlights of OSBC 2009 - Day 2

The second day of the Open Source Business Conference in San Francisco again had many thought provoking presentations. The day started with a trio of keynote presentations from executives from Sun Microsystems, Microsoft and IBM. In my opinion, Sun CEO Jonathan Schwartz's keynote address on Clouds was the best presentation of the Conference. (Disclosure: I work for Sun.) As a result, instead of summarizing the entire day, this post focuses on clouds.

As the hot new technology trend, Cloud computing attracts a good bit of interest and was mentioned in virtually all of the keynotes to some degree. I have been caught in the cloud hoopla too, but have had difficulty identifying what makes it different from software as a service. Until this morning, I have not been able to find an answer, but Jonathan Schwartz's presentation pulled together many of the missing pieces.

Schwartz explained Sun's vision for clouds, which includes 3 types of clouds each of which can be deployed in public and private environments. The three clouds are:

1. Infrastructure as a Service - This is a packaged operating system for use in a data center. Amazon's EC2 is a good example.

2. Platform as a Service - These types of clouds go a step beyond infrastructure while trading high switching costs for enhanced value. Google's docs and related services are an example.

3. Application as a Service - This is the type of cloud many enterprises have already experienced. It extends from a platform to implement a fully functioning application over a network in a manner similar to what we already experience on our computers. SugarCRM's offering is a common example.

The public/private distinction is important. While many enterprises will be able to utilize a public cloud and avoid the IT overhead, some enterprises will require private clouds behind their firewall to address security concerns and regulatory requirements (such as HIPPA and GLB in the health care and financial industries). Schwartz sees each enterprise utilizing a "network of clouds" that are mixed and matched to meet its needs.

While this taxonomy of Sun's vision of clouds made them relatively easy to understand, my moment of gestalt came as Schwartz explained that the cloud is not only the ultimate embodiment of super computing, but it is the next logical step beyond open source. As open source becomes a mainstream business strategy, I have struggled with the question of "what happens next?"

I now understand how the benefits of the open source in the application space can be amplified when applied to clouds. (On the point of open source as mainstream, Matt Asay, GM and VP at Alfresco, and co-founder of the OSBC, described the state of open source as reaching the end of the "cancer" phase and beginning the "pragmatism" phase, with a continued need to emphasize evangalism.) I also understand that the vision of clouds (not just Sun's vision) goes well beyond traditional SaaS offerings to encompass a much larger, interconnected infrastructure with much greater potential for a qualitative leap in how business is conducted and problems are solved. No doubt, cloud computing will keep the legal community busy for years trying to understand how to adapt our old methodologies to this new environment.

Matt Asay has his own post that emphasizes other elements of Schwartz's presentation that is worth reading.

For more details on Sun's cloud computing solutions, check out their web site.

[Updated to fix some typos.]

Highlights of OSBC 2009 - Day 1

Yesterday I attended the first day of the 2009 Open Source Business Conference in San Francisco. This is the premiere event for anyone interested in open source and has separate tracks specifically appealing to Executives and Managers, Developers, Venture Capitalists, and Attorneys. This is a great place to not only see and hear all the "rock stars" of the open source industry, but you can even meet and talk to them in person ... it's like having a backstage pass, but without the groupies.

I attended several interesting sessions on the first day and some of the key points that stood out to me are below. I also participated in a session on managing open source within an organization with an excellent panel: Virginia Tsai Badenhope from Smithline Jha law firm, Joyce Chow from Apple, Angela Ziegenhorn from Symantec, and Duane Valz from Yahoo! I'll have a separate post on that in the next couple of days.

-New Meaning of "risk" in open source. In the past, open source discussions focused (often unnecessarily) on risk, specifically referring to the perceived risk with the quality of the software. Now, however, the stronger view is that NOT using open source software is risky... risky in the sense that IT managers might lose their jobs if they don't cut costs. (Matt Asay noted this in his keynote opening remarks.) The survey data presented by Michael Skok of North Bridge Venture Partners backed this up with unfamiliarity with open source ranking much higher as a barrier to adoption than legal concerns.

-Don't lose focus on innovation and quality. A good deal of discussion occurred around whether the current economic difficulties benefit open source. The majority view is that yes, indeed, those in need of software solutions are more likely to look to open source as a free or low cost alternative to proprietary software.

However, several presenters also pointed out that open source has always stood for more than cost savings and the open source community has worked hard to demonstrate the pace of innovation and quality of open source software. Marten Mickos, SVP of the Databased Group at Sun (at least for a little longer) made this point very well in the panel discussion portion of the keynote. During the Marketing in Open Source presentation moderated by Sun's Zack Urlocker, Greg Armanini from Zimbra (Yahoo!) emphasized this point saying that we don't want to lose the check on the innovation checkbox in procurements. It would be a shame to lose that message in the marketing push around low cost solutions. John Roberts, CEO of SugarCRM also said that the ability of customers to maintain control over the software and avoid lockin is critical.

-Issues of open source "purity" are not longer important. Creating a business with open source software is well accepted and must not be seen as a contradiction to open source values. This evident in the mainstreaming of open source in the software industry, the breadth and quality of open source solutions, and the fact that litigation of open source issues is becoming more common.

-The next frontier for open source is enterprise IT. This is where the big money is for the open source industry, and it is evidence of the legitimacy and broad acceptance of open source by even the most conservative customers. (Note - Jonathan Schwartz, CEO of Sun Microsystems (Disclosure: I work for Sun), said Sun's data shows that ALL of the Fortune 500 companies use open source.)

-Disruption is great for business, but don't disrupt adoption. Marten Mickos and other panelists had commented that a good business strategy is to target any industry that has not yet been disrupted by open source. Michael Skok of North Bridge Venture Partners further clarified this notion by emphasizing that adoption by users must still be easy. In other words, do not disrupt the ability of end users to obtain and use the product.

I found all of these points useful in further clarifying how best to implement open source as a business strategy and I hope you do too.

Open Source Prime Time? Sometimes...

No doubt the open source movement is having a significant, tangible, positive impact on the technology industry. It's success grows every day as we see it moving up the priority list of IT Managers and CIOs in large part because of the cost savings it offers. Even though open source has arrived on a macro scale, I see plenty of difficulties on a micro scale, which reminds me open source needs to make significant strides to be truly mainstream.

The micro level difficulties range from quirky annoyances to significant impediments to performing necessary activities. For example, I spoke at a PLI legal continuing education course on open source licensing a few months ago, and I will speak on a panel at the Open Source Business Conference next week. Both presentations required submission of slides and associated documentation prior to the presentation. A message went out to presenters: "Our presentation machines *do not* support OpenOffice." Microsoft PowerPoint and Microsoft Office were the only supported formats (in fact, sometimes even PDF is not supported). In addition, when collaborating with colleagues, no matter how carefully one converts OpenOffice documents to Microsoft Office formats, formatting and content problems are almost certain to occur.

[Update: OSBC presenters received an e-mail update today notifying us that OpenOffice documents are in fact supported for the presentation. Great news! One small step towards making open source practical for everyone in all circumstances.]

On an even more granular level, while open source tools are generally pretty good, they are not quite ready for full product use. Redlining, for example, is a critical tool lawyers and others use for tracking changes between different versions of contracts. While I use OpenOffice a majority of the time and am largely satisfied with it, the document comparison feature is inaccurate and unreliable. (For a positive spin on use of OpenOffice and other open source software in legal workflows, check out the Open Source for Lawyers website.)

My point is not to steer you away from open source. On the contrary, I am a heavy user of open source applications for my work and personal projects including Mozilla Thunderbird and Lightning for e-mail and calendar, and GIMP as a Photoshop alternative. However, I am acutely aware of the limitations of these applications when it's crunch time. When I have 15 minutes to produce a redline that will properly display all the sneaky changes an opposing attorney has made to a contract, I simply can't rely on OpenOffice. I hope this changes sometime in the near future.

Magic and Fear vs. Open Source Reality

I am surprised at how easy it is to let the magic or fear of open source sidetrack discussions that should be firmly rooted in legal considerations. Maybe this is because open source evokes such polarized reactions ... true believers show fanatical devotion to the open source movement as if it is a religion, while technology dinosaurs grumble about risk and cling to the notion that open source is a fad. The reality, of course, is that the majority of us fall somewhere in between these extremes and are in a constant state of assessment as to how best to use open source to our advantage. In making these assessments, we need to take care that we don't let the rhetoric around us cloud our judgment.

Attorneys need to pay special attention to this because one of the critical roles we play is to give an honest assessment of the facts and risks. Unfortunately, even the most experienced attorneys can be distracted by the level of rhetoric around open source, particularly when open source isn't a primary practice area. Like all legal issues, analysis of open source issues requires a disciplined approach. Here is short hierarchy of things to consider in order of priority (using GPL as the context in some cases):

1. Know the law. This is obvious, yet open source discussions often fail to include an explicit discussion of basic legal issues. In his 2001 essay on Enforcing the GNU GPL, Eben Moglen (then General Counsel of the Free Software Foundation) made it clear that even though the idea of free software is unusual in the world of proprietary intellectual property rights, "as a copyright license the GPL is absolute solid." Contract law is as important to open source as copyright law. The Federal Circuit Court of Appeals used contract law to reach its ruling in the recent Jacobsen v. Katzer case. Finally, the increased litigation surrounding the GPL (such as the Busybox line of cases and the FSF v. Cisco case) are as important a reason as any to make sure you know what the law says about open source.

2. Know the GPL. The basic concepts of copyleft and the goal of the GPL seem easy enough to understand - if you modify GPL-licensed code, you must distribute your modifications in source code. While this is generally true, the details of the GPL are critically important to determining how to comply with the license. The Software Freedom Law Center's Practical Guide to GPL Compliance provides a list of details that could be the subject of claimed violations. Truly understanding the GPL can be an impossible task when we consider the flexibility and ambiguity intentionally built into the GPL. Reading and understanding the SFLC's Practical Guide, FSF's FAQs on the GPL and other resources is important in interpreting the GPL.

3. Understand the community's priorities. One of the distinguishing elements of open source is the deep involvement of the community. Even if you think you have the "right" answer to a particular open source question under the law or based on a valid interpretation of the GPL, the community might reach an equally valid answer under its own analysis and interpretation. As a result, open source activities cannot be considered in a vacuum.

4. Evaluate where your business goals fit. Don't let irrational exuberance or paralyzing fear over open source rule your decision making. Open source decisions are business decisions like any other within an organization and should be subject to the same types of review and decision making considerations. Open source is a tool for use in achieving business objectives, but is not an objective in itself.

Admittedly, none of this is new ... these tips are considerations businesses evaluate every day. Even so, consider this a friendly reminder that open source is neither magic nor the bogeyman. It is just another tool in your toolbox and should be treated accordingly.