Fitting Open Source Pieces Into the Inbound Licensing Puzzle

The decision to bring outside technology inhouse is an important one for technology companies big and small.  It requires a clear strategy that provides the greatest benefits at minimum risk exposure. Though open source issues are often singled out as a unique case, they should be treated as but one facet of a company's broader inbound technology strategy.

Companies are founded for the express purpose of pursuing a specific vision, and technology companies do this by creating intellectual property. Inevitably, technology companies reach a point in which their in-house development resources cannot achieve company goals at a reasonable cost. That is when they consider bringing in outside technology either through an acquisition or a licensing arrangement. The benefit of an acquisition is that the acquired intellectual property can be treated as internally developed technology (with some important caveats, of course).

Inbound Licensing Risks
The other option is inbound licensing. While inbound licensing can be used to quickly achieve technology development goals, it can also introduce significant risks. Some important risks to consider in designing an inbound licensing strategy include:

• Third-party dependency - By choosing to license technology rather than build or acquire it, a company risks being dependent on the technical knowledge and intellectual property rights of the licensor. This means the company must rely on the licensor's assessment and representations as to intellectual property rights. The company also might not have the expertise to support the licensed technology, which would require an additional expense.

• Usage Limitations - A company's strategy for inbound licensing should always include obtaining rights as close to ownership as possible, including regarding use of source code. Unfortunately, few licensors are willing to grant such broad rights and the real difficulty for the licensee is to determine what restrictions are acceptable. Term limits and termination rights might also be considered usage limitations in that ending the right to use outside technology can be detrimental to a company's product plans. It can be difficult to create a one-size-fits-all policy on usage limitation because each use case will likely be different.

• Lack of differentiation - Unless a company obtains an exclusive license, any technology it licenses could also be licensed (or even acquired) by others, including by competitors. As a result, a company should consider whether to develop different inbound licensing strategies for technology based on whether it is a critical feature for customers.

• Sales compensation complexity - A company that licenses technology might distribute it as embedded in one of its own technologies, or as a separate standalone technology. The latter case in particular can create difficulty in setting sales compensation. Sales incentives designed to encourage complete solutions that include outside technology can easily and unintentionally be perverted to drive sales of the outside technology to the detriment of the company's own products.

• Intellectual property infringement - An inbound licensing strategy should be built on a license agreement template that includes broad warranties and indemnification rights for intellectual property infringement claims along with uncapped liability on such claims. This eliminates much of the additional risk inbound licensing introduces as compared to internal development. However, indemnification rights and uncapped liability are only as good as the solvency of the licensor.

• Fees - The most tangible impact of licensing outside technology is the cost of doing so. A one-time fee is clearly better than less predictable royalty fees. However, companies should not underestimate the cost of maintaining a development team to create similar technology inhouse or assume that inhouse development always provides a cost advantage.

Adopting the wrong strategy could have a serious negative impact. Not only could it result in significant monetary loss, but it could also impede internal innovation, reduce product quality, slow time to market, or impact other matters that might hurt customer satisfaction. Smaller companies might even lower their attractiveness as a target in an acquisition, their value as a target, or their value in an initial public offering. Companies should also remember that a strategy's deficiencies might not be evident for years. They often show up at critical times, such as when a company changes its business models, or achieves mass adoption of a product that depends on a third-party technology.

Open Source
You'll note that I haven't mentioned open source. Many of the widely used open source technologies present minimal inbound license risks. For example, they are typically free, embedded components without license limitations. In addition, third-party dependency is often not an issue because one of the primary purposes of open source technology is freedom from vendor lock-in. On the other hand, the broad availability of open source technology means that it often is better suited for basic, foundational features rather than differentiating features. Open source licenses also lack any guarantees or protections regarding intellectual property rights and infringement claims. In many cases, a commercial technology provider will offer support or a commercial license to open source technology, which subjects it to the same type of analysis with regard to the risks above. In short, though the mix of benefits and risks might be different with open source components, a single inbound license strategy can easily accommodate use of open source.

Role of Legal Advisor
While an inbound license strategy is not necessarily the domain of a company's legal advisers, lawyers can play a significant role in designing and implementing the strategy. In large companies, a business development function might own the inbound license strategy, which would leave the lawyers drafting inbound license agreements with the role of ensuring consistent implementation on a deal level.

