The Obligatory End of Year Blog Post

Virtually all media elements engage in the age-old ritual of summarizing the year that was, and looking ahead to the year that will be. Though the number of blogs dedicated to open source, or even those that mention open source on a frequent basis, is extremely small in the blogging universe, my open source compatriots are doing the same ... look at Matt Asay's The Open Road, Zack Urlocker's Open Sources, and Dana Blankenhorn's Linux and Open Source, to name a few. Each of these writers have provided valuable insight into the important open source events of 2008 and areas of focus for 2009 and I encourage you to read their posts.

I do not presume to add much to what these writers have already provided, but I would like to make a few observations. First, I see 2008 as a great success for the open source movement both on an industry-wide basis, and from my personal perspective. The industry as a whole has gained acceptance to the point that it is viewed as an important consideration in the business strategy of all software companies. On a personal level, not only was I privileged to be part of MySQL at the time of Sun's acquisition, but I also started this blog and made more than twenty postings.

Second, I believe 2009 has a strong chance of being the year that open source achieves critical mass not only of mind share, but of economic sustainability. While it's true that several open source companies are making in the tens of millions of dollars in revenues, the economic pressures that hit hardest at the end of 2008 could result in significant gains in revenue opportunities for these companies in the coming year. The economic pressures might be so severe that all IT spending is burdened throughout 2009, but the important point is that in the near future, the cost-conscious thinking arising in these times will likely lead to a radical change in the view of what constitutes value. No doubt, the open source industry will benefit.

The only prediction that can be made with any certainty is that few predictions become reality. In any case, I wish everyone all the best in 2009!

Making Money with Open Source

The question of whether a business can make money with open source software has most often been answered with an uninformed "no," at least until recently. As open source becomes mainstream and an integral part of the software industry, the common answer to this question is becoming, "yes, but I'm not exactly sure how." This was the topic that Joyce Chow (Apple Inc.) and I addressed in our presentation on Open Source Business Models at the Practicing Law Institutes seminar on Open Source Software in San Francisco earlier this month. Here is a brief summary of the highlights of our presentation.

To start, calling open source a "business model" is not accepted by everyone. Open source is clearly a development and license model, but it does not directly derive revenue. It is best viewed as a tool or strategy that can be used to generate revenue, much like any other business strategy. For the sake of simplicity, this post will treat use of open source in any meaningful way as a strategy that is an open source business model.

Open source business models are best considered as a spectrum of strategies using open source, from a 100% open source software model, to a pure proprietary model (though some might argue that "proprietary" is not the opposite of "open source" ... we will treat it here as the other end of the spectrum because it indicates that revenue is generated with no reliance on open source software). Along the spectrum are various combinations of development, licensing, services and other strategies with different triggers for generating revenue. Some of the most well know, starting from pure open source and moving to pure proprietary, are:

• 100% Pure Open Source - This is not a business model in the sense that entities in this category are typically non-profit entities that collect donations for the purpose of furthering the goals of their chosen open source project rather than profit-seeking. Entities like the Apache Foundation and Free Software Foundation fall into this category.
  

• Open Source as a Lure - Companies like Google and Sun Microsystems (my employer) employ this strategy. Google hosts its own open source code repository and open source applications (such as Android) optimized to its search results framework to generate higher web traffic and resulting ad revenue from developers and application users. Sun optimizes its hardware-dependent open source applications (such as Open Storage, xVM Ops Center, and MySQL database software) so they work extremely well on Sun's high-performance servers. In both cases, revenue is not derived from the open source software directly, but rather from the increased sales of related activities and materials.

• Aggregation and Services - These are really two separate models, but aggregation is not a viable business opportunity on its own and the two models are well matched. In consideration of seemingly infinite amount the open source code available on sites like Sourceforge or Launchpad, pulling related code together into a fully functioning application is a real value. Red Hat's ability to compose Linux from multiple sources with many copyright holders into an enterprise-friendly, reliable operating system is a perfect example. Providing services (including training, support, maintenance and professional consulting) is a very compelling revenue opportunity. Services are a natural addition to aggregation because of the expertise and knowledge gained in the process of aggregating code and ensuring it works properly. Red Hat also enhances its offering by providing a full spectrum of services to customers.

• Embedded Use - Open source software licensed as embedded components is another viable business model, but the revenue generating potential lies in the use of a dual-license model rather than the value of the open source software itself. An embedded component licensed under a permissive open source license (e.g., BSD, MIT, Apache, etc.) will not generate revenue because users have no incentive to pay for the freely available software with broad license rights. By contrast, an embedded component licensed under a restrictive or viral license (e.g., GPL) forces a potential OEM or system integrator to purchase a commercial license to the same software. Of course, this requires full ownership (or at least broad license rights) of all rights in the software. The MySQL database is an example of this model.

