Navigating the Legal Risks of Open Source

Monday May 21st 2007 by Jeff Vance
Share:

A Software Freedom Law Center lawyer and other experts talk about what businesses and developers need to know about using open source.

Microsoft is once again tormenting the open-source community. This time it’s not about the quality or price of its software, or source code issues. This time Microsoft has set its sights on Linux and other open-source projects, claiming that 235 Microsoft patents have been violated.

What’s the strategy here? Does Microsoft truly intend to collect royalties from everyone using the software in question, as it has been hinting? Or is this a counterpunch in response to GPL version 3, which itself seeks to counter some of Microsoft’s recent open-source moves? Or is this simply a strategy to boost the Microsoft-Novell relationship? Novell’s Linux Indemnification Program, after all, protects SUSE Enterprise Linux customers from IP challenges just like this.

IBM, Red Hat, and others offer similar indemnification programs, but part of the allure of open source in the enterprise is the ability to gather the applications you need from disparate sources. The vendor indemnification programs protect only the vendors’ distributed and supported projects.

It’s not surprising, then, that third parties have stepped in to offer broader protections.

OSRM Seeks to Fill Open Source Legal Void

Back in 2003, two events happened that got Daniel Egger thinking about the risks associated with open-source software. First, the SCO Group sued IBM, claiming that IBM had contributed SCO-owned portions of the UNIX source code to Linux. A number of other suits ensued, and while many of SCO’s claims have been dismissed, the court cases drag on.

At the same time, Egger was looking for his next technology venture. Egger had previously founded Libertech, a database search company, and with a law degree from Yale, the SCO suits caught his attention.

“I saw pretty quickly that their [SCO’s] case had little merit, but it pointed out a problem. They were wrong about specific facts, but they showed that there is a missing piece in intellectual property protection as it applies to open source,” Egger said.

Not long after that, another instance of open-source litigation came along. Broadcom, which supplied chips for Linksys WLAN routers, admitted it had used open-source code in its firmware. The Free Software Foundation pressured both Broadcom and Cisco, which had acquired Linksys, to open up those routers. Cisco eventually did, in a move that devalued its acquisition and allowed end users to access the code base. Many end users then souped-up the routers to create so-called “super routers, effectively undermining how Cisco could control these devices once distributed.

It’s not entirely fair to lump these two cases together. Most industry experts argue that the SCO cases have little merit, and so far court actions back this up. The Cisco case is more subtle. Linksys didn’t know it had open source at the core of its router, and Cisco certainly didn’t figure it was acquiring an open-source wireless provider. Cisco also didn’t bank on the fact that modifying those routers is considered perfectly appropriate under GPL; that’s part of the deal when you use open source.

This later example prompted Egger to found Open Source Risk Management (OSMR), a company that evaluates organizations’ open source obligations, while also providing indemnification to protect against SCO-style lawsuits.

But How Serious Is the Risk?

There’s really no consensus on the seriousness of the risk. The only consistent answer is: it varies.

“Issues of open source licensing obligations, mixed licenses and the like only come about when software is distributed – that is, when it leaves the walls of the company making use of it,” noted Gordon Haff, an analyst with Illuminata Illuminata.

Another important distinction is what sort of license the open-source project falls under. “Some open source licenses – such as Apache and BSD – impose very few restrictions on how the code covered by these licenses can be used,” Haff said. “It’s really only the copyleft licenses, like the GPL, that are a concern and – again – only if the code is distributed outside the company.”

With those points in mind, the risk for an organization using open-source software for entirely in-house efforts isn’t that large. But what if that in-house software is later distributed or even commercialized? The project developers could be long gone, and it’s possible that the organization would not even know it had an open-source foundation to its project.

This is one of the challenges that OSRM addresses. “When clients have questions about open source, our first step is to mitigate risks,” Egger said. This often means complying with open-source licenses. Even though OSRM offers indemnification, what’s often more important is simply understanding what software is in a project and what licenses it must adhere to.

More often than not the software is something that could best be termed “mixed source,” a combination of open and proprietary code. “The development model where companies write their own software, top to bottom, is gone,” Egger said. “However, many executives don’t realize this. They came of age in a time when development was still done all internally.”

Other considerations come into play, as well. As with Cisco and Linksys, an acquisition could change your profile, or as with Linksys with Broadcom, a company acquiring a component for its larger offering could have unknowingly integrated open source.

“There’s a mistaken mindset that third party equals proprietary,” Egger said. “People just assume that when they get something from a third party that the third party owns all the rights and has transferred them.”

How Free Is Free?

Figuring out licensing can get pretty messy. Who own what is often in contention, and opening things up to comply with one license could result in an IP challenge from somewhere else.

Turning back to Microsoft, what if a software distributor decided it didn’t want the legal headaches and decided to just pay some royalties for, say, their use of Linux? They’d be set, right?

Wrong. They would then be in violation of the GPL, which prohibits those distributing GPL-licensed free software from paying patent royalties.

Microsoft isn’t going to get the free software community to roll over without a fight. Free software advocates do their own license enforcing and litigating, and they have been quite successful. There are plenty of these organizations, so those challenging open source never know who they’ll be up against.

For instance, an obscure German organization, gpl-violations.org, forced security vendor Fortinet to release code because its appliances used Linux. This was an organization few had ever heard of, not a heavyweight like the Free Software Foundation, and it scored a big win for open source.

Not every free software organization looks to litigate, though, and often the first step is simply understanding those complicated licenses.

“We don’t intend to police the GPL,” explained James Vasile, an attorney with the Software Freedom Law Center Software Freedom Law Center. “In fact, we don’t really do that much violations work. Most of our clients need to figure out how to handle licenses. Plenty of developers have used GPL but don’t know what it means.”

When the Software Freedom Law Center has a client seeking GPL enforcement, the cases usually get resolved without much fuss. “There are some willful violators out there, but the majority is just unaware,” Vasile said. “We inform them of their licensing issue, and most then ask how to comply. We don’t try to extract money from them or get negative publicity. The only thing we want is for them to distribute software in a way that is compliant with GPL.”

Another point Vasile makes to clients is that open source doesn’t mean anti-commercial. “That’s a big misconception,” he said. “Under the GPL, if you want to charge for software, you can. However, you then have obligations.”

Mainly, if you charge for GPL software, you must keep the core open. “If you get GPL code, modify it, and sell it, you have to give the people you sell it to the same rights you received. Your customers must be able to copy, modify, and distribute without difficulty,” he said.

GPL Version 3 Takes on Microsoft

The GPL itself has been causing some concern in the open-source community, due to yet another licensing misconception. Some Linux users fear that GPL Version 3 will render their existing licenses obsolete. This isn’t the case, since new licenses aren’t retroactive, but Linus Torvalds has said Linux will stick to the old license, putting many end users’ minds at ease.

Even without Torvalds’ endorsement, the new GPL could have a big impact on the future of free software. The main change with GPL 3.0 is that it more aggressively challenges patents by taking on patent partnerships (like Microsoft and Novell).

At the time of the draft release, Richard Stallman, president of the FSF and principal author of the GNU GPL, said, “The GPL was designed to ensure that all users of a program receive the four essential freedoms which define free software. These freedoms allow you to run the program as you see fit, study and adapt it for your own purposes, redistribute copies to help your neighbor, and release your improvements to the public. The recent patent agreement between Microsoft and Novell aims to undermine these freedoms. In this draft we have worked hard to prevent such deals from making a mockery of free software.”

Harsh words, and all the more reason to start thinking about those third-party indemnification programs. This fight could get a lot worse before it gets better.

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved