One IP Lawyer's Opinion

Open Innovation - Time to Broaden Your Perspective

noreply@blogger.com (Gary Spiegel) — Fri, 08 Oct 2010 23:11:00 +0000

Last week I had the pleasure of attending and speaking at the Open Innovation Forum hosted by the UC Berkeley Center for Law and Technology and Chadbourne and Parke LLP. The forum had a broad base of attendees and speakers ranging from consumer products (e.g., Clorox), to telecom (e.g., T-Mobile), to educational institutions (e.g., UC Berkeley professors in law and business), to technology foundations (e.g., Mozilla), and other technology companies (e.g., Genentech, Microsoft, IBM, Cisco, Oracle and others). The diverse background of the participants greatly expanded how I think about “innovation” and the benefits of openness. Here is a summary of interesting points I noted throughout the day. I will write a separate post with more details on the panel on which I participated, “Recent Revolutions: Open Source, Open APIs, and Web Services.”

The forum agenda highlighted the concept of “open innovation” by tracing the foundational models of innovation, recent changes, emerging trends and forward looking prospects. Some important themes that came up throughout the day included:

The parallel existence of open innovation and commercialization models - open innovation models can indeed lead to commercial success
Definitions of innovation - the application of new ideas to create value
Definitions of value - “value” varies under the circumstances and could include quality of products, consumer welfare, promotion of competition, and other measurements
Economic analysis on the true commercial value of open innovation models is lacking even though many organizations have employed such models with success

Dr. Henry Chesbrough, author of several books on open innovation and source of the term “open innovation” itself, gave the opening keynote. He started with the historical sources of innovation: individual inventors, imitators, and R&D shops (large firms). Here, he introduced the “Chandler Paradigm” in which firms control the flow of innovation from R&D within their own organizations, with no inputs into our out of the firm except for the end products. Under this scenario, intellectual property is relative easy to manage. In recent history, Dr. Chesbrough continued, innovators grew to include users of technology, startups (small- to medium-sized enterprises), and non-profit organizations and enterprises (e.g., universities, standards boties, open source foundations, etc.). Innovation in these entities requires that intellectual property flow more freely than under the traditional large-firm model. As a result, from 1981 to 2005, the share of R&D produced by large firms fell from 70% to 37%, while the share from small enterprises grew from 4% to 24%.

The larger number and growing types of R&D players has led to greater openness in innovation models out of necessity. Specifically, the traditional single-firm input/output model from R&D to product has changed so that innovation at both the research and development phases can occur and flow both inside and outside the firm. The emphasis is less on having great ideas because ideas are everywhere. It is now more important to identify value by productizing ideas rather than inventing them. Venture capital firms are one prominent example of entities that create a mechanism for productization of underutilized intellectual property for commercial gain. Dr. Chesbrough also used patents to further illustrate this point. Many entities now hold patents without producing any products based on them. We even see NPEs (non-practicing entities) that hold patents solely to profit from the use of patents by others without producing any innovation of their own.

With this foundation, the discussion moved to traditional means of fostering innovation in collaboration with others. Specifically, the first panel discussed joint ventures, standards bodies, patent pools and cross-licensing. To frame the discussion, the panelists focused on the prevalence and necessity of standards, while highlighting the importance of patents and difficulties in creating an environment for open exchange. Without getting too much into the technical details, some of the important points were:

FRAND (free, reasonable and non-discriminatory) promises may not provide the level of protection parties would hope without difficult negotiations between patent holders
patent pools, cross-licenses and joint ventures are all important tools that can serve to ease concerns over patent claims and provide for a more free flow of technology

The next panel emphasized that innovation can come from virtually anywhere in its discussion of small inventor product development funnels and consumer products. Some of the non-standard examples of innovation included:

a technology company gains access to a new market acting as a middleman between small-developer inventors and OEMs for ad hoc open innovation opportunities where the technology company would not otherwise have the expertise or interest in bridging the market need directly
clearly defining a technology provider’s core value proposition and expertise to determine when M&A of related technology providers is preferred to a joint venture or other arrangement
a consumer products company fostering an online community and working with a venture capital firm to manage the flow of new product ideas from the public and evaluate the value of such ideas under a standardized program that rewards participants

Marshall Phelps, former Microsoft VP of intellectual property management and author of “Burning the Ships” spoke about his experience in the changing role of intellectual property management and commercialization of IP over the last few decades. Picking up on Dr. Chesbrough’s theme that many intellectual property assets (specifically patents) go unused, Phelps noted the great commercial opportunities such intellectual property holds. Taking patents as an example, not only can companies license them for a fee, but they can be licensed in cross-license arrangement to minimize or eliminate possible infringement threats. In addition, collaborations with all types of intellectual property can lead to open innovation and creation of de facto standards. Phelps emphasized that companies must learn how to value their intellectual property portfolio distinct from the rest of their balance sheet assets and look for ways to monetize it aside from pure product development, including by spinning out R&D that will not be used within the organization. In closing, he noted that harmonization of patent laws across national boundaries is, in his view, one of the most important goals in achieving open innovation.

