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.

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.

FSF Motives in the Cisco Case

One of the comments I received to a recent post questions the motives of the Free Software Foundation ("FSF") in its complaint against Cisco, and whether the FSF is overreaching in the remedies it proposes. Specifically, the comments reference The Software Lawyer blog posting entitled Free Software Foundation Sues Cisco: Some Criticism. To summarize, the blog post questions whether the FSF would accept GPL compliance as a solution to the disagreement with Cisco and goes further to say that "[the FSF] wants to push Cisco around and it wants money."

I think these views are overly cynical of the FSF's motives. I also disagree that endorsing the FSF's actions results in granting a licensor power to choose substitute license terms. Below, I discuss my reasoning for these conclusions in more detail in hopes of illuminating the issues in the broader discussion around the meaning of license compliance and the role of license enforcement in the open source world. Please also note that I am not concluding that the FSF will be successful in its litigation either through a judgement on the merits of the case or a favorable settlement. Instead, my intent is to illustrate that the FSF's actions appear reasonable.

[Note: I have no knowledge of the FSF's or Cisco's thoughts, reasoning or internal discussions on these matters - all of my comments are based on the complaint and public statements by these entities and commentators.)]

FSF Motives

The views presented in the comments and blog post suggest that the FSF motives are pointed more towards self interest than support of the goals of the free software movement. To the contrary, the FSF's actions indicate that it is legitimately trying to enforce the principles of free software by ensuring that Cisco honors the freedom of its users to have access to source code. No doubt the FSF would like to make an example out of Cisco and would like to see onerous penalties (including monetary damages) imposed for failure to comply as a means of discouraging other potential infringers, but this is consistent with enforcing the principles of software freedom.

The commentary also cites the FSF's requirement that Cisco appoint an open source officer as a potential remedy outside the scope of the complaint. While this might seem unusual, it is consistent with a common litigation strategy in which plaintiffs ask for more than they might be entitled to from a court. This tactic helps push settlement discussions and alternatives to litigation remedies. In fact, FSF is not the first to use this approach. Similar terms have been agreed upon in the string of Busybox cases, which were also litigated by the Software Freedom Law Center. These actions indicate a good litigation strategy rather than impure motives or overreaching.

Motives of a Large Company as an Alleged Infringer

The commentary also assumes that large companies in Cisco's position, would necessarily do their best to comply with license terms as fast as possible, and that such a company would not continue shipping an allegedly infringing product unless absolutely certain of ability to comply. In turn, the commentary suggests that this indicates the FSF has unreasonably deemed Cisco's proposed compliance activities as inadequate. This conclusion is not supported in my view.

It is fair to assume that a company in Cisco's position would perform a risk analysis based on the FSF's stated concerns and could reasonably decide to respond by engaging FSF directly. This strategy would permit the company to work through compliance options over an extended time period. From a purely utilitarian standpoint, this approach seems more favorable than immediately pulling a product suspected of GPL infringement without first consulting the FSF, which would result in further difficulties. No doubt in the multiple years of discussion between Cisco and the FSF, both parties understood that some sort of compliance actions were appropriate, but they had differing interpretations on the types of remedies and time frames for resolution. As a result, it appears that the FSF likely has a reasonable basis for its conclusion that Cisco was not acting fast enough and the use of litigation was a way to stress the importance of compliance is justified.

Remaking the Rules

The claims that FSF's proposed remedies are "remaking the rules" and that it "gets to choose the terms of reinstatement" also are not warranted. The GPL and LGPL licenses immediately terminate once a licensee violates their conditions. Once termination occurs, a licensor can choose to enforce an infringement claim and use the threat of damages awarded by a court as leverage to negotiate a settlement that includes more than monetary damages. This is the approach the FSF is taking with Cisco and it seems consistent with good litigation strategy.

In fact, the FSF has also chosen to work with Cisco for several years to obtain compliance without litigation, which further indicates the reasonableness of its actions. The FSF's proposed remedies are separate and distinct from the rights available to Cisco and all other potential licensee under the GPL. The FSF could not remake the rules of litigation remedies even it wanted and it doesn't seem fair to conclude that the FSF is trying to remake the rules or make up substitute license terms.

