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.