Mark Radcliffe on intellectual property, software patents, & open source software is Eating the World

  Mark Radcliffe is a senior partner who practices corporate securities and intellectual property at DLA Piper. Mark’s practice focuses on representing corporations in their intellectual property and finance matters. He has worked with many software companies, in particular open source software companies. He assisted Sun Microsystems in open-sourcing the Solaris operating system. On a pro bono basis, he serves as outside General Counsel for the Open Source Initiative and on the Legal Committee of the Apache Software Foundation. He was recognized for his experience by Intellectual Asset Management magazine as one of the world's Leading 250 IP Strategists. The National Law Journal named him one of the 100 Most Influential Lawyers in the United States.  

 

Mark Radcliffe is a senior partner who practices corporate securities and intellectual property at DLA Piper. Mark’s practice focuses on representing corporations in their intellectual property and finance matters. He has worked with many software companies, in particular open source software companies. He assisted Sun Microsystems in open-sourcing the Solaris operating system. On a pro bono basis, he serves as outside General Counsel for the Open Source Initiative and on the Legal Committee of the Apache Software Foundation. He was recognized for his experience by Intellectual Asset Management magazine as one of the world's Leading 250 IP Strategists. The National Law Journal named him one of the 100 Most Influential Lawyers in the United States.

 

API Economist: Trying to grasp the legal aspects of intellectual property and software is incredibly challenging. Is this due to the sheer lack of case law and precedent?

Mark Radcliffe: I think that's part of it. But I also think you need to go back a little bit and talk about how software came to be covered by copyright. If you go back to the 1980s, there were very respectable intellectual property lawyers who would tell you that software was not copyrightable because it was a functional “work”.  Only certain types of software would be copyrightable. Moreover, when the Copyright Act of 1976 was enacted, Congress deferred the decision about protecting software under copyright until they received a report from a special committee, the National Commission on New Technological Uses of Copyrighted Works (CONTU). Although CONTU recommended protection for software under copyright, one commissioner suggested that copyright not apply to “computer program in the form in which it is capable of being used to control computer operations.”  Now the courts have made it very clear that software is protected by copyright, in fact almost any form of software is copyrightable. But copyright is actually a pretty poor fit for software. It's a poor fit because there's a large degree of functionality in software. Copyright was designed for music and literature and novels, things where you'd have immense scope in the choice of how you create the “work”.

There are very few restrictions on how you write a novel or other literary work. But in software, writing a program is constrained by the languages you're using, it's constrained by the operating system and, it's constrained by the hardware. These types of functional restrictions don’t have much history in copyright law and it has been difficult for the courts to decide what is protectable “expression” in software.

While we have a number of court decisions, unfortunately they have not dealt with many fundamental issues, which are still outstanding. For example, what is a “derivative work” in software? Under US copyright law, a “derivative work” is “A work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'.” Thus, the movie “Gone with the Wind” is a derivative work of the novel. However, applying these principles to software has been difficult. While the answer is relatively straightforward if you've added twenty lines of code to a particular module. It gets very complex and very gray when you're trying to determine whether modules which are “staticallylinked” or “dynamically linked” are creating a “derivative work”.

The movie, Gone With The Wind, is considered to be a derivative work of the novel. (Image Credit: IMDB).

The movie, Gone With The Wind, is considered to be a derivative work of the novel. (Image Credit: IMDB).

This area has a substantial degree of uncertainty, because the case law in that area has been very thin and the decisions have not been consistent. This issue is not solely of interest to lawyers because the scope of the obligations under the GPLv2 (and the GPLv3) depend on this question. Many proprietary software companies continue to be concerned about the uncertainty of developing products which combine proprietary software and FOSS licensed under GPLv2 or GPLv3. They want to ensure that they are in compliance with the licenses, but the scope (based on “derivative works”) of GPLv2 and GPLv3 is not clear. 

API Economist: And within case law that exists, are there different interpretations across the United States courts?

Mark Radcliffe: That’s correct.  US Federal courts are organized into twelve “regions” each with their own Court of Appeals which governs the law in that region.  The Courts of Appeals have developed three different tests for copyright infringement for computer software.  The two major Courts of Appeals dealing with copyright issues, the Second Circuit (including New York) and the Ninth Circuit (including California) have different tests for copyright infringement of software. Thus, the legal consequences of the same acts may differ depending on where it occurs.