In short, whether the FSF will be successful in reaching a favorable judgment on the matters in the complaint or obtaining a favorable settlement with Cisco remains to be seen. Even so, the FSF's motives and actions seem reasonable in the context of the allegations in the complaint.

Jump On the Bandwagon

Last week I attended a very informative CLE on Open Source Software 2008: Benefits, Risks and Challenges for Software Users, Developers and Investors, and was lucky enough to join Joyce Chow from Apple in presenting a session on Open Source Business Models. What made the seminar so useful was the breadth of topics it covered … everything from the nuts and bolts of open source licenses, to the technical details of linking and derivative works, and even ethics in open source (presented in part in a very entertaining fashion by Dave Marr, one of my colleagues at Sun). Bob Pierce, a former colleague of mine at Adobe, provides an informative review of the presentations on his blog.

In talking with other presenters and attendees, it became clear that the law surrounding open source software has reached a milestone. The skills needed to support an open source software business are no longer practiced by a handful of attorneys, and instead are skills that every attorney should have. Examples of the importance of understanding open source appear almost daily:

• Current economic troubles make the low cost and convenience of open source software particularly attractive to IT departments and businesses of all sizes.
  

• Cisco has been sued by the FSF and SFLC for failure to comply with the GPL - having a effective open source management process, knowing how to comply with open source licenses and ensuring such compliance occurs is critical to virtually all software businesses.

• The Open Inventions Network is pooling patents and prior art to protect Linux and the open source community from patent lawsuits - the open source community controls intellectual property rights for the benefit of the community.

• Gartner research shows that 85% of enterprises currently use open source software and the other 15% will within the next 12 months - even if you think your client doesn't use open source, it almost certainly does.

These are but a handful of examples, but searching everything from broadly circulated business periodicals to the most narrowly pointed open source geek blog will yield a virtually limitless supply of information on the growing importance of the open source model.

In short, this is the time to jump on the band wagon or be prepared to be left behind.

Innovation in Open Source Licensing

The constant drive for innovation is one of the distinguishing factors of the technology industry. Even the most significant technological inventions can become virtually obsolete in the span of only a few years. Until recently, the longevity of the most familiar open source licenses stood in stark contrast to the the rapid pace of change in the technologies licensed under their terms. But is the pace of change growing for open source licensing too?

Evidence of the longevity of open source licenses is easy to find. The Mozilla Public License 1.1 was created in the late 1990s. It has not only survived in the same form to the present day, but it remains one of the most popular and well respected licenses. The Apache license, originally released in 2000, has been consistently used in the same form since it was updated to version 2 in 2004. Until the recent release of version 3 of the GNU General Public License, version 2 survived as the most popular and longest lasting open source license of all time, remaining unchanged for more than 15 years. The stability of these licenses over time spans of more than 10 years is impressive when one considers that most proprietary software vendors revise their end user license agreements every one or two years with each new release.