By contrast, small companies might not have separate resources for these types of business development activities. In fact, small companies might be so focused on chasing revenue that they might not factor in the long term risks of an inconsistent inbound license strategy. In those scenarios, lawyers can play a critical role in implementing a rational approach by reminding their clients of the long term risks inherent in inbound licensing.

Summary
Companies of all sizes should develop and frequently review their inbound license strategy to ensure it aligns with their short- and long-term development needs. The strategy should evolve as a company grows and its development and business priorities change. Companies should also ensure that at least one functional group within the organization is tasked with implementing or enforcing that strategy. This could either be a dedicated internal deal team like a business development department, or the lawyers that work on inbound licensing deals. While open source might have a unique mix of benefits of risks, it should still fit neatly within the chosen inbound license strategy.

Breaking the International Log Jam: Cloud Computing and Open Source

Possibly the biggest challenge to the continued maturation of the open source and cloud technology industries is inconsistency in the treatment of legal and other issues across international borders. Great progress has been made on this front in the open source context both through community efforts, and by greater legal certainty from court decisions, legislation and government policies. While the cloud will benefit from the growing international consensus on open source, it differs in ways that create important limitations. We need a new international legal consensus for these technologies to continue their rapid evolution.

A. Open Source

Examples of the emerging international consensus on the validity of open source principles are becoming more common. Till Jaeger, a German attorney affiliated with the gpl-violations.org project, recently published an article on Groklaw entitled, "Enforcement of the GNU GPL in Germany and Europe." What I found most striking is that both the types of issues arising in Germany, and the manner in which they are adjudicated and resolved in Germany have direct parallels with the United States. In fact, I recommend this article as an excellent educational tool or refresher on the specific aspects of GPL most likely to lead to compliance issues whether you are in the U.S., Europe or elsewhere.

The consensus is also evident in that governments are increasingly accepting, or even adding preferences for, open source as part of their procurement policies.  For example, in 2009, the United States State Department and President Obama's Administration made headlines in the IT world for making open source prominent parts of their IT objectives. Roberto Galoppini also recently reported on a ruling by the Italian Constitutional Court finding that an Italian state law preferring open source is acceptable under Italian law.  All these factors show that open source is becoming mainstream with remarkable consistency in treatment across international boundaries.

B. Cloud

At first glance, the growing international consensus on the legalities of open source and the tight link between the open source and cloud technologies would seem to indicate that the cloud will achieve similar consensus. Take the Affero GPL as an example: the license is both nearly identical to the familiar GPL, and is specifically targeted for the proliferation of technology in a cloud and networking context. Unfortunately, minor differences between the Affero GPL and the standard GPL require a significant rethinking of how terms like "conveyance," "distribution," "derivative work," "corresponding source code" and other should apply in a cloud context.

The cloud also lacks international consistency in other ways too. Summarizing a 451 Group analysis, Charles Babcock at InformationWeek notes that U.S. investors appear to invest more money in cloud computing than their European counterparts, and the technology infrastructure for the foundational elements of cloud computing are not as mature in Europe as in the U.S. These impose practical challenges to the growth of the cloud computing infrastructure in Europe.

Differences in the U.S. and Europe legal environments potentially present an even bigger barrier. The 451 Group analysis also notes that the U.S. and Europe fundamentally differ in how they regulate data protection. As but one example: the U.S. Patriot Act, emphasizes the government's ability to access information under certain circumstances; whereas, the European Union Data Protection Directive emphasizes the rights of individuals to privacy and protection of their personal information. While these purposes do not necessarily conflict, they clearly are not aligned enough to claim any kind of consensus on how to handle data in a cloud environment.

C. Possible Solutions

We are nearing the time when cloud computing will become so fundamental to our use of technology that we need a set of legal principles, not just technical standards, that ensure broad access to data across international boundaries while also ensuring protection of intellectual property in a manner that promotes innovation and investment regardless of jurisdiction. Possibly the best model from which to start is the Berne Convention for the Protection of Literary and Artistic Works. Though the scope of adoption of the many clauses of the Convention has varied over the more than 100 years since its inception, the Berne Convention represents a broad consensus and acceptance of a core set of basic principles in copyright protection, which are largely consistent between the more than 160 signatory countries.

