Open Source Licenses and Patents, Transactions, and Enforcement

Open source has evolved from something relatively unknown to something akin to having water in your pipes: you have open source in your software. The question has moved from "Who's using open source?" to "Who's not using open source?" Large companies will admit that they cannot, for all intents and purposes, develop software without the use of open source in this day and age. In the last 18 months there has even been an acceleration of this trend. You may or may not know it, but whether you are a developer or a consumer of software, you are already using open source.

The Increased usage of open source software has increased the need for license compliance. On the legal side, the advantage now is we have a better depth of understanding of the issues than at any point over the past decade.

The Open Source Census has shown that self-reported use of open source averages 94 packages per company. Based on data from typical code scans, actual use is likely to exceed this number by 3x to 10x.

Is this a cause for concern? At the very least it's a cause for compliance and for treating open source software the same way you would treat other software that you utilize. Most companies already focus on complying with proprietary software licenses, so really the only issue is bringing open source compliance up to that level. In other words, make each use of open source a knowing and compliant use of open source. There are, incidentally, many advantages to being in compliance, including use in marketing as a differentiator.

What Is Compliance?

Compliance means complying with license terms, patent and intellectual property (IP) infringement issues, and transactional documents. It has traditionally been viewed as something required, expected, and, yes, even tedious, mundane, and burdensome. But it can be a real advantage. Seeing it in this light is important. For certain there are companies out there -- well-meaning companies, well-run companies -- that haven't focused on this issue as much as they should have.

The key is beginning to treat open source software just as you treat normal software.

The essence of open source software is availability, not price. Richard Stallman, known as the founder of open source, says “The word 'free' does not refer to price; it refers to freedom. The freedom to copy a program and redistribute it to your neighbors so that they can use it as well as you. The freedom to change a program, so that you can control it instead of it controlling you; for this, the source code must be made available to you. You should think of 'free' as in 'free speech,' not 'free' as in 'free beer.'"

In other words, freedom refers to the availability of the code, being freely available for use, distribution and modification, and not the price. This is the basis of all open source philosophy, and, by extension, licensing.

Open Source Origins and Legal Definition

Open source started very much as an academic movement. It was often initially referred to as "free software," and the name didn't change until the 90s when the software industry began to notice the potential of open source, especially with the advent of the Linux operating system and the Netscape Communicator web browser.

The thinking was that open source had been overly activist and ideological. In order to bring it into the business world, the Open Source Initiative (OSI) was formed in order to tone down the ideology, transfer benefits to the commercial software industry, clarify and establish the term "open source software," and develop an Open Source Definition (OSD) to define the principles of open source software.

The term Free and Open Source Software (FOSS) is really a reference to the full history of this type of software development. Some people are militant about which term is accurate, but "FOSS" and "open source" are often used interchangeably.

The bottom line -- for legal purposes -- is that open source software is licensed software. Open source licenses make the software "open source." This is not to take away from the method of development, which often involves a distributed community of developers throughout the world working without pay. But for legal and compliance purposes, the licensing is the starting point.

Many, Many Open Source Licenses

There is one open source definition, coined by the OSI, but we have many, many open source licenses. For those with a technical background, one way to think of this is you can have a technical specification, but with many separate implementations that meet the specifications. They are all compliant to the specification, but they are all different.

