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.

Not Your Ordinary Communities and Contributions

Few terms are more central to the free and open source ("FOSS") movement than "community" and "contribution." The common definitions of these terms are:

Community: a unified body of individuals as - a state or commonwealth; the people with common interests living in a particular area; an interacting population of various kinds of individual in a common location; a group of people with a common characteristic or interest living together within a larger society; a group linked by common policy; a body of persons or nations having a common history or common social, economic, and political interests; a body of persons of common and especially professional interests scattered through a larger society.

Contribution: a payment (as a levy or tax) imposed by military, civil, or ecclesiastical authorities usually for a special or extraordinary purpose; the act of contributing; the thing contributed

But these terms mean so much more in the context of FOSS. Anyone who sponsors, participates in or contributes to a FOSS project needs to understand not only the importance of these terms, but also how their meaning has changed over time.

Starting Point
The community is the core of any FOSS project. Consistent with the common definition, a FOSS community has traditionally been a self-defining group of people and organizations that share the common value of exchanging ideas and intellectual property in the pursuit of creating the highest quality software using an open development model. Until recently, there has been little need to define the community in any greater detail because membership was open to all and carried no obligation to participate, which resulted in the attraction of like-minded participants.

FOSS contributions have traditionally come from individual developers and companies alike. They typically included any materials submitted to the project under a standard set of terms commonly accepted and understood by the community. Again, because the community traditionally shared common values, there has been little confusion as to what constitutes a contribution and what the receiving FOSS project could do with it.

Where Are We Now?
With the growth of the open source movement, the concept of free software has taken on competitive and commercial traits, which has impacted the meaning of "community" and "contribution." Those who sponsor or participate in FOSS projects need to take note of the changes.

In the case of communities, we can no longer assume that the FOSS project sponsor and participants share common values. At a minimum, sponsors and participants might be divided between those that advocate for pure free software principles, and those that use the community for purely strategic purposes in support of a commercial advantage.

The nature of contributions has also changed. Some FOSS project participants might contribute for the purpose of advertising an alternative product or fork, or to incorporate code allowing for easier integration with a commercial product. In addition, the traditional "anything submitted" contribution model, which promoted free exchange of ideas and is the most beneficial to the community as a whole, is less relevant. More recent contribution models include the option for contributors to declare which of their submitted materials are deemed not to be contributions. The legal terms that apply to contributions are sometimes also subject to the influence of commercialization by being narrowly focused on the sponsor's objectives to the detriment of the community's needs as a whole.

How Should FOSS Project Sponsors Respond?
FOSS project sponsors (whether non-commercial or commercial) should carefully consider how to respond to this evolution in the meanings of "community" and "contribution". They should spend more time defining their FOSS goals, more closely monitor FOSS activities and contributions, and implement measures that will further their goals and ensure that the appropriate elements of the community work in their favor.

Specific actions for consideration by FOSS project sponsors include:

• Posting a definition of goals for content, community and participation. This might include a statement of purpose for the project, a definition of community values, and a code of conduct for participants.
  

• Creating separate discussion boards and mail-lists for contributions in support of the project, general discussion about the project without contribution, and discussion of other projects or any other matters not related to the sponsored project.

• Monitoring contributions and discussions to ensure that they are posted to the proper boards and lists, and to ensure that contributions do not contradict the applicable participation model and community values.

• Avoiding alienation of participants even if they appear to contradict community values. For example, even when a project participant uses a project discussion board to promote its own commercial activity, the sponsor should first decide whether to object to that practice. If it chooses to object, it should do so in a way thatfosters inclusion and participation in a rational, pro-community manner, while minimizing the perception that the sponsor is hindering project discussion or participation.