API Economist: These software patents seem to be worth a ton of money.

Mark Radcliffe:  Yes, software patents have become important recently.  It's interesting that here we have this very valuable asset, software, but the intellectual property law governing it remains uncertain. Just turning a little bit of a corner here and talking about patents, their application to software continues to be controversial.

Going back about 20 years ago, many patent lawyers would tell you that you couldn't apply patents to software. That's obviously changed. Now we have a lot of discussion about what the scope of patents applying to software should be, particularly business process patents.

A significant challenge to using patent laws to protect software is that the functions of software is frequently confidential and the software industry has not tended to publish or otherwise made public, so it is difficult to determine whether an invention in software is sufficiently“new” and “non-obvious” to qualify for patent protection.  Other industries subject to patent protection, such as pharmaceuticals and bicycles, have a long and rich history of publications and the determinations about “new” and “non-obvious” nature of an invention are much easier to make.

API Economist: Despite the examination of software patents by the United States Patent and Trademark Office, it sounds like we should reform the patent system. Do you agree?

Mark Radcliffe: Yes, I think we need a reform to the system. However, we are not likely to get a statutory change, because the recent enactment of AIA, the America Invents Act, took a long time to negotiate. The American Invents Act is an example of the challenges you face in reforming patent law, because different industries have very different interests. For example, the software industry, in which a computer or even a computer chip could have hundreds or thousands of patents infringed. Just a reminder that a patent is not an affirmative right to manufacture a product, it's a negative right. It's a right to prevent someone from making, using, and selling a product which includes your invention.

Image Credit: USPTO.gov

Image Credit: USPTO.gov

For example, a typical Intel microprocessor has five to seven thousand patents which “read” on that, which could prevent Intel from selling it. In that context, the technology industry wanted to say, “We need to get rid of the automatic granting of an injunction for patent infringement.” An injunction's basically an order by the court ordering you to do or not do something, such as distributing a product. The software industry wanted to focus on a method of paying damages or royalties that reflect the fact that the patent may only affect one very small part of a very large combined system. There's one case involving Microsoft where Alcatel Lucent claimed that that the Windows Media Player (a small part of the Windows operating system) violated its patents. The court initially used the value of the entire value of the Windows operating system to calculate the damages. Obviously that is very difficult, just not practical.

On the other hand, the pharmaceutical industry insists that automatic injunctions are required to protect the drugs which have taken hundreds of millions of dollars to develop. Such drugs are generally covered by only a few patents (unlike electronic products). The industry insisted that they need to get an injunction to stop companies selling generic versions.

The AIA, which took this long period of going through Congress, was not able to resolve these issues. While the patent system continues to have problems,  I think the practical chances of major new changes is low. 

API Economist: So, despite the AIA, is it left to the courts to muddle through this?

Mark Radcliffe:  The AIA did make some valuable changes, but many important issues remain to be decided by the courts. And the courts (in particular, the Supreme Court) has taken up these challenges: they are becoming much more active in patent law. Recently, the courts have dropped the automatic grant of injunctive relief for infringement.

The courts have now said no, that isn't the case. They have insisted that traditional standards for granting injunctive relief apply to patent suits: the plaintiff [1] that he is likely to succeed on the merits, [2] that he is likely to suffer irreparable harm in the absence of preliminary relief, [3] that the balance of equities tips in his favor, and [4] that an injunction is in the public interest.”  More recently, the Federal Circuit held that a party seeking a preliminary injunction must show, as part of the irreparable harm requirement, a causal nexus between the alleged infringement and the alleged harm. 

The reason that that's important is you take a look at the RIM case involving Blackberry. A patent troll, NTP, sued RIM. The court initially awarded NTP $33 million in damages (increased to $53 million) and an injunctive relief. However, RIM’s concern about the effect of injunctive relief was so great that RIM settled the suit for over $600 million.

The threat of an injunction gives the plaintiff great leverage: RIM paid twenty times (or 12 times the “willful damages”) the actual damages to avoid the injunction.

So the courts have changed their approach to injunctive relief. Such relief is no longer standard and many cases the only relief will be damages. This change is helping make disputes less dangerous. We will also probably see courts cutting back on the scope of patents, particularly in the business process and software area.

And the patent office is making a special effort to avoid granting “junk” patents.  They are particularly focused on being more effective at looking for “prior art”, proof that the invention was used in the past and is not “novel”.