All OSI-certified licenses compliant with the OSD are listed on the OSI site (http://www.opensource.org) Currently, there are over 70+ licenses, though this is growing regularly. The most often used comprise a smaller group: The GNU General Public License (GPL) version 2 and version 3, the GNU Lesser General Public License (LGPL), plus other common licenses like BSD/MIT, Apache, Mozilla, and Common Public. The rest of the 70 some licenses are sometimes rare, sometimes just slight variations of the well-known licenses, and sometimes unique and not used as much.

There has been discussion about paring back the total number of licenses for clarity, and there are good arguments for and against this. Still, this has not happened yet.

From a legal standpoint, these licenses are viewed as "form licenses." Most of the time a vendor will pick a license that fits their situation and ideals. Sometimes, they will create their own, but with 70 some licenses the need is rare. When someone does this and comes up with their own or a variant of an existing OSI-approved open source license, that gives rise to un-approved licenses. Sometimes, of course, someone will combine two licenses and even use the same original name. This is a legal headache. From this, some very legally difficult situations have resulted.

The big name OSI-licenses have been used in commerce long enough that there are databases of legal and technical analysis on what the terms mean in different situations. This has clear compliance benefits. The ability to go ahead and make a relatively definitive call on where one stands in regard to the GPL, for example, provides a more ready set of answers than it has in the past. There's more common legal understanding developing.

Of course, there are still many areas where reasonable minds differ, so don't take it for granted that any one interpretation that you find out there is the law.

One note, you will often hear the term copyleft. This is a direct takeoff from copyright. "Copyright, all rights reserved" versus "Copyleft, all rights reversed." It's a phrase originally from the Free Software Foundation and Richard Stallman. The main difference with copyleft licenses is that they pertain not just to the code but also to any possible derivatives of the code. This is exactly where a lot of compliance discussion happens.



Be sure to look closely at the text of the license when you're doing compliance and confirm not only that it is the license that you think it is, but also confirm that the provisions say what you remember them as saying. There is no substitute for looking at the license itself. Open source licenses can be viewed as a set of form licenses that are generally more liberal in the rights that they provide around the ability to modify and distribute the source code than your typical proprietary licenses.

Jacobsen v. Katzer

Open source licenses are legally enforceable. We know this by legal theory, but now we know this by actual case law as well. The most often-cited case is Jacobsen v. Katzer, which dealt with model railroad software. It started out as a patent case in which it was alleged by Katzer that Jacobsen was infringing on a patent held by Katzer. Jacobsen's response was actually where the copyright infringement claims came in. Essentially he claimed: "I may be infringing on that patent but that patent is actually based on software that I first licensed under the Artistic License. You've actually included portions of my software in the software that you then went ahead and obtained a patent on, which is fraud. The patent is thus invalid, and, in addition, you are infringing my copyright because your patent includes portions of my code. You did not follow terms of the Artistic License which require you to give me notice and attribution for using my code." Importantly, under the Artistic License, which is an open source license, Katzer was allowed to use the code, but what Katzer didn't do was let anybody know that parts originated from Jacobsen. Jacobsen wasn't given attribution for that origination. Jacobsen claimed, therefore, that Katzer's was unauthorized and that unauthorized usage constituted copyright infringement.

The district court denied Jacobsen's motion, surprising many in the open source community. The interpretation of the Artistic License was as a contract, not a license. Therefore, the breach gave rise to monetary damages but not injunctive relief. The court of appeals, which was the court of appeals for the federal circuit because this was originally a patent case, reversed and remanded back the case to District Court. The District Court again denied injunction but on different grounds. It was almost as if the District Court made a point of saying "Well, ok, you can tell us our business but you still can't tell us how to decide the outcome." The grounds were largely procedural, and there had been a shift in the standard for obtaining an injunction between the time this case was originally filed and the time that the case was remanded back to the District Court. Eventually, this case was settled out of court in early 2010. The settlement was not kept confidential and is available at: http://www.docstoc.com/docs/25847971/Jacobsen-Settlement

The settlement was relatively straightforward with a monetary component and an agreement to cease use of the offending code and several other terms. But thankfully for those involved in this area of open source -- open source compliance and interpretation of open source licensing -- this case stayed around long enough to actually yield legal precedent.

There is some great benefit from Jacobsen v. Katzer. The Artistic License is now known as enforceable as a license and not as a contract. What does this say about all open source licenses? Well, there are 70 some open source licenses and many different terms. The Jacobsen v. Katzer decision is worded broadly enough that you can point to it and say most approved open source licenses will be enforceable as licenses not as contracts.

Notice and attribution provisions create conditions, not covenants. Conditions on a license mean a license whereas covenants suggest a contract. This was dealt with in all three decisions in Jacobsen v. Katzer.

Also, the conditions are of "significant and direct" economic benefit to the licensor. In an open source license in a situation similar to Jacobsen v. Katzer where there is no money exchanged for the distribution of the software, the question of economic benefit came into play. Would there even be any damages had this been a contract? It's given away anyway. The court found that there were, in fact, significant and direct economic benefits to these notice and attribution conditions, and thus enforcement as a license is necessary to protect the rights of the licensor to accomplish the objectives of the license.

Interpretation as a contract would have rendered the Artistic License meaningless by foreclosing the ability of the licensor to enforce those provisions through injunctive relief.

Copyright licenses are designed to support the right to exclude. Monetary damages alone do not support or enforce that right. The choice to exact consideration in the form of compliance with the open source requirements of disclosure and explanation of changes rather than as a dollar-denominated fee is entitled to no less legal recognition.

Violations of the Artistic License give rise to claim for copyright enforcement, not just damages as with breach of contract. Remedies include the potential to seek injunctions, the potential for statutory damages, and the potential to cover attorney's fees.

Jacobsen v. Katzer is a very important decision. Since it is likely applicable to other open source licenses as well, it gives a very large club that open source licensors can now legally wield. It was thought about, hypothesized about, and written about for a long time but to now actually exists in the form of a case validated at the Appellate level of the United States Court of Appeals for the Federal Circuit (CAFC) is extremely positive for the open source community. You will continue to hear a lot about this case and rightfully so.

So open source licenses are not only enforceable, they are being enforced. This is significant because up until a few years ago open source licenses were enforced through private enforcement actions outside of courts. The Free Software Foundation (FSF) run by Eben Moglin and Dan Ravicher were responsible for multiple hundreds of private enforcement actions. They were all kept out of court.

Enforcement Actions

There have been some notable enforcement actions, including actions against Linksys and Broadcom involving software that was embedded on the Linksys routers provided by offshore developers to Broadcom. The legal action began right about the time when Linksys was purchased by Cisco and bubbled up into an actual court filing.

Interestingly enough, you do not often hear about these types of cases. No one wants to go on record. This is despite the fact that usually, and, in fact, most all of the time, non-disclosure agreements are not signed in these out of court settlements. So they are legally able to talk, they just don't want their companies associated with these enforcement actions. Why? It's a testament to the effectiveness of these actions.

In Europe, Harold Velte of gpl-violations.org and now affiliated with Free Software Foundation Europe (FSFE), has brought multiple actions that reached the courts in Munich and elsewhere. Sitecom and D-link were a couple of earlier cases. Skype and SMC are more recent cases, and Fortinet in the middle of those. In many respects, this out-of-court and then progressing into in-court open source enforcement actually had a lead in Europe. And back in the day before we had a court case in the United States, many people looked to the translation of the filings of the district court in Munich to see if we could glean any information about compliance, mainly around the GPL license.

The Anatomy of Enforcement Actions

The anatomy of enforcement actions is still interesting to look at. If you look at the court cases that have been brought, the actions and activities that lead up to those filings possess many common traits. It's primarily against a company distributing proprietary technology, but not always. It's generally agnostic in regards to the size of the company and location. In Europe, for example, enforcement actions were not only in Germany. They were in Spain and in the UK as well. They typically involved the GPL and that has been the case in the United States as well, but you increasingly see more activity around other licenses. Part of the reason is that the GPL Version 2 has historically been the most popular and widely used open source license, so there's just more popular and valuable software that is licensed under that license. It also tends to be a more complicated open source license.

There are few rules of engagement, but patterns do exist. An informal inquiry to begin with, followed by a more formal inquiry and a demand for compliance. Often all of this only happens through email, not letters. Then it will move to cease and desist letters where you are actually exchanging correspondence, but still no actual legal proceedings until we reach the cases that have come to be known as the BusyBox cases. They are often not long in duration, either. (They can be longer, characterized by periods of activity along with periods of delay, sometimes because the FSF was just understaffed or overburdened.) It's a collaborative resolution process; mostly they do not want money but just compliance. The emphasis is trying to bring more users of open source "under the tent." If you're unable to comply or unwilling to comply, they will very politely tell you that they do not want you using open source. But generally the goals vary by enforcer.

The process is typically kept private even though non-disclosure agreements (NDAs) are generally not signed, which is interesting. Most enforcement actions are private, basically. Far more enforcement actions are kept private than ever see the light of day in court.

BusyBox

The initial batch of enforcement actions involved some relatively small companies, the smallest being High Gain Antennas –- a mom and pop operation –- through to big companies like Verizon and many others you'll recognize.  However, the common theme was companies distributing open sourced software on Linux-based devices. One of these companies was BusyBox. BusyBox is a Linux utility, Linux the very popular operating system. The advice went out immediately to everyone that if you're using Linux on your box, make sure that if you're using BusyBox you're compliant. And, rightfully so, because during periods of inactivity lawsuits were filed.

Users stretched outside of device providers to the consumer or retail space. There have been lawsuits with Best Buy, JVC, Bosch and more. These have come to be known as the BusyBox lawsuits, and they are characterized by very straightforward failures to comply with the GPL. For example, a device is distributed without the BusyBox source code -- not the kind of doomsday cases where a company is modifying code licensed under the GPL or linking to code that's licensed to the GPL. That case is still out there to be heard but BusyBox was not that. It's relatively innocent by most accounts. In most cases the accused didn't even know what was happening, in most cases because they had received the firmware from a third party. The cases sought relief in the form of unspecified damages, litigation costs, and an injunction against further use of the BusyBox software. There was a trend toward settlement. Most if not all of the initial cases brought have settled. Again, settlement terms signed in most cases are generally not public because firms don't want to bring attention to themselves.

These started at all types of companies. The common thread was BusyBox and Linux as the operating system. Most appeared to be innocent, with some receiving the software from a third party. Only Verizon seems to have received an indemnification from its supplier. Verizon was indemnified and basically turned the case over to its software provider. The disputes were preceded by contacts with the defendants. Again, not unlike the private enforcement actions, third parties are not always named. It included a follow-up by the Software Freedom Law Center (SFLC). Meaningful attempts to negotiate were generally the case, although some early on were questionable. There were rapid movements to lawsuits -- sometimes very rapid from the standpoint of reaching a stalemate and moving on and not letting these cases wallow. None of the defendants have challenged the allegation to date, on the record, which speaks to the strength of the GPL as well as the straightforward nature of the claims. Looking at this, one can't help but wonder if BusyBox has become the model for GPL lawsuits. The case against Cisco, for example, came after a number of these BusyBox cases. Those complaints are all available online and certainly you can make your own comparisons. There's room for a model for other types of GPL claims, but for a straightforward GPL compliance claim, it's very instructive to look at this and understand that BusyBox is likely what you're going to be held to.

What does this mean?  We think it strongly indicates an increased premium on preemptive diligence and action. Certainly if you're shipping a Linux box these days you had better be certain you're compliant.  Even if you're not shipping Linux on a device, if you're distributing open source software, first, these cases make abundantly clear that you should make sure you're not adding yourself to the list of BusyBox defendants, and second, making sure that you're complying with the applicable licenses. It's also a strong justification to look upstream, as most software is not entirely developed in-house these days, and make sure you're in agreement with your software providers. Have specific open source provisions in your agreements. These are easy cases but they don't go away. Compliance remains a top priority. This wasn't just about money, but about getting compliance as well, and a collaborative process to do so. It can be a cooperative process. From the defendants' standpoint, what seemed to work best is finding a willingness and an ability to comply and demonstrating competence through those two tools.

One very specific note: Every company has 800 numbers and emails for assistance, but consumers often wonder if anyone answers those. If you're in-house at a company you want someone to actually answer those. If there's an open source inquiry, it should be routed to legal because it was that kind of inquiry that ultimately gives rise to those lawsuits.

Fear and Loathing

Back in 2004 Open Source Risk Management published a study that indicated there were 283 patents implicated by Linux with at least 27 of those held by Microsoft.

Since that time we've seen plenty more open source patent lawsuits. FireStar bringing its case against RedHat. Acacia Research bringing a case against Novell and RedHat. More recently, Artifex bringing suits against Diebold and Palm. Very much in the news, Microsoft bringing suit against TomTom, the GPS maker. And IBM bringing a suit against TurboHercules, and the controversy of whether that was truly an open source suit or not. Suffice to say, if you're using open source software, you need to be concerned about the patent landscape, same as you would for proprietary software. Further, you need to be following many of the same steps when you evaluate patent infringement.

Let's look at some settlements.

Microsoft vs. TomTom Five year term, covering both past and future U.S. sales of the relevant TomTom products. This is from the press release: "the agreement includes patent coverage for Microsoft's three file management systems provided in a manner that is fully compliant with TomTom's obligations under the General Public License Version 2." We don't have access to the actual settlement document -- so we're left to wonder for sure -– but it purports to be open source compliant. Also TomTom will drop FAT-patented parts of its products. TomTom will remove from its products the functionality related to two file management system patents (the "FAT LFN patents"), which enables efficient naming, organizing, storing and accessing of file data. From the release, "TomTom will remove this functionality within two years, and the agreement provides for coverage directly to TomTom's end customers under these patents during that time."  But only a five year term, so presumably TomTom needs to move on and move away from the offending code in that time period or it would be open to suit once again.  Notably, Microsoft is passing patent protection to TomTom's end customers. Those of you who know about the Microsoft-Novell patent agreement will notice some similarities here with some of the technology and some of the language. Really though, the suit is over but the issue lives on. This really didn't provide any broad-reaching protection other than protection for TomTom's end customer in this period of time. TomTom came out of this settlement with work to do.

Firestar vs. RedHat Contrast that with the settlement in Firestar vs. RedHat. Here the whole settlement document is available online.(http://www.redhat.com/f/pdf/blog/patent_settlement_agreement.pdf). "Very broad" is the way one would characterize this settlement. All software licensed under the RedHat brand, derivative works of RedHat branded products, and combinations of software including RedHat branded products –- it's all included. Upstream developers as well as predecessor products of Red Hat branded products, distributors, customers... everyone is covered by this. All patents owned by DataTern and Amphion are also included -- a broad array of patents. There is a tremendous amount of differences between Firestar vs. RedHat and Microsoft vs. TomTom. Which becomes the model remains to be seen. Other pending cases may see an opportunity for different settlement models. The broad RedHat model is an industry model, while the TomTom model is far narrower. In terms of accessing risk following patent infringement, knowing what the terms were of each of these settlements can be important so you can advise your clients on what are the implications of settlement. This is information we didn't have five or ten years ago.

Industry Expectations

The other area of compliance is industry expectations that companies be compliant in M&A transactions, finance, distribution, and OEM deals. Companies that offer products that leverage open source -- companies that have made the build versus buy versus open source decisions -- have done their homework and are truly compliant. If you're using open source even in a network environment, and you're providing a SaaS model, there's even an expectation here that you're compliant. In looking at the end game for a number of companies (whether IPO or channel agreements), expectations are continually moving upward in terms of what consumers of your technology are going to expect. They're going to expect compliance.

These industry expectations can often be bigger drivers than the legal considerations because this is really how money comes in the door. If you're not meeting expectations, you end up with important issues that can break a deal.

Increased Hassles and Risks for the Unprepared

Many parties are not well informed. There are often overly broad requests from buyers in M&A transactions. Requests go beyond what you would legally or reasonably need. Sometimes that's just erring on the side of being conservative, other times it's just the buyer being uninformed. Beware of those overly broad requests. Be ready to speak about why you want to scale them back, whether it's incompetence or just being incorrect. Be ready if you're on the side of making those requests for companies that really don't understand what you're asking for. It's surprising but true.

Open source obligations, provisions and covenants have really evolved. It's going to vary by industry and by company. Some companies with open source risk profiles that are far narrower than others will be far more stringent in their requests. It's not just a matter of startup company versus large technology company. There are plenty of startup companies that are just as diligent about this as the ones devoting millions of dollars and have compliance departments like HP or IBM.

Diligence requests have evolved as well. These can be closing conditions to deals. They can have real business implications. Even more so than being the subject of a BusyBox lawsuit, it is these expectations and the fact that if a company's business plan is leading them towards this type of deal, that's what's driving open source compliance these days. Gauge your open source compliance to be able to meet the related provisions. Don't wait until you have these provisions in front of you. Actually build your open source compliance programs and policies. Put your dollars toward meeting these expectations. It sounds pretty basic but it's interesting how few companies look at doing that. Companies are good at setting goals to measure their success, but don't often consider the legal hurdles they'll encounter to get there. For open source, it's very helpful to be able to do that.

Conclusion

Looking at what you should do in terms of compliance, focus on open source-specific provisions, the covenants you see that are open source specific. But recognize that other provisions will likely apply to open source as well. There are plenty of agreements written that don't use the word "open source" but still have plenty of provisions in terms of dealing with third party licenses, third party IP infringements, and rights in third-party developed software -- even confidentiality, protection of trade secret provisions, and provisions dealing with source code disclosures. Provisions as seemingly unrelated as compliance with applicable laws can apply. Certainly the interplay with the indemnification provisions of the deal and the caps on liability come into play.

And, finally, even provisions dealing with compliance policies and procedures. This can have big implications. It need not if it's managed correctly. Open source is everywhere these days, so looking at compliance proactively, placing a premium on being prepared, or complying on a distributor or purchaser or OEM's terms are necessities. The provisions that we've included come from real companies who don't want to inherit anyone in their supply chain. Compliance is key if you want to do business with products that use open source.

Best practices in compliance have been here for five or ten years. You've probably heard of them before. The key is actually doing them. And getting companies to continue doing them. There are now concrete reasons to comply, and to employ these best practices. Both legally and from a business perspective. There are a lot of tools and resources available for compliance, one being OpenLogic. Your job in compliance is to use those tools. Don't wait until the eleventh hour. Don't have your head in the sand. Compliance is no longer a "nice to have" but is now an "expected to have."Follow @openlogic
Follow @OSCloudServices

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.