The same type of international discussion should focus on principles of validity and enforcement of open source agreements like the Affero GPL, as well as address appropriate measures for data portability while preserving data protection standards. The U.S., Europe and other jurisdictions should strive to reach at least a basic consensus on these issues in much less time than the 100+ years for the Berne Convention to reach its current level of maturity. The pace of change in cloud technology and our reliance on the cloud will face meaningful limits sooner rather than later. The growing international consensus on how to apply basic legal principles to open source in a consistent manner should serve as a model for achieving consensus over cloud issues.

Truth in Open Source Advertising

"Open core" has attracted a bit of controversy recently. Commentators have questioned the viability of open core as a meaningful product strategy and whether it differs from traditional product strategies. Regardless of how this debate is resolved, the discussion illustrates why software vendors employing any type of open source model need to pay particular attention to the way they market open source. The impact of using terms like "open" and "open source" could soon extend beyond the development community to include legal ramifications.

A. What is Open Core and Why the Debate?

Open core is a product delivery strategy that combines a core set of open source functionality with an added set of proprietary functionality. This strategy has been widely discussed over the last 2 years both to define what it is, and whether it has any value to software vendors and customers. Most recently, the discussion has shifted to a debate between two points of view:

(1) Open core is meaningful because it allows software vendors to develop software at a lower cost.

(2) Open core is nothing more than a twist on the traditional freemium model used by software vendors for years, and even if it lowers vendor costs it does not create additional value for customers. In addition, the open core strategy might be weakening as the industry evolves.

B. Vendors Must Use the Term "Open" With Care

While the debate over the viability of the open core strategy is interesting, it points to a larger issue that software vendors should be clear on how and why they use terms like "open" and "open source. Failure to do so could squander goodwill with the development and open source communities, and even make them more susceptible to risks like false advertising claims.

The terms "open" and "open source" have evolved from a set of almost religious principles espoused by non-profit organizations like the Free Software Foundation and the Open Source Initiative, to marketing buzz words, and the result is that these terms mean different things to different people. For example, Matthew Aslett recently noted that "[a]s more and more proprietary software vendors, and software service providers have engaged with open source development, the concept of an 'open source vendor' has become meaningless." Brian Prentice of Gartner recently explained another example of this change - open core providers are including end users and resellers in their definition of "community," which traditionally consisted only of developers who might participate in an open source project.

Questions on the meaning of these terms extend beyond the open core context to the open source world at large. Even GNU/Linux users are beginning to wonder what "open" means given that many versions of the open source operating system contain a significant amount of non-free software both in the kernel and in surrounding component.

C. Becoming a Substantive Legal Issue?

Traditionally, software vendors that abused the use of terms like "open" and "open source" only had to fear backlash from the very community they were attempting to leverage. The open source development community would punish these vendors by notifying the world of these vendors' non-open practices on blogs and message boards, which would result in lower community participation in sponsored projects.

Now, however, more proprietary vendors are vested in the open source business and are looking for ways to look more open and advertise their openness more aggressively. Software vendors clearly see a marketing advantage to using terms like "open" and "open source." With more money at stake, the competitive nature of this marketing could bring more scrutiny from competitors.

Competitors in the technology industry have long uses fair advertising laws to raise doubt over marketing claims as an indirect means of competition. In the United States, for example, they use rules and policies of the Federal Trade Commission, which which might now be more easily applied to the open source context. At a basic level, these rules and policies set forth the principle that advertising must be true, non-deceptive and fair, and claims must be backed by evidence.

At issue is whether a software vendor can and should use the terms "open" and "open source" in contexts where the definitions of these terms have different meanings in different communities, and whether vendors use them in a way that properly indicates the actual value that customers are seeking. Some of the common false advertising theories that a competitor might raise are: deceptive advertising; bait and switch; unfair comparative advertising; misleading endorsements and testimonials; and unfair price comparisons. For example, is it deceptive or unfair under advertising laws to advertise a free and open source product, or use such a product in a competitive comparison, when the vendor knows that the target customers will only be interested in the paid-for version of the product that has different features?