• Tiered Product - Tiered open source software offerings include two basic types of models. First, an open source offering could be an entry level version of a product, much like the evaluation or "light" version of a proprietary product, with a more fully-featured version available for a fee. However, the open source vendor has an advantage over the typical proprietary evaluation product because the source code is freely available for modification and customization. Funambol's open source and carrier grade editions illustrate this type of tiered product well. Second, an open source offering could be fully featured with no separate enterprise version of the product, and the open source vendor can compel purchase of a commercial license by offering additional tools or add-ons that make the open source software more valuable either by making it easier to use or enhancing its efficiency. In both cases, we come closer to a pure proprietary model in that revenue is generated by the value of the software itself either alone or in conjunction with other software or services.

• Incidental Open Source - Many of the most useful and reliable software tools, components and subroutines are available under open source licenses. As a result, virtually all software developed and distributed today contains open source software to save time and resources. However, the mere inclusion of open source components in a software product does not mean that a software vendor is engaged in the open source business. As a result, the incidental use of open source should not be seen as a means of generating revenue through the use of open source.

• Pure Proprietary - The name says it all. Distribution of software containing no open source components, and with no connection to other open source software is in no way an open source business model. This model was common 10 - 15 years ago with most software vendors such as Microsoft, Oracle and others, though all of these vendors not use open source materials at least on an incidental basis and are actively participating in other open source business models.

This is not an exhaustive list by any means. Each business entity must consider its goals, strengths, and the multitude of variables of each development, license, go-to-market element and revenue trigger for each open source strategy to ensure it finds the best point along the spectrum for it's unique needs. Moreover, these business models should be combined to achieve maximum effectiveness.

Open Source Legislation and Budgeting

California's fiscal health is in a downward spiral with no end apparently in sight. But when that end comes, the crash will be a doozy. After enduring California's longest budget stalemate in history, a time period spanning July to September 2008, the legislature and governor agreed upon a budget that was almost immediately torpedoed by the nation's economic crisis.

Now California legislators are arguing virtually around the clock from their entrenched positions (Democrats primarily advocating tax increases, with Republicans primarily advocating spending cuts) to find a way to plug a budget gap likely exceeding $40 billion by next year. The current proposal would impact Californians with massive additions to and increases in taxes, surcharges and fees including a 2.5% income tax surcharge, an additional $0.10 (possibly more) per gallon fee on gas purchases, and numerous other increases. It would also include dramatic cuts and work stoppages in infrastructure projects.

The budget stalemate not only illustrates the disconnected between political parties, but the disconnect between the politicians and their constituents. The citizens of California deserve to have a stronger voice over their politicians and the policies that impact them directly. You are surely asking, "what does this have to do with open source?" Well, nothing directly, but the ideals of open source (as identified by the Open Source Initiative and the classic text "The Cathedral and the Bazaar", as well as concepts drawn from the book "Wikinomics") provide an excellent starting point for changing the budget and legislative processes to better serve the state. Consider these advantages found in the open source model:

• More brain power means more diversity of views and better ability to solve problems
  

• Speedy fixes to problems and resolution of issues
  

• Lower overhead by outsourcing difficult issues to those with expertise and interest
  

• Creating a closer tie between companies (politicians/government) and customers (constituents)
  

• Better responsiveness to customer feedback and needs
  

• Facilitating a sense of inclusion and legitimacy of decisions and actions

The idea that government activities would benefit from more transparency to and direct involvement from involvement of constituents is not new. An organization known as MorePerfect.org has had its website running since 2006 offering a platform for anyone to voice there opinion, and draft and modify legislation on any issue (including revising the US Constitution). This is but one example, but imagine how effective such an idea could be if both the legislature and constituents committed to it.

Maybe the politicians could set aside their entrenched positions by listening to the priorities and needs of citizens, which would not only lead to a budget aligned with the state's needs but would also help win the trust of citizens.

Jump On the Bandwagon

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

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

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

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

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

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

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

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

For All the Law Students Interested In Open Source

I recently met several law students who are interested in intellectual property law and the open source business. I was impressed with their awareness of the impact of open source on the technology industry, and happy to see how interested they were in learning more. In response to their questions on how to develop the skills needed to focus on open source, I have advised students that no pre-defined path of classes or experience leads to expertise, but there are several activities to emphasize as they progress in their journey towards finding their niche in the legal community.

A. First and foremost, all students interested in open source must have a solid foundation in intellectual property law. Open source business models arose as novel ways to utilize traditional proprietary rights. For example, the GNU General Public License ("GPL"), the most well known and widely used open source license, relies on a liberal grant of the rights held exclusively by a copyright owner to ensure that software users have a maximum amount of freedom to use open source software. A thorough understanding of copyright law is critical to understanding the impact of "copyleft" licensing.

