Getting Started With Open Source Policies

Earlier this month I had the opportunity to work with Adam Cohn, Senior Corporate Counsel at Cisco Systems, to present a session on "Effective Open Source Development Business Practices" at the Practicing Law Institute's Open Source session on Free Software 2009: Benefits, Risks and Challenges in Today's Economic Environment. With companies of all types and sizes becoming familiar with and using open source software, creation and implementation of open source policies was a focus of our talk.

The structure and contents of an open source policy, as with any company policy, must be tailored to the particular needs of the company. As a result, this post does not focus on the specific contents of a policy (but see this article by Stormy Peters, Executive Director of the GNOME Foundation, with a "how to" on open source policies, including ideas on specific topics to cover within such policies). Instead it targets initial considerations in defining the term "policy," determining whether you need a policy, how open source fits into your risk profile, and if and how open source fits into your business strategy. Next, it offers tips on how to align your policy with your business strategy for maximum effect.

(Note: The content in this post is based on the PLI presentation, but are mine alone and do not necessarily represent the views of Adam, my co-presenter, or our respective employers.)


Initial Considerations

What does "policy" mean?

The term "policy" will have different meanings between companies, between departments within companies, and between individuals within companies. As a result, as you undertake the exercise of determining whether you need a policy and implementing the agreed upon policy, ensure everyone involved has a clear understanding of the meaning of "policy." For example, policies are implemented for a number of different purposes from minimizing operational risk (such as a manufacturing quality check process) to satisfying legal obligations (such as financial policies in support of Sarbanes-Oxley reporting obligations). Looking at this another way, a policy could be something as simple as a set of operational actions, a more complex set of review and approval guidelines, or a vision statement on what open source means to the company. Often, a "policy" will address many of these needs at once.

Do you need a policy?

Not everyone needs a true policy, and even when a policy is necessary, it should be tailored to address the particular needs of a company. Start by identifying the specific problems you are trying to solve, which might span from telling staff that open source software should not be used at all, to implementing robust processes to both use open source in product development and distribute software under an open source license. Also determine whether a separate, standalone policy is needed. You might be able to address the problems you identify through minor updates to existing policies, such as policies on use of intellectual property or review and approval procedures for product development and distribution.

What is your risk profile?

By identifying the risks your policy should address, you will be better able to make your policy meaningful. For example, your company might have a particular sensitivity to one of the following types of risks: (a) fear that use of open source, along with related review and approval procedures, will result in the inefficient use of resource as compared to the perceived benefit; (b) fear of lack of warranty or infringement indemnity; (c) lack of understanding of community needs and dynamics; and (d) lack of understanding on customer concerns and expectations concerning your use of open source. Companies that use open source sparingly for internal purposes alone might view (a) and (b) as bigger risks than (c) and (d) and should adjust their policies accordingly. By contrast, companies that are not involved in open source communities and that frequently distribute closed source products containing open source components might be more concerned about (c) and (d), and they would have different policy needs.

How does open source fit into your business strategy?

As with risk profile assessment, companies must also identify how open source fits into its business goals and adjust its use of open source and related policies accordingly. The results of a year-old Gartner survey indicate that virtually all technology companies use open source software. But, mere use of open source software alone likely should not be deemed an open source business strategy. By contrast, frequent use of open source for revenue generating purposes almost certainly constitutes an open source business strategy. Consider the following broad guidelines for when a business strategy might warrant a robust open source policy:

• Minor policy should be considered: (a) Incidental use of open source in product development; (b) Use of open source in development for internal use

• Robust policy could be helpful: (a) Frequent inbound use of open source in product development; (b) Participation in open source community projects; (c) Sponsoring an open source community

• Policy is strongly recommended: (a) Open source development tools with proprietary “crown jewels”; (b) Services business for a community project; (c) Dual license strategy

Aligning Your Policy With Your Business Strategy

Policies are often designed primarily to address risks or satisfy legal obligations. By contrast, strategies are used to indicate a companies goals to be achieved over a particular time. Policies and strategies cannot exist in a vacuum, and each depends on the other. Policies cannot be narrowly tailored to address important risks unless a strategy exists to help prioritize those risks. Similarly, strategies will not be successful unless proper policies are in place to assist in effective implementation and avoid or mitigate risks. As a result, companies should make alignment of open source policies and strategies a high priority.

Once a company explores the "Initial Questions" identified above, it should consider the following recommended actions to check for compatibility and identify areas where additional consideration is needed:

• Determine whether an operational "how to" guide is sufficient, or is a vision statement appropriate. A hybrid approach is likely most appropriate.

• Identify the specific business cases that would benefit from a policy (see the discussion on "How does open source fit into your business strategy?" above).

• Assess the impacted functional areas. Think broadly, beyond the development and legal teams. Your HR (employee participation in outside projects), IT (internal security), finance (lack of indemnification; revenue recognition), and other departments might also need guidance on how open source will impact their functional areas. Also think outside your company to assess the impact on your customers, partners and the open source community.

• Assign appropriate review and decision-making authority. The more important open source is to your business strategy, the more important it is for your managers to understand what open source issues they can approve, and the proper escalation paths.

• Test hypothetical business cases. While this concept is relatively simple, it can provide a meaningful sanity check before implementing a policy in a complicated business. For example, this type of review might identify that employees do not understand open source issues enough to implement the policy and strategy, which might require more training.

• Manage conflicts with other policies and strategies. For example, a company that rarely uses open source might have an supplier indemnification policy that would not be appropriate if it decides to use open source software more frequently in its operations. Open source components often don't have the warranty and indemnifications protections these companies are used to seeing.

Companies should review their policy/strategy alignment regularly to ensure both that their strategies accurately reflect their use of open source, and their policies address the particular needs of the company.


More Information

You might also find the following web links interesting as you continue your own research into open source policies (note that I do not necessarily endorse or agree with the content in these links, but they provide other perspectives on the policy discussion):

• Black Duck Software - Offers a whitepaper entitled, "Creating and Implementing an Open Source Policy: Five Steps to Success" (registration required)

• ABA Section of Science and Technology Law - Offers both a model open source software policy outline and a model open source software review/approval form that might server as starting points for a policy. These documents were drafted in 2005 by Heather Meeker of Greenberg Traurig, LLP, who is known for her frequent involvement in open source issues, and they are available for reuse and distribution under a Creative Commons license.

• Open Logic and Stormy Peters - Offers a heavily reference "how to" guide for policy creation. As referenced earlier in this post, the article provides more detail on the specific types of content that you might consider adding to a policy. Note: Open Logic also offers papers on how to write an open source policy and open source policy best practices (registration required).

• Digium - This open source telephony software/equipment provider shows (in multiple blog posts here and here) potential customers how to assess whether open source is right for them and to what degree. This is an example of a "policy" designed to promote a particular type of software by a particular provider.

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.

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.