In the final session I attended at the forum, Matt Ocko from Archimedes Capital gave an enlightening description of his view of the role of open innovation today. In short, he was somewhat pessimistic that open innovation has or will result in a great technological leap. Specifically, he used open source as an example: startups spin out open source only when it is not core to their value because they don’t have the resources to maintain it; large companies spin it out to gain competitive advantage rather than from altruism under community ideals. In other words, while open source might lower the cost of disruption, it doesn’t necessarily result in open innovation. Finally, he gave his very interesting macro view of innovation -- open innovation in technology R&D will become less relevant over time as the world reverts to a 19th-century state in which scarcity of physical resources is a barrier to product development.

A lot to think about...

My next post will go into detail on my panel’s discussion on “Recent Revolutions: Open Source, Open APIs and Web Services”

Fitting Open Source Pieces Into the Inbound Licensing Puzzle

noreply@blogger.com (Gary Spiegel) — Fri, 28 May 2010 04:24:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Fri, 16 Apr 2010 22:34:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Fri, 02 Apr 2010 07:40:00 +0000

"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

noreply@blogger.com (Gary Spiegel) — Tue, 23 Mar 2010 04:19:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Fri, 19 Mar 2010 05:47:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Mon, 04 Jan 2010 06:28:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Thu, 24 Dec 2009 03:42:00 +0000

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.

Not Your Ordinary Communities and Contributions

noreply@blogger.com (Gary Spiegel) — Fri, 16 Oct 2009 21:15:00 +0000

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.

Judgement Day for Commercial Open Source ... How Did I Miss It?

noreply@blogger.com (Gary Spiegel) — Fri, 31 Jul 2009 05:48:00 +0000

In a recent Business Week online article, Peter Yared, founder and CEO of San Francisco startup Transpond, describes "The Failure of Commercial Open Source Software". While Yared makes a case that the commercial open source software business hasn't lived up to the hype that it will "change the world," he reaches too far in declaring its failure. A more appropriate conclusion would be to recognize that commercial open source only recently reached broad acceptance as a business strategy and is on a strong growth trajectory. We must measure its success in that context.

Yared's arguments are diverse, but they fail to account for important indicators of open source success:

1. Minimal number of liquidity events for open source businesses. As identified by one of the commenters, several prominent examples of open source liquidation events are missing from Yared's list, including Zimbra, Trolltech and Sleepycat. In addition, the article uses 2003 as a benchmark year, allowing only 6 years to measure exit success. According to a September 2008 MoneyTree Report by PricewaterhouseCoopers and the National Venture Capital Association, the average seed-financing to exit life cycle of a venture-backed company is 8.6 years. As a result, any conclusions about the success or failure of open source businesses, many of which were started within the last 6 years, are premature at best.

2. Continued success of proprietary vendors. Not only is this irrelevant to measurement of open source success, but it fails to acknowledge the growing role of open source in proprietary companies. Companies like IBM, Microsoft, Adobe and Oracle, are milking revenue from their established proprietary business models while they also distribute open source software to generate revenue, influence development communities and drive broader adoption. In addition, measuring open source displacement of proprietary software misses the point, particularly in the short 6 year time frame here. Open source targets adoption opportunities through grass roots growth, which takes longer (but is less expensive) than the hard-hitting direct sales approach of proprietary companies.

3. Success is limited to commodity businesses; Enterprises are not likely to add open source businesses to their lists of approved vendors. These assertions fail to take into account the growing reach of open source throughout the software industry. While it is true that many of the more successful open source companies to date have been in the infrastructure and commodity business, we are beginning to see significant adoption of enterprise and end user open source applications (such as Alfresco, SugarCRM and others). Matt Asay further amplifies the limitations of Yared's assertion by identifying SpringSource as an example of an open source company that innovates and targets enterprise-friendly software development, which is outside the category of traditional commodity software.

4. Cost savings of open source are overstated. This contradicts the conventional wisdom that cost savings is one of the primary reasons companies adopt open source. In an April 2009 Forrester report, 75% of survey respondents said "Reduced IT costs" are critical or very important in their decision to use open source software. In addition, a panel of venture capitalists at OSCON proposed that open source companies can typically save up to 30% in sales and marketing costs as compared to proprietary companies, which leads to quicker profitability, quicker exits and happier investors. Even so, the article is likely correct with respect to mature open source businesses. In two March 2009 Open Sources blog posts, Savio Rodrigues compares the income statement of Red Hat to those of Microsoft and Tibco. In both cases, he concludes it is unlikely that mature open source vendors will be more capital efficient than commercial vendors.