I raise these points not to trigger fear of a FTC crackdown. Instead, the concern is that competitors in a highly competitive environment might be willing raise seemingly insignificant violations as a way to slow down their rivals by interfering with their marketing campaigns. The real risk from these concerns is hard to predict when we consider that the term "open" is not tied to an objective standard and is ambiguous outside the traditional open source community.

D. Bottom Line

As in all customer relationships, fairness and honesty are the best policies both in direct communications and in marketing. Don't emphasize the terms "open" and "open source" in your marketing materials and messaging unless your open source offerings actually provide value to the customer. Also, be mindful of the changing perception of "open" in the industry as a whole, not just the traditional open source community, and adjust your marketing accordingly. These are good practices both for the health of your business and for minimizing legal risks.

[Note: Non-substantive editorial modifications were made within hours after the initial post.]

OSBC 2010 - Highlights - Day 2

Day 2 of the 2010 OSBC again had several interesting sessions, including some insightful legal sessions.

A. Maximizing the Value of an Open Source Business

If you are looking for a nuts and bolts "how to" session on building an open source business from the ground up, this is the type of session you need to attend. Benchmark Capital's Rob Beardon made it through only half his presentation on "Tactics and Metrics for Scaling an Open Source Business" because of the volume of audience participation. Beardon, along with assistance from Zack Urlocker (former MySQL VP) and other open source veterans in the audience, sketched the following blueprint:

Guiding Principle: the value of an open source business is directly proportional to the size of the community and the company's ability to influence and monetize it.

Key Areas:

1. Foundation - every open source business must start with the following attributes to be successful:

• Technology - must add value by solving a customer's problem
  
• Community - must attract the best in the field with the promise of innovation and disruption
  
• Business Model - choose between the "owner/builder" (innovation) and packager/distributor (commoditization) models
  

2. Tactics - position for rapid scalability with viral awareness, then generating adoption, THEN sales

3. Metrics - traditional metrics are not relevant. State of the art is to measure web traffic, customer acquisition percentage and lead nurturing tools

A successful open source business will be able to create a "closed loop demand management" workflow that fuels growth. It is important to note that this methodology is not much different that standard "Entrepreneur 101" tactics, but is highly tuned to the particular needs of an open source business with a goal of a liquidation event for its VC vendors.

B. Legal Matters in Open Source
I attended several legal sessions on Day 2 as well. I won't recount all the details of the discussions, but here are some of the most interesting points:

1. GPL Enforcement. Karen Sandler, General Counsel of the Software Freedom Law Center, gave a thorough review of common open source software license incompatibility. Of note was her helpful clarification on the requirements of the GPL (Sec. 3 of v2, Sec. 6 of v3). In particular, she confirmed that the common practice of including only a download link to source code is not enough to satisfy the "written offer" requirement of the GPL. However, she also emphasized that a download link might be enough for all practical purposes as long as it is relatively easy to find the source code. This is true at least for the SFLC, which is more interested in software freedom than litigation. This is likely a relief for many developers that try their best to comply, even when the details often elude them.

2. Best Practices. Virginia Tsai Badenhope of Big Fix provided some great pointers in her session on how to handle open source within an organization. Her comprehensive checklist consisted of 5 categories:

• Inventory and assess usage of open source
• Comply with terms of open source licenses
• Implement an open source policy to whatever degree necessary to meet the business needs
• Update outbound licenses to ensure they reflect the use of open source
• Update inbound licenses to ensure suppliers make proper representations and warranties for open source

The details under each of these categories will vary depending on the company and particular circumstances, but it is critical to have a set of procedures in place to ensure nothing slips through the cracks.

3. Affero GPL. In his session on Open Source Litigation, Catalin Cosovanu from Wilson Sonsini primarily discussed litigation on enforcement of the GPLv2, but audience questions quickly transformed the discussion into the legalities of the Affero GPLv3. For example, the lack of definitive caselaw on the meaning of "distribution" under the traditional v2 means that the more comprehensive notion of "conveyance" under the could trigger more legal claims and lead to more uncertainty, particularly in the Affero network context. The network terms of Affero also make the notion of "corresponding source code" more ambiguous, particularly in a cloud environment. Finally, even simple questions like "where should the written offer appear?" are not as simple in the Affero context.