API Economist: Mark, maybe to the untrained lay person who uses open-source software, I would think that many people think that you can do whatever you want with open source software. It's open source, it's free, I can do anything, nothing matters. That's not really the case, is it?

Mark Radcliffe: No, it really isn't. There's a famous quote by Marc Andreessen: Software is eating the world. That's true. But I could change the quote: open-source is eating the software world. The development of software has changed dramatically in the thirty years that I have been practicing: when I started, software was written in-house, occasionally using some existing third party software under license. The developer needs to be a hard core programmer. Now software is essentially assembled from preexisting components, many of which are open source. Then you put some additional proprietary software in the product or you add some new proprietary layers on top of the preexisting components and bang, you've got your product. Even large companies such as Microsoft and Apple are using this approach. That's the new reality of software development.

So we've reached, in some ways, nirvana from software development: the reuse of code. You don't have to constantly rewrite the “time/date” module for your new product. However, nirvana is that, like the Garden of Eden, it has snakes. The snakes, unfortunately, are software licenses that don't work well together.

The logo of the Open Source Initiative. The OSI maintains the Open Source Definition and  the list of Open Source Initiative-approved licenses.

The logo of the Open Source Initiative. The OSI maintains the Open Source Definition and  the list of Open Source Initiative-approved licenses.

For example, you can't really integrate code that's licensed under GPLv2 and code licensed under the Apache License, Version 2, in a way which creates what's called a “derivative work” with the GPLv2 licensed code, a very close form of integration. That doesn't mean you can't have modules licensed under those two licenses in a product if they are not “derivative works”. You can and many products do. But if the integration of two modules is tight enough to create a derivative work, then you've got a problem, because you have incompatible obligations under the licenses.

However, your original point is a significant one:  open source software does come with a license which has terms and conditions and you need to comply with those terms and conditions. I can tell you from my experience, which includes helping companies obtain investments from venture capital money and “exit” by merger, the use (or misuse) of open-source software is getting an enormous amount of attention from investors and potential acquirers.

If you're not properly managing open source software and complying with license obligations, then the terms will change and may even, in rare circumstances, kill the deal. The result in mergers is that the escrow goes up. I've seen an escrow increase by 50 percent. In that case, the purchase price was $100 million and the initial escrow was $15 million, but was increased to $25 million because of concerns about failure to comply with open source software licenses. Basically, the stockholders didn't get the extra $10 million for twenty four months (if no claims are made) after the closing because of their lack of open-source software compliance.

Thus, the idea that you can do anything you want with open source software is a very dangerous one. Because at critical points during company’s history, a venture round or an acquisition, the lawyers for the other party will go through your open source software compliance will be reviewed with a fine tooth comb. Acquiring companies (and some venture funds) use Black Duck or Palamida to do a scan ofyour code.

In fact, I have three Black Duck reports on my desk right now. If the acquiring company finds that the use of open source software has not been properly managed, for example you only manage it an ad hoc fashion, the acquiring company will start considering their options to mitigate the risks: increasing the size of the escrow, decreasing the purchase price by the cost of any remediation and even delaying the closing to permit remediation 

API Economist: When the Linux Foundation was established you had the first practical open source operating system in the market. But it seemed like Linux really took off once IBM brought all of its resources to bear. Here we are in the age of the cloud and I think of OpenStack and it's like history is repeating itself with IBM bringing their resources to bear and backing the project.

Mark Radcliffe: I think you're absolutely correct. And that has accelerated dramatically. The Linux Foundation, for a long time, was one of few open source software foundation (the Apache Software Foundation is another long time foundation). But what in the last three or four years we have seen the broad recognition that software is fundamental in many industries. And the recognition, much software is “generic” infrastructure that does not really add competitive advantage, but everybody needs it.

The question is how do you focus on the software that's going to differentiate your product and separate it out from the underlying “generic” infrastructure, the plumbing that every company needs but doesn't need to be separately developed by every company.

OpenStack is an example of this new approach:  a group of companies (there are now over 180 companies including AT&T, HP, IBM, and Rackspace) that have come together to create the infrastructure for cloud computing. Interestingly enough, this project actually started out as a joint venture between Rackspace and NASA, and it evolved over time.

