How risky is open source?

Often overstated, intellectual property threats apply to both proprietary and open source code

Even as its adoption in the enterprise has exploded, open source software remains dogged by questions regarding its legal status. Most recently, Microsoft has claimed that open source violates no fewer than 235 software patents.

Such pronouncements have contributed to an atmosphere of presumed risk regarding open source, and debate over the terms and enforceability of open source licenses and the role of patents in software development has only added fuel to the fire.

"We have heard repeatedly from customers that IP [intellectual property] assurance is a major factor in a company's decision to purchase technology," says Susan Hauser, Microsoft's general manager of strategic partnerships and licensing. "Unfortunately, we live in a world where disputes over intellectual property can result in a lawsuit."

This may indeed be true, but it is true for any software deployment, not just open source ones. Today, commercial open source is a mature industry, and leading vendors balk at the suggestion that their products are inherently riskier than proprietary equivalents.

"We've never had an actual reporting of an IP infringement issue," says Zack Urlocker, executive vice president of products at open source database vendor MySQL, adding that very few MySQL customers even broach the topic in sales negotiations. "It's not zero, and for the people where it does come up, it is important. But the vast majority of deals we close, the issue just doesn't come up."

Certainly, proprietary software vendors such as Microsoft have a vested interest in playing up the risk associated with open source. After all, open source software has become one of the more important resources for IT professionals, threatening proprietary vendors’ market share. But although copyrights, trademarks, and patents do merit consideration, these issues shouldn’t be overstated. Rather, an accurate understanding of the relationship between open source code and intellectual property can help IT practitioners become better advocates for open source within their organizations.

Who owns the code?
The idea that open source code could infringe on intellectual property rose to prominence in 2003 when The SCO Group  asserted that the Linux kernel unlawfully incorporated SCO-copyrighted code. Indeed, the majority of IP issues surrounding open source involve copyrights, as it is copyright law that gives open source licenses their teeth.

Because the open source model avows open, collaborative development, open source projects are, for the most part, the work of numerous authors. As such, many commercial open source vendors do not in fact “own” the products they sell. Instead, they are merely distributing the software under a license extended to them by the original creators of the underlying code.

Collaborative development and distribution is considered one of the great strengths of open source, but it can also lead to problems. In rare cases, an individual contributor to a project might re-release portions of code under an incompatible license, or even contribute code that infringes on another’s copyright. If portions of code must be removed, the business value the product delivers to the customer could be diminished.

To minimize this risk, some open source projects such as MySQL require all contributors to assign copyright of their code to a central organization. The industry, however, is divided as to whether such a policy really guarantees customers greater protection.

But what’s important to note is that open source projects are by no means alone in incorporating code from multiple parties. According to Greg Jones, associate general counsel for commercial Linux vendor Novell, "The degree to which the third parties own the code in your offering changes, but the concept of having third-party code that may be fundamental to your offering is common to both major proprietary software products and open source software products."

In general, copyright infringement poses very little risk for software end-users. The issue is slightly more complex for customers who wish to incorporate open source code into their own software. Even in these cases, however, guidance and support from an established open source vendor can help mitigate these risks and ensure disputes can be remedied quickly and without financial consequences for the customer.

What's in a name?
Trademarks have minimal influence over IT purchasing decisions, but they do at times play a role. A trademark acts as a seal of authenticity, assuring customers that a product is backed by the full faith and reputation of a specific vendor. ("Linux" is itself a trademark owned by Linus Torvalds.) But because users of open source software are generally entitled to create derivative works based on the original code, occasionally a derivative "fork" of an open source project can appear that is not entitled to use the same trademarks as the original.

Loss of a trademark does not necessarily translate to loss of business value to the customer. For example, when the Debian Project altered its distribution of the Firefox Web browser to comply with Debian policies -- including minor source code changes and the removal of some artwork that could not be distributed under Free Software license terms -- the Mozilla Foundation refused to allow Debian continued use of its Firefox trademarks. As a result, the Debian version of the browser is called "Iceweasel," despite being functionally almost identical to Firefox.

Occasionally, a derivative project will offer greater value than the trademarked original. The windowing system, which began as a fork of the trademarked XFree86 project, has since become the preferred graphics layer for most Linux distributions. Because of this, customers should be doubly sure to evaluate open source projects for features, community, and commercial support, rather than relying on trademark branding alone.