B. Of equal importance to students is understanding contract law and having strong contract drafting and interpretation skills. Using the GPL as an example again, the copyleft effect only works because the license is drafted in such a way that passing along the rights granted under the license to subsequent licensees is a condition of the license grant. (See Mark Radcliffe's commentary on the Jacobsen v. Katzer case, which hinged on the "conditional license" issue.) In other words, the contract is written to enforce the viral nature of copyleft licensing. The conditional nature of most open source licenses means that contract interpretation skills are critical. A legal interpretation of a particular open source license must take into account the contractual conditions and obligations along with the broader context in which the licensed components are used.

C. As in any endeavor requiring legal analysis, a lawyer must always look beyond the relatively narrow context of "the law" to recognize and understand the bigger picture and real world consequences of legal conclusions. This is particularly true with open source businesses because the goal of businesses to generate revenue contradicts the act of giving something away for free does and open source technology must be used to generate revenue in other ways. In addition, open source businesses are heavily tied into their corresponding development communities and open source solution partner networks. The choice of an open source license, or a division of features between open and closed source versions of a product, and other such decisions open source companies must make have significant impacts on the viability of an open source business.

D. A more practical point for law students is to look for internships and clerkship opportunities with companies and law firms known for open source expertise. My employer, Sun Microsystems, for example, is a leader in the open source community and typically offers internships to several law students each year. These students get to see the details behind the hard decisions that business units make in guiding their open source activities. They also get to research details of the law as applied to open source issues, which gives them a level of expertise in a particular subject matter that can follow them the rest of their career.

E. Attend conferences and talks about open source law, as well as trade shows featuring open source businesses. The open source business has become big enough that a multitude of conferences and trade shows are presented virtually every week across the country and around the world. Events like OSCON and the OSBC are fixtures in the open source world, as are conferences like the MySQL User Conference and SugarCon for SugarCRM, to name just a few. Look at the upcoming Continuing Legal Education calendars to see how many seminars are devoted to open source or spend at least an hour on open source. (Shameless plug: I will be presenting a talk on open source business models with Joyce Chow from Apple Inc. at a December 10 PLI conference in San Francisco.) These are all great opportunities to learn how open source works in the real world, and students sometimes get free or reduced fee admission.

F. As a final note of encouragement, do not get discouraged by a lack of technical background (such as engineering or computer science) because this does not need to be a barrier to understanding open source technology and businesses. My college degree was in government and economics with no formal training on how software is written or even the difference between source and object code. While it is true that many law students start with a technical background, it is common for a lawyer in the tech industry to not have a deep technical background. (See the blog of one of my colleagues at Sun who did a survey of college majors of those within the Sun legal group... the results are very interesting.)

Innovation in Open Source Licensing

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

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

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

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

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

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

Olympic Open Source Lessons

The Beijing Olympics are almost half over and have had plenty of excitement ... gold medals, world records, and races decided by hundredths of a second. This makes my wife really mad! She doesn't hold a grudge against Michael Phelps, beach volleyball or the Chinese tandem diving team. NBC's coverage is what makes her blood boil. The open source world could teach NBC a valuable lesson.

NBC clearly withholds the most prestigious races and events for the late night hours. Anyone who goes to bed at a reasonable hour (meaning before 10:30 pm), like my wife, will miss much of the day's most exciting competition. I don't have that problem because I usually stay up a little later to check e-mails anyway, only to find myself drawn into the exciting events NBC saves for us night owls who don't go to bed until 11 pm or midnight. While I may be suffering from a lack of sleep, at least I have the satisfaction of seeing the best parts of the Olympics. Even so, I admit that it would be nice to reclaim an extra hour of sleep while still enjoying the best of the Olympics in primetime.

Not only is my wife becoming more frustrated each day as she hears news of the exiting events she missed the night before, but this is becoming a common theme for many who tune into the Olympics with the expectation of seeing something big. Why must we be subjected to hours of "competitive showering" in prime time only to see "nothing more than a bunch of highlight reels" late at night?

What would happen if a software company chose to tightly control the release of its most valuable features until it decided the time was right ... and it justified this action on the assumption that this is the way to maximize the extraction of commercial value from the software? Well, this describes the business model of the vast majority of the software industry and we know the result. Open source software has emerged to serve the needs of customers by giving them access to fully featured, customizable software for free.

We might as well refer to NBC as the Microsoft of broadcasting (maybe this explains MSNBC?). NBC has another option ... the open source option. Not only is it broadcasting the Olympics on television, but it also makes countless hours available through the Internet. As with television, NBC has chosen to tightly control its Internet content based on its television schedule. Research indicates that access to real time Olympic video would have little negative impact, if any. In fact, even NBC management recognizes that providing broader access to Olympic video through a variety of media would likely enhance the size of the audience as a whole.

NBC's approach to disseminating Olympic video illustrates that open source principles hold inherent benefits that transcend the software business. Opening up access to video through television and Internet would not only benefit NBC, its advertisers and its viewers alike, but it would also make my wife happy which is reason enough to do it (in my opinion).

Who Has a Shaky Foundation?

The commercial software licensing business as we now know it started with the move from mainframe computers to affordable personal computers and has been around for at least 20 years. Similarly, open source licensing as we now know it arguably started with release of version 2 of the GPL just a few years later.

Even though these software license and distribution models have been in effect for roughly the same period of time, "conventional wisdom" (the Freakonomics definition) appears to be that the proprietary software license model is built on a solid legal foundation, while the open source model is filled with legal uncertainty. Recent developments on the legal front for both business models remind us that these stereotypes often do not hold true.

The open source community has had a recent string of recent "wins" giving it more credibility from a legal perspective. The continual flow of BusyBox cases, including the recent initiation of an action against Extreme Networks and settlement with Super Micro Computers, Inc., has shown that the GPL can be readily enforced, particularly in cases where GPL-covered code can easily be tracked and where the nature of the software requires the type of linking or integration that would create a derivative work or modification.

In addition, Red Had recently settled a patent dispute and showed that it is possible to successfully negotiate a patent license that protects the open source community as a whole. Both Red Hat's explanation of its strategy, and Mark Radcliffe's analysis of the license terms are fascinating reading for anyone who wants to see the gory legal details that go into making open source work for everyone.

By contrast, a recent case in U.S. Federal District Court in Seattle illustrates that the very foundation of the proprietary license model is still subject to uncertainty. In Vernor v. Autodesk, Autodesk found itself on the losing end of the court's interpretation of the "first sale doctrine," a principle in copyright law that permits purchasers of a copy of a copyrighted to distribute that copy without obtaining additional permission. Another implication of the first sale doctrine is that copyright holders cannot use license agreements to control distribution of copies of their work in perpetuity.

While this Autodesk case was decided in a district court, at least two U.S. Courts of Appeals have made similar rulings, and some others have yet to address the issue directly. The difference in opinion between the Circuit Courts has not been addressed by the U.S. Supreme Court. As another indication of the momentum behind this view, William Patry, Senior Copyright Counsel for Google and author of one of a highly respected legal treatise on copyright law, stated in response to the Vernor decision that to permit a license to circumvent the first sale doctrine "is an absurd position to me, and in such cases, federal courts should take a common sense view of the transaction in order to avoid abolition of the first sale doctrine".

The first sale doctrine is consistent with some of the basic principles of open source, but it does not provide the same level of freedom that copyleft and other open source licenses provide. As a result, the Vernor decision isn't likely to impact the open source model directly.

Instead, the important message here is that no matter how exciting the successes they enjoy or how dire the challenges they face, both the open source and proprietary software license business models as we know them today have solid legal foundations and will certainly survive.

Silicon Valley Cocktail Party Small Talk

Whether you scan the newspaper headlines once in a while as you pass the newsstand, or multitask with NPR in your headphones, New York Times RSS feeds to your laptop and CNN Headline News ported to your mobile phone via Slingbox, it's important to have a few interesting tidbits of recent information readily at hand if you happen to attend a cocktail party or other social gathering.

While the subject of open source software might not be the key to climbing the social ladder in many places, it would be a clear hit in Silicon Valley Extended (e.g., beyond the San Francisco Bay Area to include the Raleigh-Durham Research Triangle, Bangalore, India and other places that live and breath technology). With that in mind, here is a list of 5 important issues in open source that will likely continue to heat up over the coming months (in no particular order) and that are worthy of discussion with your tech colleagues:

1. Security of Open Source Software. When Fortify Software released its report on security in the open source software industry, it created an immediate reaction. Fortify noted that typical community open source development models and projects often do not incorporate the types of security safeguards that enterprises like to see. It was a critique of process more than security features of the software itself. While the underlying message was sound, it created an immediate reaction from (a) the open source development community, which took issue with the implication that open source software is not secure (in fact, a pillar of open source adoption has always been that it is more secure precisely because it is open and subject to constant testing), and (b) anyone else who wanted to spread fear, uncertainty and doubt ("FUD") about the open source industry. Commentators like Dana Blankenhorn recognized the overreaction by the media and others in their blog posts. Bottom line: While open source software processes are not always at the level of security typically employed by enterprises, the software itself is largely secure, and likely more secure than its proprietary counterparts.

2. Cloud Computing. Cloud computing is the availability and use of computing resources over a network when the actual machines used for processing tasks are not specifically identified ahead of time and are reassigned frequently. One fear for users of cloud computing (like Amazon's EC2 offering) is that the cloud will break and the one vendor that controls it will not be able to fix it. Even worse, user data will be stuck in the cloud. Classic vendor lock-in. As noted by the 451 Group, many believe that an open source cloud platform would reduce these risks and a number of alternatives to Amazon and the other big name cloud vendors. Bottom line: As in all other segments of the software industry, cloud computing vendors need to be aware of the disruptive capabilities of open source.

3. Mobile Infrastructure. Apple has been getting virutally all the buzz in the mobile market because of its release of iPhone 3G. While the closed nature of the iPhone's architecture has drawn heated criticism from the Free Software Foundation, it has gotten at least a temporary pass from the type of widespread critical commentary you might expect from others in the open source community. In parallel, the open source community is looking forward to LiMo and Android as the first true open source alternatives. Out of nowhere, Nokia's recent acquisition of the outstanding stake in the Symbian mobile operating system added even more strength to the mobile open source movement. In addition to the platform, we also have companies like Funambol, which has already brought a level of freedom to the mobile market that was previously unheard of. Bottom line: Open source will see rapid adoption in mobile, and they are just now getting their ducks in a row.

4. Virtualization. The recent emergence of virtualization technology presents a significant challenge to open source licensing. Virtualization enables the creation of software appliances, which combine software components into a finely tuned package. According to rPath, a one of the thought leaders in software appliances, virtualization can be used to combine operating systems, open source software and proprietary software into a single package without violating open source license obligations or subjecting proprietary code to copyleft. While the legal analysis is too new to have been well tested, it is easy to foresee scenarios in which virtualization is used to avoid they types of product interaction that would have been deemed a modification or derivative work of an open source work, and be subject to copyleft. Bottom line: The industry is just now starting to apply deeper levels of creativity in how virtualization is used, and the impact on all types of software license models, including open source, needs to be carefully considered on a case by case basis.

5. Standing to Sue in Open Source. From the open source perspective, one of the biggest limitations on enforcement of copyleft open source licenses is that the entire responsibility of enforcement falls on the copyright holder. If the copyright holder either doesn't want to pursue a license violation, or doesn't have the resources to do so, no one else can undertake that responsibility on behalf of the community. An enforcement mechanism that enables community members who lose access to source code that otherwise would have been available would solve this problem, but this would likely require a change to the copyright statutes themselves. Another option would be for the open source community to use its collective influence to urge copyright holders to either enforce their rights, or assign them for others to enforce. Bottom line: Nothing is likely to change any time soon on the legislative front, but a community body might be able to find alternative means of enforcement.

BONUS

6. Software/Platform as a Service. GPLv2 and v3 are extremely effective in applying copyleft to software distributed in the standard ways (through online download or on physical media). These licenses, however, have no effect on software used solely over a network connection without any distribution. The Affero GPL was created specifically to address SaaS and PaaS models by applying copyleft to software accessed over a network. The Affero GPL has seen modest adoption (125 projects, according to Palamida ), and Funambol CEO, Fabrizio Capobianco has been a fantastic advocate for the license including by adopting it for Funambol open source projects. Bottom line: With the growth of SaaS/PaaS, coupled with the growth of open source, more service providers will take a serious look at AGPL, which will likely increase adoption.

Please share your thoughts on the key trends in the technology industry that will impact the open source world.

GPL Enforcement, Frogs & Funny Hats

The GPL has become the most popular of open source licenses in large part because of its "copyleft" status. Not only does it virally attach to software code, but it automatically terminates if its source code distribution obligations are not honored. The severe consequences of breach, along with community pressure for compliance are strong deterrents to violations that would require enforcement measures. Even so, every open source company using GPL will be faced with GPL violations and must carefully consider both when enforcement is appropriate and what factors should be weighed as part of that decision.

To those open source companies that assume GPL enforcement is always the quickest, best strategy, I quote the great open source guru Homer J. Simpson: "you're living in a world of make-believe! With flowers and bells and leprechauns and magic frogs with funny little hats." Yes, it's true that enforcement serves a critical function. Not only does it prevent abuse of open source code on a case by case basis, but it also upholds the legitimacy of the GPL as a license vehicle and meets the community's expectations of its fellow members.

On the other hand, enforcement is not a panacea. The community might view inconsistent enforcement as arbitrary and self-serving, or it might have different views on what a company's enforcement priorities should be. In addition, enforcement actions might actually slow the adoption of open source in proprietary companies. A great recent example of this type of unintended consequence is the discussion arising from the recent string of settlements related to the Busybox GPL enforcement cases. Though widely criticized by a number of open source commentators, intellectual property attorney Edmund Walsh wrote an article in which he analyzed these cases and concluded that "for-profit companies [have] new reasons to re-evaluate the ways in which they use open source software as well as the extent to which they use it."

Open source companies should also consider strategic non-enforcement as an option, or take a further step and grant limited exceptions to open source licensing (assuming the company controls adequate IP rights). Among the benefits of these approaches is the ability to encourage specific types of partner and end user activities that would have been difficult to otherwise achieve without radically altering a dual license strategy. However, these approaches should be used with caution because they can easily backfire. The community might view this type of manipulation of open source strategy as counter to open source philosophy. It also could lead to end users using the software in unanticipated ways that negate the perceived or realized benefits of the approaches.

The moral of the story is ... as you consider your options with respect to enforcing the inevitable GPL violations that all open source companies face, avoid the frogs with funny little hats!

Speak to the Government in Language it Understands

Last week Matt Asay explored the downside of governments legislating open source use, and the theme was extended by Dana Blankenhorn who pointed out that the migration to open source must be evolutionary rather than something stipulated to occur at a point in time. Matt went further this week by highlighting the EU's recent message to its member countries urging them to use more open source, with the very astute observation that the tactics of advocacy and persuasion are likely to be more effective than legislation. The time is right to explore strategies for accelerated government adoption of open source.

In essence, the debate on how best to accelerate government adoption of open source has boiled down to whether to dictate use through legislation, or persuade governments through the same grass roots persuasion used for years by the open source community. In my opinion, we should not discount the value of the right kind of legislation, which can accentuate the positive aspects of the types of community persuasion that have been so effective. An ideal approach would be to create legislation that encourages the government to make procurement decisions based on criteria indicative of high-quality open source products and projects.

To explain what I mean, think of Section 508. Section 508 is a US federal law requiring government agencies to consider accessibility factors when purchasing IT products. Federal procurement rules implementing the law provide more details on the specific types of factors to be considered. In short, the government is not permitted to purchase software or hardware that does not meet its minimum accessibility standards (such as for use by blind or motion impaired workers or members of the public who access government information) unless choosing a fully accessible product over a less accessible product would create an undue burden.

Applying this idea to open source, we should start by identifying the procurement criteria that are the most advantageous to open source products and projects. Lower cost is clearly a primary factor for enterprises in determining when to convert from proprietary to open source. After a recent tour of several Fortune 100 comanies, Zack Urlocker of Sun/MySQL noted that the current weakness in the economy appears to be enhancing the effectiveness of the "cost savings" sales pitch.

While the same economic benefits will be attractive to governments, the unique nature of government services means that other factors will be at least as important if not moreso. Fortunately, the conventional wisdom is that the open source development model, as compared to the standard proprietary model, results in quicker development times, higher-quality features, features more relevant to end users, better scalability, more customizable products and more secure products (which is particularly important to agencies like the US Department of Defense). This is something that open source companies already do in their data sheets, white papers and savings calculators to convince commercial customers that purchasing open source is a good idea.

In order to make this kind of legislation happen, the open source community would have to muster its resources and undertake a significant lobbying effort. Even if it's not successful in creating new procurement rules or legislation, this type of unified effort would possibly be the best marketing campaign in the history of open source. In any case, an emphasis on the right kind of legislation could accelerate the typical grass roots marketing efforts and sales pitches.

Governments Dive Into Open Source: How Deep is the Pool?

Over the last few years we have seen a steady wave of news stories, blog postings and seminars have been telling us that the government is making a big splash by making open source IT solutions a priority. No doubt the rising tide of open open source will reach government just as it is reaching the rest of the software industry ... as Mark Radcliffe put it, open source is the Borg and resistance is futile! Even so, constituents have felt few drops from the splash that open source software has made, particularly here in Silicon Valley where it might be expected to be more prevalent. Consider this:

• Municipal/City Government - I live in San Jose, California, a city that proclaims itself the “Capital of Silicon Valley”, is home to some of the world’s largest technology companies, and host to an innovative festival combining technology and the arts. These high-tech credentials have not translated into adoption open source. In fact, the city rejected a 2008 proposal to ease budget pressures through the adopting lower cost open source software on the grounds that it would have limited impact and was inconsistent with other strategies.

• County Government - As far as I can tell, Santa Clara County, which includes the City of San Jose, has not adopted or even significantly considered the adoption of open source software on any meaningful scale.

• State Government - California, to its credit, is one of several states that seems to have made the adoption of open source a priority. Not only did the State formally authorize a search for open source replacements to proprietary software but, as Matt Asay has highlighted, the CIO for the California Air Resources Board has encouraged his staff to use open source software in any way possible. Other states have even gone so far as to propose legislation requiring the consideration of open source alternatives in any IT procurement.

• Federal/National Government - The US Federal Government has seen a steady increase the use of open source over the last several years, and this has been a regular topic of discussion by open source commentators such as open source commentators. The Department of Defense in particular has invested a great amount of resources into open source and has made significant efforts to reach out to the open source community.

• Regional/Continental Government - The open source movement has touched even higher levels of government. As the most prominent example, the European Union is probably the single biggest adopter of open source, with a pipeline of open source priorities that will likely keep the EU ahead of the curve for years to come.

These anecdotes are just a sampling of the type of news constantly swirling about government adoption of open source. While open source almost certainly is being utilized in critical government infrastructure and other ways that are not readily discernable to people other than IT administrators, all levels of government can do more to grab the wave of unique value that open source software provides and apply it in ways that better serve its constituents. Some governmental bodies, such as the EU and its member states, seem to have jumped into the deep end of the pool. (Matthew Aslett at the 451 Group recently embarked on an open source tour of Europe that has resulting in intriguing insights on the status of open source in Europe as a whole as well as specific countries including Austria, Switzerland, Romania and Russia.) In the meantime, governmental entities here in Silicon Valley continue to splash in the kiddie pool, or choose not to get wet at all. With some prominent exceptions of specific agencies that are clearly in the "deep end", the federal government and various states are wading in deeper pool waters, but no further than their feet can touch.

In my next post, I'll discuss some thoughts on a framework for government open source adoption that avoids the pitfalls of mandating it through legislation.

Relationships Matter

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

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

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

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

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

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

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

Countdown - Open Source Style

I am a big fan of top 10 lists... particularly humorous ones a la David Letterman. While I can't claim that any of the top 10 list below is humorous, it does paint an interesting picture on the status of open source in the top 10 companies (by market cap) in the Software Application Industry (Technology Sector) of the stock market.

These 10 companies represent over 96% of the market capitalization in the Software Application category. At the end of each entry, I give the company a (purely subjective) grade reflective of its efforts, commitment and contributions to the open source community.

So, here we go...

10. Sybase ($2.7B) - Database Management, Information Management and Business Intelligence Software. Sybase appears to have made at least a minimal effort to embrace open source. It even has an OSI approved license (the Sybase Open Watcom Public License). More important is how many of Sybase's competitors have serious open source credentials ... MySQL/Sun, Pentaho, JasperSoft, GreenPlum. Grade - D.

9. Nuance Communications ($4.1B) - Speech and Imaging Solutions Software. A search for "open source" on the company website results in 0 hits. Enough said. Unfortunately, there are no open source options. Grade - F.

8. Red Hat ($4.2B) - Linux and JBoss Provider. Red Hat, as we all know, is one of the premiere examples of open source software industry success. Enough said. Other Linux providers exist, as do other OS providers, but Red Hat is the go-to open source vendor. Grade - A.

7. BMC Software ($7B) - Enterprise Management Including Application & Database Management. As with Nuance, a search for "open source" on the company website results in 0 hits. However, BMC has a developer network with various, small-scale open source projects. Grade - D.

6. Intuit ($9B) - Personal Finance, Small Business and Tax Software. Intuit does not appear to have any significant involvement in open source and this probably is not the type of software that has attracted a developer community to create open source alternatives. Grade - F.

5. CA ($12.3B) - IT Management Software. To my surprise, this 30+ year old company has embraced open source in a significant way. For example, CA has supported the open source industry's patent pledge for several of its patents. Grade - C.

4. Adobe Systems ($21.6B) - Creative, Knowledge Worker and Enterprise Software Applications. Facing the commoditization of it biggest revenue generating applications (Photoshop and Acrobat), Adobe has taken the initial steps it needs to diversify its business into open source in a significant way. Grade - C+.

3. SAP. ($60.1B) - Business Operations. SAP has dabbled in the open source world, partnering with MySQL on database technology. Overall, however, SAP hasn't made many significant contributions to the open source community. Grade - D.

2. Oracle ($111B). Database, Middleware and Enterprise Management. Oracle might be described as the Jeckyll and Hyde of open source. While it distributes several open source applications (such as Sleepycat and Innobase), it also actively challenges other open source providers (such as with Unbreakable Linux) and would likely acquire competing open source companies to eliminate a business model that threatens its own. This duality makes it hard to settle on a grade. Grade - C-.

... drum roll ...

1. Microsoft ($277B). It's no surprise that Microsoft is in the number one spot (even on Letterman the #1 is always anticlimactic). In spite of making substantial contributions of code as open source, Microsoft is the big bad wolf of open source for good reason... among other things, it has a very proprietary stance on patent licensing for open source projects. Grade - D.

Some other companies that didn't make the list due to technicalities are:

• Google ($178B) - would be the clear number 2 if it were in the "Software Application" category. Google would receive a B for OS Effort (knocked down from A because of its deceptively not open Android platform and other calculating open source strategies).
• Sun Microsystems ($10.2) - would be at number 6 if it were in the "Software Application" category (though its software business is probably valued at closer to $4B, which would drop it a few spots on the list). Sun would definitely receive an A for OS Effort as the largest open source software provider.
• Still other companies like HP and IBM have been long-time contributors to the open source movement, but are not reflected here.

I find it very interesting to note that of these top 10, only 1 got a grade better than C. In addition, one estimate of the total value of the open source industry ($60B) would place the entire industry at only number 3 on the list (though without an objective market cap value, it's hard to draw many conclusions from this).

On the other hand, if we add Sun and Google (two of the top open source contributors) we come closer to a critical mass of open source presence on the list, and lest we forget that numerous open source companies with no market cap at all (because they aren't listed on a stock index) are providing strong, competitive alternatives to the software and solutions provided by the companies on the list.

What can we conclude from all this? First and foremost, we can safely conclude that I am not a mathematician, statistician, or financial analyst, as evidenced by my loose use of numbers and grading to make my point.

More important, even a pessimist would have to say that the presence of a company like Red Hat on the list means open source is making significant inroads into the traditional software industry. The amount of innovation and competition presented by companies not yet public or too small to make the list yet indicates that the trend is strongly pointing towards greater adoption of open source. It might be only a handful of years before all of the top 10 companies on this list receive A's and B's.

Commercial vs. Free: Not a Zero Sum Game

Think back to 1991 and the release of GPLv2 ... the open source software community was abuzz with great anticipation that the goals of the "free software" movement would soon be achieved. Now fast forward to present day ... the open source software business is potentially worth as much as $60 billion, a small Linux provider named RedHat has grown into a successful public company, and an open source database company named MySQL has been purchased by Sun Microsystems for $1 billion. Does this prove the success of the commercial open source movement? Of the failure of the free software movement?

If the recent firestorm in the community over Sun's proposal to sell closed-source add-ons for the open source MySQL database is any example, then the open source community appears to have concluded that the success of one is only at the expense of the other. (In the interest of full disclosure, I am a MySQL/Sun employee, and these opinions are mine alone.) The community would rather punish MySQL, one of the pillars of open source movement, than applaud the prominence it has helped bring to open source through its innovative open source and business strategies.

This "zero-sum" attitude is not only wrong, but also harmful to the open source industry. Instead, the open source industry must accept that both open source purists and commercial opportunists can co-exist in the same environment without forcing an absolute choice between them. Though it appears more open source "rationalists" are reaching this conclusion, the community needs to start acting based on what is good for open source as a whole, not just the purist forms of open source.

The viability of this type of co-existence is well proven in other contexts. Take the example of environmentalism and the "greening" of the business world. Groups like the not-for-profit Sierra Club operate on the same playing field (though at the opposite end) as companies that use the "green" label as an insincere marketing ploy (I won't point any fingers). The business world accommodates this range of diversity allowing groups interested in societal change to organize as not-for-profit entities, which allows them to focus on their chosen area of social good without being subject to income tax. Entities like the Apache Foundation, Linux Foundation and Free Software Foundation play this role in the open source world by focusing on open source for the public good (and get a tax relief too).

At the same time, though commercial entities are primarily motivated by profits, the community pushes them to be "good citizens". We see the pressure the community puts on companies these days to pursue environmentally friendly policies in spite of (or sometimes in support of) their profit motives. Similarly, commercial open source companies perform good citizenship by acting in support of open source ideals, which not only builds community goodwill but also allows them cash in someday.

To make this drive to good citizenship most effective, communities need a way to differentiate commercial entities by evaluating them both their effectiveness and sincerity in pursuing. Many environmental groups act as watchdogs and standard setters for their commercial counterparts. Similarly, the open source community has taken a new focus on improving upon the traditional benchmarks of open source (choice of an OSI approved license and release of copyrighted code) with proposals to include patent and trademarks as well as business and development models in the standard definition of "open source". Another proposal is the creation of an independent body that would objectively grade companies on their "openness". While these are great solutions, they are not likely to reach their potential for effectiveness until we all recognize the importance of co-existence.

Just as we don't hold commercial entities to the same standard of environmental purity as we do the Sierra Club, the open source community must strike the right balance between pursuing its passion and pushing commercial open source companies to act in "acceptable" ways. It must not forget that open source advocates, and good ideas that can further the open source movement, can come from virtually anywhere in the open source spectrum. While it's useful to distinguish between commercial open source companies based on openness, the community must begin acting as if we are all in this together. If we don't learn to co-exists, we risk an irreparable fracture in the movement that we all support.

Trade Secrets: Which Secrets are Worth Keeping?

Trying to understand the impact of intellectual property rights on an open source company can be intellectually challenging. We saw this quite clearly in the complicated discussion of patents in the last post. I think it's the right time to take a break and tackle a subject that is far less controversial and mentally demanding -- trade secrets.

The concept of trade secrets is straightforward... an intellectual property right designed to protect economically valuable information that a company attempts to keep confidential. It can be applied to all types of information from marketing strategies to manufacturing techniques. Trade secrets, like copyrights, trademarks and patents, can provide a valuable means of differentiation, but in different ways. While copyrights, trademarks and patents provide differentiation through unique product features and branding, trade secrets do so by preventing competitors from using a company's business operations to their own advantage.

Open source companies might be tempted to ignore trade secrets on the grounds that the term "secret" is the antithesis of "open," but this would be a mistake. Instead, open source companies should use trade secrets to their advantage as a core element of their business strategy in much the same way as their proprietary counterparts. Proprietary software companies protect virtually all information by treating it as secret unless the company specifically authorized for disclosure. This is consistent with the proprietary license strategies they employ, which withhold intellectual property rights until a customer purchases a license.

This blanket approach will not work for open source companies. Because the company's source code is publicly available and development ideas and techniques are freely discussed within the community, much (if not all) of the company's technical information is not even eligible for trade secret protection. As a result, open source companies must clearly distinguish between technical and business information. Business information worthy of trade secret protection might include the next vertical market to be targeted with a marketing campaign, the unannounced release date of a closed-source add-on to the open source software, or the fact the company expects to close a significant deal by the end of the quarter. As business information, these examples do not directly impact the community, and release could potentially put the company at a disadvantage with respect to its competitors.

This is not to say that all technical information should be open, or that all business information should be closed. Open source companies should use this as a guideline in determining which secrets are worth keeping. Once an open source company makes this determination, it should use non-disclosure agreements aggressively to protect that information.

This is the final of 4 posts in a series aimed at providing practical consideration for open source companies with respect to intellectual property rights. As alluded to in the post introducing this series on intellectual property rights, I will soon tackle other aspect of the open source business that touch on legal issues including relationships with customers, partners and employees, as well as deciding when to shift legal work from outside to inhouse counsel.

Patents: More Than Meets the Open Source Eye

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

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

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

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

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

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

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