On the other hand, recent developments might be an indication of innovation in open source licensing. The release of version 3 of the GPL in 2007 indicates that the open source marketplace needed a license that performed essentially the same functions as version 2, but refined the application of those functions to the new realities of the software industry, such as the rise in importance of patents, and the awareness that use of GPL-licensed code is prevalent in embedded hardware components. The Affero version of GPL (treating network access to an application as a form of distribution that triggers application of the GPL's source code distribution obligations), a seldom used option for GPL users, was originally released in 2002, but it too has been revised in connection with the release of GPLv3. (Note: The 2006 release of the Honest Public License by Funambol CEO Fabrizio Capobianco directly equated "network communication" with "distribution", whereas the Affero GPL v1 itself used different terms but probably had the same effect.)

Other, more significant types of license innovations are occurring. Consider the Cilk Arts Public License, a newly created license made pubic in November 2008 by a company named Cilk Arts, which provides multiprocessor application platform performance optimization. This license is intended to address the "loophole" in the GPL concerning the fact that users of GPL-licensed software can modify and use the software internally without any obligation to release modifications to the public. This concept truly is an innovation when you consider that the right to use software internally without obligation is one of the inherent freedoms the Free Software Foundation tries to protect. Whether it will be adopted to any significant degree by the open source community remains to be seen.

It is also important to point out that not all of the recently released licenses are necessarily innovative. Consider approval of the Microsoft Public License (Ms-PL) and Microsoft Reciprocal License (Ms-RL) in 2007 by the Open Source Initiative as meeting the OSI's definition of open source (though the licenses have been in use since 2005). These licenses are not innovative in that they operate much like the new BSD, Apache 2.0, and MPL. In fact, these licenses turned out to be quite controversial, not because they contradicted the norms of open source licensing, but because people feared Microsoft was attempting to gain an unfair advantage by having its own version of open source licenses while many other comparable, popular licenses already existed.

In recent years we have seen new open source licenses released to, among other things, address changes in the software industry (GPLv3), address perceived deficiencies in existing open source licenses (Cilk Arts Public License), and to spin existing open source license templates to address a particular company's business needs (Ms-PL and Ms-RL). In my view, of the licenses discussed above, only the Cilk Arts Public License represents true innovation in the field of licensing. The others are simply incremental improvements applying the same license features to new situations. Maybe there are other "out of the box" attempts at creating a new license out there and I would love to hear about them (please send your comments). At the same time, however, we should all consider whether we truly need license innovation and at what point a company-specific twist on open source licensing transforms from addressing a legitimate business need, to being nothing more than a vanity license.

Copyrights: Alive and Kicking in Open Source

As mentioned in my previous post, this is the first in a series of posts about the role of intellectual property rights in open source businesses. Copyrights and copyright ownership are a significant part of all open source businesses and are as relevant today as ever before.

In a world where the most popular open source license (the GNU Public License) embodies the philosophy of "copyleft," it would be easy for an open source company to ignore the value of copyrights and copyright ownership. It is even easier to ignore copyright ownership with the great success of a company like Red Hat whose business is built on a foundation of software with so many copyright owners that the concept of ownership becomes virtually irrelevant. In spite of this, open source companies must make copyrights and copyright ownership a top priority, and must implement business policies that protect and exploit copyrights as necessary to make their chosen open source business models effective.

Copyright ownership seems "old school". For decades, proprietary software companies have tightly controlled their copyrights in, and generated revenue by, granting limited scope usage rights to customers. The rise in popularity in open source business models in recent years has changed the way software companies use copyrights and the rights they grant to customers. Companies that license their software as open source, by definition, can't prevent others from exploiting their copyrights to make a better product, or by setting up a consulting or service business based on the same software. Differentiation is the only way an open source company can survive in this environment, and copyright ownership is a critical element of differentiation for any open source business models.

Most open source business models roughly fall into two categories: dual-license or service-oriented. Open source companies that retain ownership of copyrights (either by creating code themselves or through an assignment of rights from contributors) can implement a dual licensing model. While the purists in the open source world might see the use of closed source value-add components as a contradiction to the open source values, realists recognize that the value and quality of open source software cannot be sustained unless a revenue stream accompanies it. The dual license model gives open source companies that own copyrights incredible flexibility. Not only can they license their software to companies that would not typically entertain use of open source software by providing a closed source license, but they can also develop add-on components that retain the open source nature of the core software while generating value that was not previously there.

Open source companies that implement a service-oriented business model can also benefit from copyright ownership and differentiation. These companies can extend the value they provide beyond their services by creating their own add-on components for which they own the copyrights. These components can be licensed as closed source, or under a dual-license model, which gives an open source company a new level of flexibility.

Open source companies with all levels of revenue can enjoy the good news that copyrights are generally easy to protect and exploit. They are created spontaneously upon creation of copyrighted work and can be exploited through basic license agreements or through transfer of ownership. Registration of copyrighted material, which enhances a company's ability to enforce copyright infringement claims, takes very little time or money. Even in cases where copyright ownership is not deemed important as a primary business strategy, open source companies should pursue ownership and protection of copyrights to the greatest degree that makes sense for the chosen business model to preserve flexibility and enable differentiation.

In my next post, we will look into possibly the most important intellectual property right of all for open source companies: trademarks.