The patent issue
At present, software patents appear to pose the greatest risk for adopters of open source software, at least in the United States. Attempts to introduce software patents into law in the European Union have been defeated, due in no small part to the efforts of open source vendors and activists. But patents are routinely awarded to U.S. software developers, often for seemingly trivial algorithms.

A study conducted by Open Source Risk Management in 2004 suggested that the Linux kernel might violate some 283 registered patents. Similarly, of the 235 patent infringements cited by Microsoft, 42 were attributed to the Linux kernel. So far, none of these patents has been litigated. But the field of software patents is so broad that Free Software advocate Bruce Perens claims that there is no software that does not violate some patent, somewhere.

Certainly, the potential risk to customers, should key software technologies in the products they invest in later be ruled to be infringing, is significant. For example, recent patent claims brought by Verizon against Vonage for its VoIP implementation could limit Vonage's ability to acquire new customers, or even to continue to operate its service. What’s important to note, however, is that Vonage's service is based on proprietary technologies, which demonstrates that there is nothing inherent in proprietary software licensing that makes proprietary products less vulnerable to patent lawsuits than open source ones.

"A particular open source license, such as the GPL, could potentially constrain the discussions to resolve a patent dispute with a patent owner," says Novell's Jones. But otherwise, he says, the risks involved with deploying either type of software are essentially the same.

The real risks
How likely is it that software patent holders will bring suit against open source customers for patent infringement? The actual risk is impossible to measure, but is probably minimal. For one thing, software patents are too pervasive. The result is a kind of patent standoff, complete with its own "mutually assured destruction" deterrent. "If we enforced all the software patents, the software industry would grind to a halt entirely," says Perens.

The recent compact between Microsoft and Novell included covenants in which each company agreed not to assert its patents against the other's customers. But despite these public commitments, it seems unlikely that either company would have pursued that course of action to begin with.

"I don't think Novell is really in the business of asserting patents against anyone," Novell’s Jones says. "We're a software company; we're a technology company. We value our customers, and so that's not something that we really even think of."

Even Microsoft is hesitant to suggest that it has any plans to sue customer companies. "If we wanted to go down that path we could have done it years ago," Microsoft’s Hauser says. "Intellectual property is the basis for collaboration between organizations, as well as a means of enforcement for rights holders. We prefer to focus on the opportunity to collaborate with others and will continue to pursue new models that address changes in the IP landscape."

MySQL's Urlocker, however, sees Microsoft's characterization of its pact with Novell as a smoke screen, designed to comfort customers with one hand while raising the specter of uncertainty around open source with the other. Furthermore, he believes the strategy isn't working. "My view is that Microsoft is trying to be divisive in the open source world, and they've been called on it," he says.

Be assured
The decision to deploy open source software is certainly complex, but then, so is any software purchasing decision. What's more, no business strategy is ever completely devoid of risk. The important point is that deploying an open source solution is not inherently any riskier than deploying a proprietary one.

Larger organizations tend to be more risk-averse, but any company will want additional assurances around key business processes. For this reason, it's advisable to engage a reputable open source vendor before deploying open source for mission-critical systems. The criteria for choosing the right vendor are essentially the same as those used to evaluate proprietary software vendors.

Commercial support contracts for open source software usually incorporate some form of indemnification clause, which can provide additional protection for customers against potential IP infringement claims. Again, however, such clauses are standard practice for proprietary software licenses as well. The fact that open source vendors offer indemnification should not be construed as evidence that open source is more vulnerable to IP disputes than proprietary software.

Business alliances, such as the one between Microsoft and Novell, may claim to offer customers even greater protection, but the broader industry remains deeply divided as to the wisdom of such deals. In the absence of actual litigation, their value to customers is difficult to ascertain.

Companies that plan to modify open source software or embed it into their own products are usually unique cases. They should consult both their vendors and their own counsel to ensure that their use of the code does not violate the terms of its license or any trademarks.

More typical customers, however -- those that fall into the "end-user" category -- have little to fear. Now that the business models around commercial open source have matured, leading open source vendors are able to offer customers many of the same assurances as established proprietary software companies. As a result, given proper understanding of the concerns and potential risks of their decisions, enterprise IT professionals should be able to purchase and deploy open source software with confidence.

Copyright © 2007 IDG Communications, Inc.

How to choose a low-code development platform