Expanding Open Source Enforcement Strategies

What comes to mind when you hear "open source enforcement"? Probably the names "Busybox" and "Software Freedom Law Center". These organizations are good examples of the "cease and desist" style of enforcement in the open source context. But an enforcement strategy should go beyond "cease and desist" to also include other considerations such as alignment with business strategy, product development and business model considerations, and promotion of open source education.

A. Aligning Enforcement Strategy With Business Strategy

Enforcing intellectual property rights always sounds like a good idea. Unfortunately, the typical cease and desist and litigation strategy has significant pitfalls including requiring vast resources and risking the loss of goodwill with customers, partners and the community. Aligning enforcement strategy with business strategy clarifies which enforcement activities will have maximum impact while minimizing risks. The question is, how do you align these strategies?

Looking at the size and goals of a company is one place to start. Many open source vendors today are relatively small and privately held. These companies prioritize rapid growth, building adoption and proliferating products over converting customers to cash. These companies could reasonably choose to avoid tricky enforcement issues under the theory that any customer, paying or free, in or out of compliance with a license, is one more customer that can be converted to cash sometime in the future.

By contrast, other open source companies are either publicly held, or privately held and on the verge of generating a return on investment. Accumulating customers is not the focus of these companies, but the traditional cease and desist and litigation approaches to enforcement of unauthorized copies could be seen as a quick way to make money for investors.

B. Building Enforcement Success Into Your Product

Enforcement begins with the choices you make as to features to include, the license that applies and the business model. For example, DRM (digital rights management) is a dirty word in the open source community, but it can be a valuable tool in enforcement. Companies with a subscription model can use DRM tools, such as a digital fingerprint, to track subscription periods and to confirm whether particular installations are eligible for support and services.

Licenses make a difference in enforcement too. The popularity of GPLv2 is due in large part to its viral terms, which make the mere threat of enforcement enough to drive compliance, particularly with traditional proprietary software companies. GPLv3 offers an even more intriguing range of enforcement options because it allows licensors to easily apply their own conditions for enforcement opportunities.

A company's chosen open source business model makes a difference too. As mentioned above, companies with a subscription model often worry about enforcement because they want to ensure the services and tools they provide are only available to licensed servers. By contrast, companies with an open core model might not be as concerned with unauthorized availability of the software because they make their money by enabling additional features or functionality.

C. Safety in Numbers

One of the most successful enforcement strategies adopted by proprietary software companies could be a model for open source enforcement strategies too. Many of the leading software companies are members of the Business Software Alliance (BSA), an organization that not only organizes anti-piracy and license compliance programs, but also promotes public policy initiatives including intellectual property and development policies. Possibly the greatest advantage of the BSA is that it allows licensors to pursue enforcement strategies collectively, thus allowing enforcement resources to be pooled while avoiding the risk of individual members losing goodwill. The uniformity in approach also creates predictability in license rights and when enforcement is appropriate.

Open source companies could come together to form their own Open Source Software Alliance (OSSA) and realize the same benefits. Ideally, the proposed OSSA could also partner with the Free Software Foundation to add credibility to the positions it takes and bridge the gap between the open source and free software movements. Unfortunately, the gap between open source and free software is likely too big for the FSF to endorse an organization like the OSSA.

These are just a handful of ideas that I hope will help open source companies break out of the "cease and desist" box to realize that enforcement means so much more than adversarial confrontations and litigation.

Word Play

Judge Learned Hand, among the most celebrated American jurists, once wrote, "The language of law must not be foreign to the ears of those who are to obey it." Yet, law is very complex. Lawyers are in a never ending quest to express complex thoughts in as simple a way as possible. Words are a lawyer's tools of the trade. Some of the commonly used words are descriptive, some are fanciful, some are latin, and some are beyond explanation.

Here is a short selection of legal terms I have always found interesting -- not necessarily because of their legal import, but sometimes just because I like the way they sound. Also, please take the survey on the right and tell me which of the words on my list is your favorite, and leave a comment if you have others you would like to share.

Caveat Emptor
Meaning: Buyer beware.
Interest Factor: This deserves to be on the list if for no other reason than it played in prominent role in a Brady Bunch episode, no doubt inspiring an entire generation of children to choose a career in law. Aside from the pop culture reference, it is good advice.

Clawback
Meaning: A provision in a financial arrangement that enables the recovery of prior payments. (Clawback is more appropriately categorized as a financial term, but it is directly related to legal documents.)
Interest Factor: Much of the discussion on our current financial crisis revolves around clawbacks on executive compensation, particularly for executives from failed companies or companies receiving government subsidies.

Cramdown
Meaning: A bankruptcy term describing a situation in which a court imposes an involuntary reorganization plan at the expense of some classes of creditors.
Interest Factor: This term immediately caught my attention in bankruptcy class in law school. Not only is it perfectly descriptive of what happens in bankruptcy, I also always though it would make a great name for a rock band.

Disparate Impact
Meaning: A theory of liability in employment discrimination cases that relies on a showing that a protected class of people is wrongly treated differently even though employment policies are applied equally.
Interest Factor: News reports on Judge Sonia Sotomayor, President Obama's Supreme Court nominee, frequently include references to her role in a ruling by a panel of Second Circuit Judges in Ricci v. DeStefano, a case concerning whether a test for hiring firefighters in New Haven, Connecticut had a disparate impact on minorities.

Expressio unius est exclusio alterius
Meaning: The expression of one thing is the exclusion of another.
Interest Factor: This latin phrase is one of the foundational elements of logical thought and has applications well beyond the law. When interpreting contracts, it stands for the important principle that parties agreeing to include a list of items are presumed to have intended to include only those items, and other items must not be inferred. Applying this in a broader context, the more detail one provides, the more exclusive the description. Simple, powerful and true.