OSBC 2010 - Highlights - Day 1

For the third year in a row, I attended to Open Source Business Conference. Though I missed the morning keynotes, Day 1 was very enjoyable. I saw old acquaintances, met new ones and heard some insightful discussions on open source, the cloud and more. The unofficial themes of the day can be summarized as follows:

OSbc -> osBc -> Cloud -> Data

I use this shorthand to mean that the "open source" discussion has evolved from an emphasis on what open source means to software development; to an emphasis on the business opportunities open source provides; to open source as a critical element of the cloud movement and the next step in evolution of open technology; and, finally, to the principal that control of data will ultimately determine success in the cloud, further evolve technology and challenge the "open" movement.

I attended 3 sessions: a panel on the future of open source success, a discussion of Oracle's use of and participation in open sourece (note - I now work for Oracle), and Tim O'Reilly's future-focused closing keynote. Here are what I found to be the most interesting messages:

A. Open source solutions are commonly accepted by paying customers.

This theme came up in multiple contexts. Many open source products are widely used in the end user and enterprise IT environments. Many are also making significant profits. Customers seek open source for the quality of the products and the ability of open source to provide solutions that other vendors are not addressing. Cost savings is no longer the main benefit sought.

B. Open source continues to drive innovation.

Many software and business categories are still highly susceptible to the disruptive impact of open source alternatives. Open source has also impacted how software companies think about the sales and marketing processes. It cuts the cost of sales by removing the need to engage customers until they decide the software is valuable. Also, the high volume nature of many open source businesses has forced companies to design more efficient lead scoring and other sales processes.

C. However, open source might be approaching its limits.

The success of open source in the high volume, commodity sales model in open source might not be duplicated in other contexts. Also, implementations of so many value-add models over the years indicate how hard it is to identify the right balance between free and paid offerings. Each open source offering must monetize the unique solution it provides to customer problems, and support alone almost certainly will not be enough.

Possibly the biggest indication of the limits of open source is the dearth of public "pure" open source companies like Red Hat. Large companies have steadily acquired many of the most prominent open source companies and projects. While this is not necessarily bad for open source, it means that the impact of pure open source has been diluted throughout the industry instead of concentrating the potentially disruptive power.

D. The cloud is the natural evolution of the open source revolution, and is more transformative than open source.

Open source is likely the precursor to a much larger disruptive force - the cloud. Both the technology and spirit of the open source movement are critical to innovations in cloud technology. Cloud technology is already changing the way we look at operating systems and application stacks.

E. The cloud is important but still has significant limits - data ownership and control.

Companies that control the cloud infrastructure likely have limited commercial opportunities. Much like the experience of telco equipment providers, once the technology is deployed, few customers remain. By contrast, those companies that control how data is used within the cloud have great flexibility in providing compelling business offerings.

F. Rights and obligations concerning data will be the critical issue to address.

Tim O'Reilly illustrated the point best by asking whether we (the public) want a single company (like Google) controlling all our data. Everything from restaurant reviews to personal health records could be held by a single party that has its own ideas on how to use such information - good or bad. O'Reilly further emphasized the potential impact by highlighting the trend toward devices that contain sensors and wirelessly stream the resulting data to the cloud. The stakes are likely higher for data held by governments and the open source methodology could drive openness in this context.

G. Several companies and technologies were named as ones to watch.

1. VMWare - VM Ware has a chance to build an entire stack from operating system to applications, which might be a serious threat to Microsoft.

2. Red Hat - as the most prominent pure public open source company, the community had high expectations that the company would serve as a hub to aggregate an open source stack. Many believe Red Hat missed its opportunity to do so.

3. Google - Google has the unique ability to easily and efficiently integrate open source, cloud technology, and data

4. Opscode - provider of open source datacenter configuration management and infrastructure framework tools

5. Gluster - provider of open source data storage and management solutions

6. Erply - online solution for running an online business including everything from invoicing to relation management; great for open source startups looking for low-cost, powerful business solutions