First Rackspace took more responsibility for managing the product (and eventually, NASA, dropped out of the management of the project). Rackspace then put it into a separate limited liability company. Over time, the community convinced Rackspace, that they needed to have an independent foundation if it was really to grow. I think that decision has been tremendously successful and OpenStack is now one of the most rapidly growing projects in history. 

API Economist: I interviewed Julius Marchwicki of Ford earlier this year and he mentioned that they were open sourcing AppLink code to the GENIVI Alliance, making them the first American automaker to do so. It’s another example of open source software eating the world.

 Mark Radcliffe is a senior partner who practices corporate securities and intellectual property at DLA Piper.

 Mark Radcliffe is a senior partner who practices corporate securities and intellectual property at DLA Piper.

Mark Radcliffe: GENIVI is an example of how this approach is breaking into industries that are not traditionally considered as “software” intensive. The problem that GENIVI had was it was taking a long time (sometimes more than five years) to put a new in-vehicle infotainment (IVI) into automobiles, because automakers would give the system requirements to suppliers who would then build each IVI independently, resulting in long development cycles and high costs. Then you were stuck with that system for however long that model of car was around.

GENIVI brings together CE manufacturers and the car companies and assists them to make such development and integration into more of a plug and play situation which permits CE manufacturers to integrate new IVIs much more rapidly. GENIVI is only a small part of the software in a car: modern cars have more software than an Apollo spacecraft.  You've also got the Lodestone Foundation, which is spinning up from the financial services area.

API Economist: I’m not familiar with the Lodestone Foundation. What do they do?

Mark Radcliffe: It was backed by Deutsche Bank. It aims to cultivate an ecosystem of open source software for capital markets firms. Individual companies are also using open source strategically. I think that the most interesting approach has been adopted by Netflix. Netflix is essentially open-sourcing most of their infrastructure. They've been doing it gradually over time. They've decided that their competitive advantage does not necessarily lie in parts of their infrastructure, but exists in their algorithms and other parts of the system.

I think that it is an interesting approach. If you go back even a couple of years, nobody would have considered such a strategy because their infrastructure was their secret sauce. They have changed that view. 

API Economist: How has cloud computing impacted open source software licensing that was traditionally distributed in an on-premises construct?

Mark Radcliffe: It's had a dramatic effect. The open source world has two strands of licenses:  copyleft licenses, such as GPLv2, GPLv3, LGPL, and similar licenses and permissive licenses, such as Apache and BSD. Virtually, all open source licenses are based on the assumption that the software is going to be distributed. It's going to be distributed on a floppy disk or later on a CD or DVD.

In the new cloud computing world software is not actually distributed, the functions are provided, such as Google’s search service. Consequently, many of the basic assumptions on which copyleft licenses are based will be no longer be correct. Copyleft licenses assumed that you were developing a community code base, that would be distributed and, thus, the source code would be made available to the entire community. Consequently, the code base could continue to be developed.

In cloud computing, most code is never “distributed”  then those obligations under copyleft licenses to make source code available are never triggered, so that underlying assumption goes away. It's had an enormous effect

API Economist: So that’s the catch, distribution?

Mark Radcliffe: That's correct. That's the thing that triggers obligations for traditional copyleft licenses. However, two common licenses, AGPL and OSL base their obligations on “communicating” or “making available” the software over a computer network. The AGPL is more limited since it only applies to modified code. But these licenses are used very, very rarely. By and large, and the amount of code that's under those licenses is de minimis. Thus, the cloud computing environment continues to undermine the assumptions under traditional copyleft licenses that they are creating a community code base whose source code is available to all members of the community. 

API Economist: Let's now get to our favorite question here at The API Economist. What are some of your favorite mobile devices and mobile apps?

Mark Radcliffe: I'm going to be very traditional here, because my favorites are my iPad and my iPhone, but I still use is my BlackBerry. Unfortunately, I have to use that for business. My favorite app of all time is Kindle app. I absolutely love the Kindle app. I also listen to a lot of books that are read, so the Audible app is something I like a lot. I also like to drink tea, and there's an app called TeaMap, which is a great little app that allows you to find tea houses in cities all over the United States. It isn't very good overseas, but you can find that them by Google.

Then I also like to go cycling when I'm traveling. Many cities have their own apps, such as “I Bike Boston” and “London Bike Rides” although Google Maps can be very helpful to figure out where you are. And Map My Ride is a great app for planning rides.