Jus Cogens
Meaning: A fundamental principle of international law accepted as a norm. Genocide and slavery are common examples.
Interest Factor: I will always remember the distinctive German accent in which I first heard this term spoken ("juice kookens") . A guest German law lecturer introduced this legal concept to our international law class in law school. While this term is valuable in its recognition that certain principles are almost universally recognized as boundaries of conduct, care should be taken to ensure the term is not mistakenly applied so broadly that it interfere with legitimate discussion and dissent.

Res Ipsa Loquitur
Meaning: A thing that speaks for itself, often abbreviated as "RIL".
Interest Factor: Along with "expressio unius...," this is one of the classic latin terms used in legal writing. The term is most often seen in the context of tort law when the cause of an injury is apparent on its face, but direct evidence is difficult to find.

How does this tie into open source? It doesn't ... at least not directly. However, it is interesting to note that many of the most popular open source licenses avoid the use of traditional legal terms and virtually all avoid latin terms. This is likely due to the fact that developers rather than lawyers wrote the first comprehensive free software licenses (like GPL).

This is just a small sampling of the wonderful world of legal terminology. Please share your favorites!

[Note, the "meanings" above are drawn primarily from the Nolo Press legal glossary, the Law.com dictionary, the FindLaw legal dictionary, the free legal dictionary, and Wikipedia.]

Back to Basics

Open source business models are a hot topic these days. Blogs are filled with in depth discussions on open source topics such as choosing the right license, building a strong community, and deciding which software should be open and which should be closed. This blog is no stranger to open source business models. While it's easy to jump right into the intricacies of open source (for an example of the level of minutia that arises in the open source business model conversation, see this link with a "simple" chart summarizing the different types), the truth is that open source means nothing unless is fits within a good business strategy. That's why I say it's time to get back to basics.

The most basic question for any business is, "how will we make money?" The answer is never as simple as "use open source." In the software industry, like any other business, a good business strategy starts with at least three fundamental elements: developing a product, attracting attention, and delivering value. Open source is simply a new spin on traditional approaches to implementing a good strategy and it can play a role in each of these ares.

Developing a Product: Regardless of whether a software product is open or closed source, it still goes through the same types of development milestones from concept phase to general availability. Throughout this process, the developer must decide how to allocate resources for quality testing, bug fixing and feature inclusion. One of the great virtues of open source as a development model is that it can speed development time and product quality by leveraging the community's input particularly in identifying and fixing bugs, but also in identifying high-priority features.

Attracting Attention: A great product isn't worth much unless people know about it. The mere mention of "open source" attracts attention, which makes it a fantastic marketing tool. The freedom that comes with open source software ... freedom to try it, modify it, play with it ... makes it easy for users to choose your software over the competitors' offerings. Even better, open source freedom includes the freedom to distribute, which means users can deliver your software to even more potential customers.

Delivering Value: Finally, it's not enough to develop a product and attract attention. Ultimately the product must provide users with something valuable... something worth paying for. Having a strong relationship with an open source community means that a software developer has a clear view into what users deem important. The open source development model allows developers to deliver products that address customer needs directly, which makes those products more valuable to users.

Adopting an open source business model is not a guarantee of success, but its disruptive power can complement a traditional business strategy and improve chances for success. For lawyers advising clients on open source strategies, it's very important to avoid the paralysis of legal analysis that comes with open source. Lawyers need to understand the fundamental business strategies of their clients and the industry as a whole. In short, never forget the basics.

April Roundup

A number of news items grabbed my attention this month ... for instance, I vaguely recall a story about one big tech company buying another, but the names escape me. In any case, a number of interesting open source blog postings appeared in April. Here is a sampling of posts falling in two basic categories:

Open Source as a Hobby and Business

• Connecting Hobby and Business in Open Source - How are some businesses able to harness the passion of developers for their open source hobby to create open source success? Dana Blankenhorn illustrates that it takes more than good software and a good business model to create a successful open source business.
  

• Open Source Business Strategy: About the Open Source Whole Product Concept - Roberto Galoppini explores the idea that successful commercialization of open source requires delivering a fully realized product. In my opinion, productization is the critical element differentiating an interesting project that is viewed as a fun toy from an enterprise class tool that customers are willing to pay for.

Open Source in Government

• Five Ideas to Get FOSS Into Governments - Sun's open source officer, Simon Phipps [Disclosure: I work for Sun], offer six (in spite of the blog title's reference to five) concrete ideas to speed government adoption and use of open source. Because of their size and influence (both as exemplary users of open source, and through their ability to impose procurement and usage rules), governments are important players in the open source movement. Broader government adoption of open source would be a great benefit to the industry as a whole.
  

• Participatory Legislation: the Italian Democratic Party Launches a Wiki - This blog post describes two cases of governments taking first steps towards applying open source principle to the legislative process. Specifically, the post mentions efforts in New Zealand and Italy to allow the public more direct input into writing laws. These small steps mark what I believe will result in a more participatory governing process that will ultimately lead to more accountable government.
  

• Election Industry Trade Group Issues Report Examining Open Source Voting - The Election Technology Council, a trade group US voting system vendors, recently published a report concluding that open source and proprietary software products must be treated differently for purposes of governments making decisions about voting technology citing complexity in management and lack of accountability in traditional open source projects among other things. My view is that the Election Technology Council is perpetuating the type of fear, uncertainty and doubt we typically see in industries not prepared for competition from open source vendors. While it is true that the integrity of the voting system requires certain minimum standards including security assurances, open source software can surely satisfy those needs.

Other hot topics included the importance of channel sales in growing the scope of the open source industry, and deeper discussion of the status of the emerging cloud industry , and what type of open source license is appropriate for cloud technology.

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.