7. Pentaho - rapidly growing open source business intelligence solution

8. Eucalyptus - open source "Infrastructure as a Service" cloud solution

Obligatory End of Year Post - 2009

Yes, I know it's already 2010, but this post is still my official "end of 2009" post. I've included some highlights from the posts on this blog along with my choice of top 5 open source stories and themes of the year. Please add your comments on what you think are the top stories for 2009.

Reflections on This Blog

The readership of this blog grew substantial in 2009 and I am very thankful for that. Visitors from 30 states, 29 countries and 6 continents came to this blog with the top 3 countries being the United States, Brazil and the United Kingdom. I have to admit, the prominence of Brazil surprised me. Visitors seemed to be attracted to a wide variety of subjects, but management of open source within a company and GPL enforcement seemed to be the favorites. Here are top 5 most visited posts of the year, beginning with the most popular:

1. In-House Counsel - Managing Open Source
2. FSF Motives in the Cisco Case
3. Obligatory End of Year Blog Post (2008) (emphasis on the FSF-Cisco case)
4. Highlights of the Open Source Business Conference - Day 1
5. Show Me the Money at OSCON - Venture Capital and Open Source

Top 5 Open Source Stories

Shifting to the industry as a whole, the top stories of 2009 also illustrated the importance of in-house open source management and GPL enforcement among many other themes. Below, I have provided my list of the top 5 stories and themes of the year:

1. Oracle Acquisition of Sun Microsystems - As a Sun employee, I have a deep personal interest in this deal, but it is also a significant event for the business of open source (not to mention the software and hardware business too), particularly the EU's competition investigation of the MySQL business. The deal could be characterized as a definitive affirmation of the importance of open source in that even companies whose success is perceived to rely on the traditional proprietary software model (such as Oracle), see open source as an important strategic element. Questions on the MySQL aspect of the deal even prompted industry heavyweights like Eben Moglen, founding Director of the Software Freedom Law Center, to explore the impact of the GPL.

2. GPL Enforcement Actions - The relative popularity of my blog posts on the Cisco-Free Software Foundation litigation (which has since settled) is one indication that GPL enforcement is a hot topic. This trend gained momentum throughout 2009 and will likely continue to do so in 2010. Examples include the Software Freedom Law Center's December announcement of litigation against Best Buy, Samsung, Westinghouse and 11 other entities on behalf of the owners of BusyBox, and a French court case in which users of GPL software got a ruling affirming their right to receive the source code to that software and modifications.

3. Microsoft Release of GPL Code - Few companies raise the ire of the open source community more than Microsoft. That's why open source proponents were pleased, and surprised, to see hear Microsoft announce that it would contribute driver code to the Linux kernel. It is not clear whether Microsoft's decision was based on necessity in the face of a potential GPL violation, or a strategic move to enhance compatibility with Linux. Regardless of the motive, Microsoft's actions indicate that even the most sophisticated of companies must pay close attention to their use of open source and honor the provisions of open source licenses. This is especially true in light of the recent enforcement activities discussed in the previous paragraph.

4. US Government Commitment to Open Source - The principles of technology neutrality have long been recognized in the European Union to the benefit of open source software usage by European governments. The United States federal government has not been as accommodating of open source, but at least two events in 2009 indicate a possible change in US attitudes. The US Department of Defense revised its guidelines on use of open source software in October to essentially give it a procurement preference over proprietary software when all else is equal. In addition, it appears that the Obama Administration is actively looking for ways to bring the benefits of open source to government operations.

5. Red Hat's 10 Year IPO Anniversary - Red Hat is commonly viewed as the most successful pure open source company with its status as a Fortune 500 company with a market cap of almost $6 billion and generating over $700 million in revenue in 2009. As such, it's longevity and success are significant barometers on the health of the open source business as a whole. With a lingering cloud over the economy, and the relatively slow growth trajectory of most open source companies, it seem unlikely that we will see any open source IPOs in 2010.

Please post your thoughts on the most important open source events of 2009. I wish the best of success to all of us in this corner of the world we call "open source."

[Note: The "Top 5" portion of this post was updated after the original post to make non-substantive changes for purposes of clarification and adding more reference links.]

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.