• Treating conditional contributions (i.e., contributions made under terms other than the sponsor's standard terms) as invitations for negotiation to be handled in the same manner as other commercial inbound licenses. Sponsors should not grant exceptions to conditional contributions because that risks contradicting community expectations and undermining the purpose of the project.
  

• Weighing a number of factors when faced with a choice between accepting a conditional contribution or not obtaining any rights to the contribution at all. Specific considerations include: the value of the potential contribution; the scope of rights offered; consistency with the sponsor's commercial strategy; consistency with community values and expectations; perception in the community; and consistency with free software principles. An assessment of these factors could lead to a number of outcomes from a decision that the contribution will not be part of the project, to a decision by the sponsor and contributor to enter into a commercial relationship.

Relationships Matter

After a couple of postings focused on the state of the open source business, I would like to pick up the theme of earlier postings concerning fundamental legal considerations for open source businesses.

Good businesses are built on good relationships ... relationships with customers, partners, and employees. Open source companies have another important relationship to consider ... the community. In the spirit of the old adage "good fences make good neighbors," contracts, instead of wood or brick, help keep good relationships from going bad. While contracts are well accepted in customer, partner and employee relationships, they are not as effective in a community relationship. Whether through contracts or other means, open source companies must address the unique demands they face in balancing their profit motives with open source ideals.

The most fundamental of all business relationships is between vendor and customer, and standardized contracts are a well-accepted means of describing the expectations of these parties. While the commercial contracts of open source companies are generally the same as for proprietary companies, certain virtues of the open source development model allow open source companies to sidestep or minimize the many traditional commercial software contract clauses. For example, the availability of free software before purchase often makes customers less worried about issues like evaluation licenses, performance and ownership warranties, broad indemnification rights, and licensor liability obligations.

Partner relationships of all sorts (marketing, distribution, inbound licensing, joint development, etc.) also are commonplace in the open source business and typically addressed through standardized contracts. Because partners, like customers, can get the value of open source software without paying for it, open source companies must present additional value (such as marketing or referral benefits) compelling enough to entice partners to enter into agreements that provide adequate protection. Specific clauses might include prohibitions on forking the code or creating an unauthorized solution, or an obligation that a partner's solution must always be available under an open source license.

Employees are the most important assets of any technology business. As a result, employment agreements, related agreements governing ownership of inventions created by employees, and confidentiality agreements are regularly used. The traditional templates for these types of agreements are, however, at odds with the open source ideals of community participation because employees of open source companies are also members of the community. As a result, open source companies must challenge themselves to rethink the traditional scope of employer ownership rights and level of oversight in employee participation in outside projects and implement appropriate legal agreements and company policies. This type of flexible approach also has the benefit of being a great tool for recruiting potential employees from the community.

A community relationship is different than the other relationships above in that an open source company can't rely on a contract to set expectations ... the community has no single point of contact that can enter into contracts, and the relationship is based on a constantly evolving application of open source principles as well as trust established over time. However, a company's contributor agreement, the one important community-oriented legal agreement, should reflect community ideals such as by granting contributors joint ownership or broad usage right in contributed code. The community also looks to a company's position on patents as an indication of open source friendliness so a carefully considered patent policy is important see my previous post on patents for more on that). In general, open source companies need to establish a clear business strategy that incorporates open source principles, and be able to clearly and tactfully articulate why the community should accept a particular business decision even when it might conflict with open source ideals. Decisions as to when and how to enforce violations of open source licenses, or when to introduce closed source code into an open source solution are among of the most difficult for the community to accept, but a strong community relationship will help.

Each of these 4 relationships are vital to the success of an open source business. While contracts can play a primary role in open source companies and their customers, partners and employees being "good neighbors," the community relationship, by its very nature, is less predictable and requires trust along with the proper balance between sincerity in honoring open source principles and conviction on business strategies that might be seen as contradicting open source values.

Patents: More Than Meets the Open Source Eye

Copyrights and trademarks are important assets in the software industry and their use is well-accepted by the open source community. By contrast, few software issues are more controversial than patents, and the open source community has been particularly vocal in advocating for the elimination of software from the scope of patentability. Though it would be easy for an open source company to translate the community's views into a belief that patents are not relevant to its business, such an approach would ignore the reality of patents in the software industry and place the company at great risk. A better approach is to create a patent policy that acknowledges the status of patents in the industry, implements appropriate measures to incorporate patents into business strategy, and clearly explains a company's position on software patents to the community.

As with copyrights and trademarks, patents can be tools for differentiation. Proprietary companies often pursue differentiation by collecting patents (either by harvesting them internally, purchasing them, or licensing them). These companies often choose to wield their patents offensively, affirmatively license them for a fee, and/or license them for free (or at least promise not to assert them). This is a core element of their business strategy. Community reaction to these policies usually has little impact on proprietary companies.

By contrast, open source companies often do not include patents as a core element of their business strategy, influenced in large part by their communities.The open source community (and many members of the proprietary "community" for that matter) objects to software patents on philosophical grounds, and also for the practical reason that patent threaten the very survival of popular and innovative open source projects and companies. In fact, many members of the community will not consider a company to be “open source” if it opens it copyrighted materials while claiming patents on the same technology (even if only for defensive purposes). As a result, the traditional approach for open source companies has been to establish a policy against software patents that might also include associated lobbying efforts, or to allow use of patents only for defensive purposes.

Notwithstanding the community bias against patents, open source companies should consider the benefits of differentiation that patents can offer. Once a company determines that patents are critical to its business strategy, it must decide whether to use those patents offensively and/or defensively, grant free patent licenses or covenants not to sue, or submit patents to shared pools. In fact, at least one purported open source company is experimenting with a business model under which it withholds patent rights for commercial use unless a customer purchases a license (though it appears the community will react negatively if the proposed business model becomes reality). Even when an open source company decides not to collect patents in the ordinary course of business, it should still consider whether to collect patents (or licenses) strategically on a case-by-case basis for defensive purposes. Use of patents in these ways might pass community muster if explained properly.

Finally, open source companies should be aware that their actions might define their patent policies without intending to do so. For example, adopting GPLv3, and the patent licensing obligations therein, as the licensing vehicle for an open source project implies that patented materials should not be included in community software unless there is no threat they will be enforced. While use of the GPLv3 is accepted by the community, open source companies should ensure that the patent provisions therein are consistent with its patent policies and objectives before adopting the license.

On first glance, the expense of obtaining patents, and difficulty in enforcing, protecting and exploiting them, as well as the community bias against software patents indicates that collecting patents is of little value to open source companies. However, patents can be valuable tools for differentiation, which might justify the effort and expense. In any case, there are other compelling reasons to think carefully about a patent policy and strategy. Regardless of what policy or strategy an open source company decides upon, it must always recognize the reality of patents in the software industry and consider what the community will tolerate.

In my next blog posting, we will leave the the complexity and controversy of patents behind for a discussion of trade secrets, and we will ask, "how 'open' should open be?"