5. SaaS will overtake open source. The general trend away from installed software applications to SaaS and cloud systems is undeniable. As Matt Asay explained on his Open Road blog in May, cloud computing is the natural conclusion of open source, because cloud computing is the ultimate expression of the open source principle that services, rather than the software supported by such services, are the most valuable component of a product offering. But SaaS and cloud business models are having significant growing pains of their own. Customers are concerned about the portability of data, freedom from vendor lock-in, security and standardization and other matters that must be resolved before achieving broader commercial acceptance. (It's a bit ironic that open source software might actually be the best way to address these concerns.) SaaS and cloud businesses appear to be subject to at least the same level of skepticism as open source. As a result, it seems unlikely that SaaS and cloud business models will replace the open source software business in the near future.

6. Open source benefits do not lead to monetary gain. Yared observes that his company uses open source but typically does not pay for it other than contributing code back to projects. This is a common practice and it implies an impending failure of commercial open source. Yared concludes that these factors do "not mean every successful open source project can sustain a commercial company, especially when they are delivering complicated applications rather than simple plumbing." No doubt this is true, but it is also true of proprietary business models and does not lead to the conclusion that commercial open source has failed.

It is fair to question when open source will become as reliable an investment as other technology businesses. In this regard, Yared's article raises some important points for discussion. However, rumors of the failure of open source business models are greatly exaggerated, and any pronouncement on the success or failure of open source is premature.

Show Me the Money at OSCON - Venture Capital and Open Source

noreply@blogger.com (Gary Spiegel) — Thu, 23 Jul 2009 06:16:00 +0000

To my pleasant surprise, Mark Radcliffe (notable open source attorney) announced last week on his blog that his law firm, DLA Piper, would host an open source legal track to run in parallel to the OSCON trade show in San Jose this week. The schedule included a diverse mix of topics that pushed the boundaries of typical legal presentations on the issue of open source. I found the talk on venture capital and open source the most interesting. The panel consisted of 3 seasoned venture capitalists (Josh Stein of Draper Fisher & Jurvetson, Mark Gorenberg of Hummer Winblad, and Vivek Mehra of August Capital) and an experienced open source attorney (Vicky Lee of DLA Piper).

Venture capital is a hot topic of discussion. Several tech publications and blogs are reporting, based on a report issued earlier this week by PricewaterhouseCoopers and the National Venture Capital Association, that venture investment has shrunk to pre-tech-bubble levels, the slow economy is putting a damper on venture capital, and venture funding in the tech industry is down over 50% year-over-year from 2008 to 2009. At the same time, however, the tech sector seems to be attracting more investment in recent months. The panelists at the OSCON session on "Understanding Venture Capital Investments in Open source Projects" seemed to have an enthusiastic view of investment in open source companies.

The panel described several elements that go into their determination of what is a good open source investment. The most fundamental points, however, came during the second session by Larry Augustin on "Choosing a License: Ensuring that Your Intellectual Property Strategy Matches Your Goals". Augustin emphasized that: (1) open source is only a tool and an open source business model alone is not enough to guarantee success or to warrant funding by venture capital firms; and (2) quality is critical to ensuring customers want to purchase a product regardless of whether it is open source or not.

Beyond these fundamental points, the panel discussed the following elements:

1. Successful Business Model

Clear Distribution Rights - Ownership of all the copyrights in a product eliminates uncertainty about distribution rights. When third-party components are involved, however, clarity on rights is important.

Disruption, Platform and Infrastructure - Venture investments are most desirable in quality companies that focus on specific areas: (1) market disruptors in an existing industry; (2) technology that can become a platform; and (3) technology that focuses on infrastructure (because it is most likely to help companies reduce costs).

Free is a Negative - Serious customers do not find as much value in free products as products that they must pay for (Larry Augustin emphasized this point in the second session).

Support and Services - Companies that do not own their code and generate revenue only from services are susceptible to competitors.

Open Core - This is the current popular favorite of open source business models and it has a proven record of generating revenue, which is attractive to venture capitalists for obvious reasons.

Community - Open source products that spring from existing communities or that are developed in parallel with newly created communities can both be successful, but they present distinct tradeoffs. Existing communities provide an available user base that drives quick adoption, but the likelihood of multiple contributors complicates the intellectual property ownership issues.

2. Benefits to Venture Capital Investors

Lower Cost - While the first wave of financing is typically the same for open source and proprietary companies, the second wave often results in significant savings, which the panel estimated to be 30% or more. Specifically, the availability of open source software and related ecosystem allow open source companies to spend less on sales and marketing, which greatly reduces operating expenses.

Quicker Adoption - Because end users always have access to open source software, companies are able to avoid the lengthy proof-of-concept and testing cycles that occur when releasing a product for the first time. The panel felt this could save open source companies up to 2 years of development and testing time.

Easy to Build a Channel - Open source communities are well suited to perform localization, vertical market and other customization for products, which allows open source companies to enjoy the benefits of channel distribution without devoting sales and other resources.

Early Revenue and Exit - The lower cost and quicker adoption enjoyed by open source companies mean that these companies are likely to begin generating revenue and profits more quickly, which means that investors are likely to reach an exit opportunity more quickly too.

3. Net Results for Venture Capital Investors: When open source investment opportunities are carefully screened with the business model considerations above in mind, the benefits inherent in open source companies make these types of investments relatively safe for venture capitalists. At a minimum, investors should not view open source companies as being inherently more risky that other startup venture investments.

In closing, the panel indicated that approximately 15% of their holdings are in open source companies. While this is a significant amount of investment, the percentage is likely to grow over time as new software companies arise and existing ones revisit their business models. At the same time, the 85% of holdings that are not in open source companies is a good reminder that a good idea will attract investors because it's a good idea, not because it's open source.

Expanding Open Source Enforcement Strategies

noreply@blogger.com (Gary Spiegel) — Wed, 01 Jul 2009 05:14:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Wed, 03 Jun 2009 05:53:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Wed, 27 May 2009 04:50:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Wed, 29 Apr 2009 05:47:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Thu, 09 Apr 2009 06:55:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Wed, 01 Apr 2009 05:01:00 +0000

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

noreply@blogger.com (Gary Spiegel) — Fri, 27 Mar 2009 05:33:00 +0000

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.

Highlights of OSBC 2009 - Day 2

noreply@blogger.com (Gary Spiegel) — Thu, 26 Mar 2009 05:15:00 +0000

The second day of the Open Source Business Conference in San Francisco again had many thought provoking presentations. The day started with a trio of keynote presentations from executives from Sun Microsystems, Microsoft and IBM. In my opinion, Sun CEO Jonathan Schwartz's keynote address on Clouds was the best presentation of the Conference. (Disclosure: I work for Sun.) As a result, instead of summarizing the entire day, this post focuses on clouds.

As the hot new technology trend, Cloud computing attracts a good bit of interest and was mentioned in virtually all of the keynotes to some degree. I have been caught in the cloud hoopla too, but have had difficulty identifying what makes it different from software as a service. Until this morning, I have not been able to find an answer, but Jonathan Schwartz's presentation pulled together many of the missing pieces.

Schwartz explained Sun's vision for clouds, which includes 3 types of clouds each of which can be deployed in public and private environments. The three clouds are:

1. Infrastructure as a Service - This is a packaged operating system for use in a data center. Amazon's EC2 is a good example.

2. Platform as a Service - These types of clouds go a step beyond infrastructure while trading high switching costs for enhanced value. Google's docs and related services are an example.

3. Application as a Service - This is the type of cloud many enterprises have already experienced. It extends from a platform to implement a fully functioning application over a network in a manner similar to what we already experience on our computers. SugarCRM's offering is a common example.

The public/private distinction is important. While many enterprises will be able to utilize a public cloud and avoid the IT overhead, some enterprises will require private clouds behind their firewall to address security concerns and regulatory requirements (such as HIPPA and GLB in the health care and financial industries). Schwartz sees each enterprise utilizing a "network of clouds" that are mixed and matched to meet its needs.

While this taxonomy of Sun's vision of clouds made them relatively easy to understand, my moment of gestalt came as Schwartz explained that the cloud is not only the ultimate embodiment of super computing, but it is the next logical step beyond open source. As open source becomes a mainstream business strategy, I have struggled with the question of "what happens next?"

I now understand how the benefits of the open source in the application space can be amplified when applied to clouds. (On the point of open source as mainstream, Matt Asay, GM and VP at Alfresco, and co-founder of the OSBC, described the state of open source as reaching the end of the "cancer" phase and beginning the "pragmatism" phase, with a continued need to emphasize evangalism.) I also understand that the vision of clouds (not just Sun's vision) goes well beyond traditional SaaS offerings to encompass a much larger, interconnected infrastructure with much greater potential for a qualitative leap in how business is conducted and problems are solved. No doubt, cloud computing will keep the legal community busy for years trying to understand how to adapt our old methodologies to this new environment.

Matt Asay has his own post that emphasizes other elements of Schwartz's presentation that is worth reading.

For more details on Sun's cloud computing solutions, check out their web site.

[Updated to fix some typos.]

Highlights of OSBC 2009 - Day 1

noreply@blogger.com (Gary Spiegel) — Wed, 25 Mar 2009 17:34:00 +0000

Yesterday I attended the first day of the 2009 Open Source Business Conference in San Francisco. This is the premiere event for anyone interested in open source and has separate tracks specifically appealing to Executives and Managers, Developers, Venture Capitalists, and Attorneys. This is a great place to not only see and hear all the "rock stars" of the open source industry, but you can even meet and talk to them in person ... it's like having a backstage pass, but without the groupies.

I attended several interesting sessions on the first day and some of the key points that stood out to me are below. I also participated in a session on managing open source within an organization with an excellent panel: Virginia Tsai Badenhope from Smithline Jha law firm, Joyce Chow from Apple, Angela Ziegenhorn from Symantec, and Duane Valz from Yahoo! I'll have a separate post on that in the next couple of days.

-New Meaning of "risk" in open source. In the past, open source discussions focused (often unnecessarily) on risk, specifically referring to the perceived risk with the quality of the software. Now, however, the stronger view is that NOT using open source software is risky... risky in the sense that IT managers might lose their jobs if they don't cut costs. (Matt Asay noted this in his keynote opening remarks.) The survey data presented by Michael Skok of North Bridge Venture Partners backed this up with unfamiliarity with open source ranking much higher as a barrier to adoption than legal concerns.

-Don't lose focus on innovation and quality. A good deal of discussion occurred around whether the current economic difficulties benefit open source. The majority view is that yes, indeed, those in need of software solutions are more likely to look to open source as a free or low cost alternative to proprietary software.

However, several presenters also pointed out that open source has always stood for more than cost savings and the open source community has worked hard to demonstrate the pace of innovation and quality of open source software. Marten Mickos, SVP of the Databased Group at Sun (at least for a little longer) made this point very well in the panel discussion portion of the keynote. During the Marketing in Open Source presentation moderated by Sun's Zack Urlocker, Greg Armanini from Zimbra (Yahoo!) emphasized this point saying that we don't want to lose the check on the innovation checkbox in procurements. It would be a shame to lose that message in the marketing push around low cost solutions. John Roberts, CEO of SugarCRM also said that the ability of customers to maintain control over the software and avoid lockin is critical.

-Issues of open source "purity" are not longer important. Creating a business with open source software is well accepted and must not be seen as a contradiction to open source values. This evident in the mainstreaming of open source in the software industry, the breadth and quality of open source solutions, and the fact that litigation of open source issues is becoming more common.

-The next frontier for open source is enterprise IT. This is where the big money is for the open source industry, and it is evidence of the legitimacy and broad acceptance of open source by even the most conservative customers. (Note - Jonathan Schwartz, CEO of Sun Microsystems (Disclosure: I work for Sun), said Sun's data shows that ALL of the Fortune 500 companies use open source.)

-Disruption is great for business, but don't disrupt adoption. Marten Mickos and other panelists had commented that a good business strategy is to target any industry that has not yet been disrupted by open source. Michael Skok of North Bridge Venture Partners further clarified this notion by emphasizing that adoption by users must still be easy. In other words, do not disrupt the ability of end users to obtain and use the product.

I found all of these points useful in further clarifying how best to implement open source as a business strategy and I hope you do too.

Open Source Prime Time? Sometimes...

noreply@blogger.com (Gary Spiegel) — Thu, 19 Mar 2009 05:39:00 +0000

No doubt the open source movement is having a significant, tangible, positive impact on the technology industry. It's success grows every day as we see it moving up the priority list of IT Managers and CIOs in large part because of the cost savings it offers. Even though open source has arrived on a macro scale, I see plenty of difficulties on a micro scale, which reminds me open source needs to make significant strides to be truly mainstream.

The micro level difficulties range from quirky annoyances to significant impediments to performing necessary activities. For example, I spoke at a PLI legal continuing education course on open source licensing a few months ago, and I will speak on a panel at the Open Source Business Conference next week. Both presentations required submission of slides and associated documentation prior to the presentation. A message went out to presenters: "Our presentation machines *do not* support OpenOffice." Microsoft PowerPoint and Microsoft Office were the only supported formats (in fact, sometimes even PDF is not supported). In addition, when collaborating with colleagues, no matter how carefully one converts OpenOffice documents to Microsoft Office formats, formatting and content problems are almost certain to occur.

[Update: OSBC presenters received an e-mail update today notifying us that OpenOffice documents are in fact supported for the presentation. Great news! One small step towards making open source practical for everyone in all circumstances.]

On an even more granular level, while open source tools are generally pretty good, they are not quite ready for full product use. Redlining, for example, is a critical tool lawyers and others use for tracking changes between different versions of contracts. While I use OpenOffice a majority of the time and am largely satisfied with it, the document comparison feature is inaccurate and unreliable. (For a positive spin on use of OpenOffice and other open source software in legal workflows, check out the Open Source for Lawyers website.)

My point is not to steer you away from open source. On the contrary, I am a heavy user of open source applications for my work and personal projects including Mozilla Thunderbird and Lightning for e-mail and calendar, and GIMP as a Photoshop alternative. However, I am acutely aware of the limitations of these applications when it's crunch time. When I have 15 minutes to produce a redline that will properly display all the sneaky changes an opposing attorney has made to a contract, I simply can't rely on OpenOffice. I hope this changes sometime in the near future.

Magic and Fear vs. Open Source Reality

noreply@blogger.com (Gary Spiegel) — Tue, 10 Mar 2009 06:01:00 +0000

I am surprised at how easy it is to let the magic or fear of open source sidetrack discussions that should be firmly rooted in legal considerations. Maybe this is because open source evokes such polarized reactions ... true believers show fanatical devotion to the open source movement as if it is a religion, while technology dinosaurs grumble about risk and cling to the notion that open source is a fad. The reality, of course, is that the majority of us fall somewhere in between these extremes and are in a constant state of assessment as to how best to use open source to our advantage. In making these assessments, we need to take care that we don't let the rhetoric around us cloud our judgment.

Attorneys need to pay special attention to this because one of the critical roles we play is to give an honest assessment of the facts and risks. Unfortunately, even the most experienced attorneys can be distracted by the level of rhetoric around open source, particularly when open source isn't a primary practice area. Like all legal issues, analysis of open source issues requires a disciplined approach. Here is short hierarchy of things to consider in order of priority (using GPL as the context in some cases):

1. Know the law. This is obvious, yet open source discussions often fail to include an explicit discussion of basic legal issues. In his 2001 essay on Enforcing the GNU GPL, Eben Moglen (then General Counsel of the Free Software Foundation) made it clear that even though the idea of free software is unusual in the world of proprietary intellectual property rights, "as a copyright license the GPL is absolute solid." Contract law is as important to open source as copyright law. The Federal Circuit Court of Appeals used contract law to reach its ruling in the recent Jacobsen v. Katzer case. Finally, the increased litigation surrounding the GPL (such as the Busybox line of cases and the FSF v. Cisco case) are as important a reason as any to make sure you know what the law says about open source.

2. Know the GPL. The basic concepts of copyleft and the goal of the GPL seem easy enough to understand - if you modify GPL-licensed code, you must distribute your modifications in source code. While this is generally true, the details of the GPL are critically important to determining how to comply with the license. The Software Freedom Law Center's Practical Guide to GPL Compliance provides a list of details that could be the subject of claimed violations. Truly understanding the GPL can be an impossible task when we consider the flexibility and ambiguity intentionally built into the GPL. Reading and understanding the SFLC's Practical Guide, FSF's FAQs on the GPL and other resources is important in interpreting the GPL.

3. Understand the community's priorities. One of the distinguishing elements of open source is the deep involvement of the community. Even if you think you have the "right" answer to a particular open source question under the law or based on a valid interpretation of the GPL, the community might reach an equally valid answer under its own analysis and interpretation. As a result, open source activities cannot be considered in a vacuum.

4. Evaluate where your business goals fit. Don't let irrational exuberance or paralyzing fear over open source rule your decision making. Open source decisions are business decisions like any other within an organization and should be subject to the same types of review and decision making considerations. Open source is a tool for use in achieving business objectives, but is not an objective in itself.

Admittedly, none of this is new ... these tips are considerations businesses evaluate every day. Even so, consider this a friendly reminder that open source is neither magic nor the bogeyman. It is just another tool in your toolbox and should be treated accordingly.

From User to Contributor

noreply@blogger.com (Gary Spiegel) — Thu, 19 Feb 2009 04:12:00 +0000

As open source software becomes more widely used, the flow of contributions back to open source projects become more important. Contributions back to an open source project are not only an indicator of the health of a particular project's community, but they are critical to ensure these projects are able to grow and realize the benefits of community involvement. Matt Asay noted in a recent Open Road Blog posting, a lack of contributions from enterprises "may have serious, negative consequences for the long-term health of the open-source ecosystem."

A recent article by Dan Woods in Forbes explains that this is the result of a gap between the "enlightened self-interest" of individuals who contribute for their own benefit, and institutional collaboration, which is "much lower than expected and hoped for, based on patterns of individual participation." While the Forbes article provides some excellent background on the problem and how we reached this point, I would like to dig a little deeper into the reasons why enterprises don't contribute, and what changes are needed to encourage more contribution.

Enterprises (primarily for-profit corporations, but also government entities and foundations) often have few incentives to contribute to open source projects, and many incentives to not contribute. At a fundamental level, the traditional thinking of enterprises has been that ownership of intellectual property is an important part of preserving corporate assets. Though the open source movement is changing these views, ownership and tight control has also traditionally been seen as crucial to preserving a competitive advantage. In addition, enterprises often suffer from the failings of bureaucratic organizational structures, which make the process of obtaining the multiple layers of necessary approvals for release of intellectual property rights difficult if not impossible. Finally, another basic concern of for-profit enterprises is that any time spent on open source projects is time taken away from core, for-profit activities.

No doubt the above described bias against open source contribution is the product of short-sighted thinking. While we should not expect that enterprises would change their position on openness in a short time frame, we can propose short-term, high-impact fixes that quickly and strongly demonstrate the benefits of open source and encourage more openness. Some specific examples include:

Appeal to employees of enterprises to voice their desire to participate in open source projects, and use resulting the groundswell of employee requests as a way to incent enterprises to develop a well-reasoned participation policy rather than perpetuating ad-hoc or unknown participation.

Create model policies that enterprises can easily adopt to permit employee participation and facilitate enterprise contribution, with an emphasis on the benefits of participation over the traditional focus on ownership and control of IP rights.

Clearly demonstrate cases in which contributions create a win-win situation for enterprises and communities, possibly in a public white paper format.

Begin with the low-hanging fruit: contributions related to internal IT infrastructure components rather than contributions that are perceived to compromise competitive advantage; tackle the issue of contributions related to competitive-advantage at a later time after the benefits of contribution are clear.

Acknowledge that strategic and competitive situations might exist that warrant withholding or delaying making contributions, while emphasizing that it is a rare case when choosing not to contribute is the best course.

Some of these are aspirational, but the underlying themes are important: (1) Every technology company has a massive base of employees who are interested, if not heavily involved, in open source, and these employees can be the agents of change within enterprises. (2) Enterprises need to better understand the economic and other benefits of contribution, and the lessening importance of ownership and control of IP rights. (3) This movement should occur incrementally by starting with the types of projects that are least likely to encounter the traditional organizational resistance.

These changes will happen on their own over time, but we can establish an environment that encourages enterprises to speed progress. At stake is the ability for open source projects to survive and reach the critical mass necessary for all community members to realize significant benefits of the open source movement.

Distance Learning - All I Want is a Law Degree

noreply@blogger.com (Gary Spiegel) — Sat, 31 Jan 2009 19:16:00 +0000

Few industries are as slow to adopt new methods and technologies as the legal profession. Certainly, the stability provided by relying on tried and true technology is valuable in an industry that is largely risk averse, but this bias against new technologies sometimes seems arbitrary. This is why current activity in favor of law degrees through distance learning is encouraging.

Until recently, the American Bar Association's Standards for Approval of Law Schools prohibited accredited law schools from granting credit for correspondence courses except in very narrow circumstances. As an example, see the ABA's old position on distance learning, which included a statement that "a law school shall not grant credit for study by correspondence." The limitation was so severe that law students who needed to take a significant portion of their course work by correspondence were effectively barred from practicing law in the vast majority of states. The new rules permit accredited law schools to count substantial amounts of distance learning credits towards the minimum coursework requirement subject to meaningful oversight by the school, and further subject to additional qualifications described in the Standards. The rule change means that instead of a bias against distance learning, the ABA now recognizes distance learning as a legitimate means of obtaining a law degree when the shortcomings of education without in person interactions are addressed.

Only a handful of states permit graduates of all-correspondence law schools to take the bar exam, which is why I was surprised by the news of a recent court case in Massachusetts (among the states with the strictest bar admission rules). (Note that California is one of the states that permits graduates of non-accredited law schools to take the bar exam, subject to other requirements that do not apply to graduates of accredited law schools. Also, several states already have alternative review processes on an as-requested case-by-case basis even though they don't permit graduates of non-accredited schools to automatically take the bar exam.) The circumstances surrounding the case were covered in a recent edition of the California Bar Journal. A recent graduate of Los Angeles based Concord Law School, the first all-online law school, wanted to practice law in Massachusetts even though he knew the state did not permit graduates of distance learning schools from taking the bar exam. In spite of the rule, the student petitioned the state bar and initiated a court case seeking the right to take the exam. The law school graduate was such an effective advocate in representing himself through the briefs he filed and his oral arguments in the court case that the Massachusetts Supreme Court ruled he could take the exam.

The case indicates a shift in the legal profession's bias against distance learning to an acceptance that, under the right circumstances, distance learning can produce strong candidates for attorneys. In practical effect, while the case does not mean that distance learning will automatically be accepted as a substitute for traditional law school attendance, it does mean that more states will likely add alternative review criteria for distance learning candidates when determining whether they should be permitted to take the bar exam.

The trend towards distance learning in legal education is part of a larger trend in support of distance learning for virtually all professions. Among the primary objections to distance learning is the lack of personal interaction and the environment of school and students is seen as critical to making good lawyers. This type of criticism is not typically cited as a weakness of distance learning in other professions. It's true that many attorneys will go into areas of the profession that require excellent client interaction skills, but these types of skills are not necessarily learned in the classroom environment. In fact, one could argue that the distance learning model more closely matches the way most attorneys perform their jobs on a day-to-day basis. Consider my experience as in-house counsel at MySQL, where over 90% of the company's employees worked outside the Silicon Valley office where I worked. The bulk of my client interactions were more often through e-mail, telephone and occasional travel rather than direct personal interaction.

Distance learning also serves another important purpose. It allows those with valuable real-life experience in non-legal professions and endeavors to pursue a legal career. Take the case of a lieutenant colonol in the US Army who is taking law school courses while deployed in Afghanistan, which was described in a recent edition of the California Bar Journal. These types of students typically have day jobs and families and would not be able to pursue a law degree were it not for distance learning, yet the breadth and depth of their experiences is exactly what will allow them to make immediate valuable contributions to the legal profession ... certainly more quickly than I could have as a law graduate who attended law school immediately after graduating from college.

No doubt, the ability to have quality personal interaction skills is critical to success in virtually all professions, but these skills can be learned outside the classroom environment and they are exercised in different ways by each individual. As a result, it does not seem fair that distance learning law students should be at a significant disadvantage. This is one case where it appears that the legal profession is taking the right steps to move into the 21st century.

No Preliminary Injunction in Jacobsen Case

noreply@blogger.com (Gary Spiegel) — Wed, 14 Jan 2009 19:42:00 +0000

Those who follow the Jacobsen v. Katzer case know that it likely will have a significant on how US courts view open source licenses and what legal remedies are available when they are violated. The latest twist in the case, as reported on the Madisonian blog, is the decision of the US District Court for the Northern District of California to deny Jacobsen's request for a preliminary injunction. On its face, this decision might seem like a setback in the ability of open source licensors to ensure the terms and principles of the open source licenses are enforcable. However, my view is that the facts of the Jacobsen case are unique enough that this ruling will not significantly interfere with the efforts of other open source licensors to obtain injunctions.

For an excellent summary of the history of the Jacobsen case, including all the legal developments up to and including the Federal Circuit's ruling in August, please see Larry Rosen's excellent article "Bad Facts Make Good Law: The Jacobsen Case and Open Source". The particular fact of importance here is that Jacobsen requested a preliminary injunction based on Katzer's failure to comply with the terms of the Artistic License requiring the licensee to "duplicate all of the original copyright notices and associated disclaimers". Compare this to the Free Software Foundation's claims against Cisco, which include allegations that Cisco failed to comply with the GPL and LGPL obligations to distribute source code to modifications made by a licensee.

This distinction important because the types of harm likely to result from failure to distrbute source code are easier to identify and articulate than the types of harm from failure to reproduce copyright notices. Under the 2008 US Supreme Court opinion in Winter v. Natural Resources Defense Council, the Court elaborated on the well-accepted requirements for granting a preliminary injunction with a particular emphasis on the point that plaintiffs must show more than a mere possibility of harm, but must actually back up the claims of harm with meaningful evidence. Here is criteria cited by the Court for all US courts to use in deciding whether a preliminary injunction request should be granted:

"A plaintiff seeking a preliminary injunction must establish (1) that he is likely to succeed on the merits, (2) that he is likely to suffer irreparable harm in the absence of preliminary relief, (3) that the balance of equities tips in his favor, and (4) that an injunction is in the public interest." (I added the parenthetical numbers for easier identification in this blog post. The Court cites multiple cases on this point going back to 1982 including another 2008 opinion.)

Elements (2) and (4) are the most important for our purposes. With respect to element (2), meaningful harm from a failure to maintain proper copyright notices in publicly available software seems difficult to prove, and proving that the harm is irreparable is even more difficult. At worst, a recipient of the licensed software would receive the proper copyright notice after the software is distributed, but this would not result in any change in use or non-use of the software. By contrast, a failure to distribute source code could change the way a recipient uses the software, which is central to the purpose of the open source license.

Element (4) is particularly interesting as applied to open source software which, by its very nature, is intended to benefit the public. The public does not necessarily benefit from knowing whether a particular copyright notice is accurate, but the public cannot take full advantage of the software made available under an open source license unless it receives the actual source code.

Setting aside variations in application of the law across jurisdictions, a plaintiff is a more likely to be able to present evidence adequate to support a preliminary injunction when a case revolves around availability of source code under an open source license as compared to a claim of failure to adequately comply with copyright notice requirements. In my opinion, cases like the FSF's claims against Cisco are the types of cases we are most likely to see in enforcement of open source license terms. As a result, plaintiffs should not let the Jacobsen case discourage them from requesting preliminary injuctions, particularly when the plaintiff's claims are based on failure to distribute source code.