On December 6, California’s Attorney General sued Delta Air Lines, claiming that Delta’s “Fly Delta” mobile application violated California’s Online Privacy Protection Act of 2003 (“CalOPPA”). CalOPPA is the state law that requires operators of commercial websites to post the ubiquitous “California Privacy Rights Notice” that shows up in most privacy policies. In simple terms, the law requires commercial websites to conspicuously post a privacy policy that identifies the categories of personal information that the operator collects, how that information is shared, how consumers can review or modify the information that is collected, and how the operator will notify consumers of material changes to the policy.

But CalOPPA doesn’t only apply to commercial websites. It also applies to “online services” – and the California AG has interpreted that term to include mobile apps. In October, the AG’s office notified about 100 companies, including Delta, that their apps did not comply with CalOPPA, and warned them to come into compliance within 30 days.

After 30 days passed, the AG sued Delta, accusing the Fly Delta app of violating CalOPPA. The app, which has been downloaded millions of times since October 2010, allows customers to check-in online and view reservations, among other things. Through the Fly Delta app, Delta allegedly collects certain personal information, including the user’s name, address, phone number, email address, credit card number, date of birth, passport number, geo-location data, and other such information. Delta’s website contains a privacy policy, but according to the AG, this policy doesn’t mention the Fly Delta App, doesn’t disclose all of the data that the Fly Delta app collects, and isn’t conspicuously accessible to users of the Fly Delta app.

The potential liability under CalOPPA is significant: the law authorizes fines of up to $2500 for each violation. Delta apparently published a privacy policy for Fly Delta app after suit was filed, and a settlement of some sort is likely, but no business wants to deal with this kind of lawsuit and the resulting public relations headaches.

Businesses that offer mobile apps can draw several lessons from Delta’s misfortune.

First, be aware that mobile apps may be subject to state and federal privacy regulations. Make sure that you’re familiar with the laws and regulations that may apply. This is no small task: the laws can include CalOPPA’s privacy policy requirements, Massachusetts’ regulations governing data security, the various financial and health privacy laws, and state data breach laws.

Second, make sure that you’re aware of what personally identifiable information is being collected by the app, what your business is doing with that information, and how it’s being shared.

Third, make sure that your privacy policy explicitly addresses your app and discloses all of the categories of information that are being collected and used.

Fourth, make sure that your privacy policy is conspicuously available to users, not just on the company website, and not just on the platform through which the app is offered, but through the app itself.

Fifth, if you’re outsourcing the development of your app, make sure that your requirements and specs address privacy issues, and consider whether it’s appropriate or possible to obtain representations, warranties, and indemnifications from the developer.

Finally — and this should go without saying — if you receive a notice from a regulator raising privacy issues, make sure to respond. Dealing with the matter early may avoid bigger problems later.

I wrote not long ago about a lively debate among FOSS advocates about the strategies for GPL enforcement. It started when Landley, a lead plaintiff in many of the enforcement actions brought by the Software Freedom Law Center (SFLC) and Software Freedom Conservancy (SFC), spoke out about his disillusionment with the way those actions were handled. As Landley described it, the GPL “zealots” (his term, not mine) used relatively minor violations of GPLv2 and the threat of injunctions to unfairly leverage significant concessions and monetary payments from consumer products manufacturers.

Declaring “GPLv2 BusyBox . . . one of the most dangerous pieces of software you can ship,” Landley announced that he would rewrite BusyBox under a non-GPL, permissive license to “stop BusyBox from being used as a bludgeon against the world at large:”

The BusyBox license enforcement lawsuits were a HORRIBLE IDEA, I regret having started that ball rolling, I couldn’t stop it. I can only render it irrelevant with fresh development.

Landley has since released toybox as a non-GPL alternative to BusyBox. Proponents of GPL enforcement lashed back at Landley. Matt Garrett assailed him for creating a non-GPL alternative to BusyBox that will make it easier for others to violate the GPL. Bradley Kuhn, head of the SFC, accused Landley of engaging in an “anti-copyleft political ruse.” According to Kuhn, Landley is just a “copyleft opponent” who used a “sophisticated political strategy” to exacerbate “minor strategy disagreements among those who do GPL enforcement.” Kuhn and Harald Welte, whose gpl-violations.org enforces the GPL in Europe, vowed that GPL enforcement would continue, and even increase.

Without BusyBox in their arsenal, many thought that Kuhn’s and Welte’s enforcement efforts would grind to a halt. Garrett urged developers who held copyrights in Linux to come forward and take up the enforcement flag, and it appears that some have heeded the call. The Software Freedom Conservancy announced that seven Linux kernel copyright holders, including Garrett, asked the SFC to enforce their copyrights on their behalf. Kuhn expects other Linux developers to join the process. In addition, the Samba project also appointed the SFC to enforce GPL compliance on its behalf.

Kuhn and Garrett expect that GPL enforcement efforts can become more effective in targeting Android and other embedded systems by including Linux kernel copyrights. According to Garrett:

The kernel is the fundamental component of Linux-based devices. . . .Android has been designed to use as little GPLed code as possible, and what we’ve been seeing recently is that companies have been trying to get rid of even more GPLed components in order to reduce their obligations. Obtaining compliance is easier if you have copyright holders involved, and if the only GPLed component on a system is the kernel then that means getting kernel hackers involved.

Moreover, the addition of Samba copyrights now gives the SFC the power to address GPLv3 violations, since Samba is licensed under GPLv3 or later versions.

Landley tried to take the BusyBox club out of the SFC’s hands, but it seems that only allowed them to pick up two, much bigger, bludgeons. Blogs

Last year, for instance, I wrote about how Google had worked around the GPLv2 when it created Android’s Bionic library, using an automated script to “clean” the Linux kernel headers.  After analyzing the code in several files, I concluded that Google’s categorical, automated approach to “clean” the headers didn’t work as a matter of copyright law, and I observed that Google’s methods provided an easy bypass of the GPL for commercial exploitation.

A number of journalists and bloggers recognized the implications of Google’s approach.  But after Linus Torvalds gave a flippant quote to a blogger that the idea “seems totally bogus” – even though Torvalds had not bothered to review the code or the “cleaning” of the Linux kernel header files – critics of my analysis declared it “debunked.”

This sort of thing has happened before.  Back in the early 2000s, the FOSS community  was quite fractured over the issue of whether loadable kernel modules (“LKMs”) could be offered under a non-GPL license.  Many, including the Free Software Foundation, took the view that LKMs were derivative works of the kernel that were subject to GPLv2.  Viewed strictly from the perspective of copyright law, that analysis has some force.  Many open source companies (including some of my clients) were trying to understand their obligations and their risks.

Torvalds took the view that LKMs were by definition derivative works of the kernel.

You just can’t make a binary module for Linux, and claim that that module isn’t derived from the kernel. Because it generally is — the binary module not only included header files, but more importantly it clearly is not a standalone work any more. So even if you made your own prototypes and tried hard to avoid kernel headers, it would still be connected and dependent on the kernel.

And note that I’m very much talking about just the binary. Your source code is still very much yours, and you have the right to distribute it separately any which way you want. You wrote it, you own the copyrights to it, and it is an independent work.

But when you distribute it in a way that is clearly tied to the GPLd kernel (and a binary module is just one such clear tie — a “patch” to build it or otherwise tie it to the kernel is also such a tie, even if you distribute it as source under some other license), you’re by definition not an independent work, any more.

Torvalds announced, however, that he would grant exceptions case by case, on the basis of his own idiosycratic judgments:

(But exactly because I’m not a black-and-white person, I reserve the right to make a balanced decision on any particular case. I have several times felt that the module author had a perfectly valid argument for why the “default assumption” of being derived wasn’t the case. That’s why things like the AFS module were accepted — but not liked — in the first place).

*      *      *

I’d just like to finish off with a few comments, just to clarify my personal stand:

I’m obviously not the only copyright holder of Linux, and I did so on purpose for several reasons. One reason is just because I hate the paperwork and other cr*p that goes along with copyright assignments.

Another is that I don’t much like copyright assignments at all: the author is the author, and he may be bound by my requirement for GPL, but that doesn’t mean that he should give his copyright to me.

A third reason, and the most relevant reason here, is that I want people to know that I cannot control the sources. I can write you a note to say that “for use XXX, I do not consider module YYY to be a derived work of my kernel”, but that would not really matter that much. Any other Linux copyright holder might still sue you.

I don’t really care about copyright law itself. What I care about is my own morals. Whether I’d ever sue somebody or not (and quite frankly, it’s the last thing I ever want to do — if I never end up talking to lawyers in a professional context, I’ll be perfectly happy. No disrespect intended.) will be entirely up to whether I consider what people do to me “moral” or not. Which is why intent matters to me a lot — both the intent of the person/corporation doing the infringement, and the intent of me and others in issues like the module export interface.

Another way of putting this: I don’t care about “legal loopholes” and word-wrangling.

This informal, ad hoc process doesn’t provide certainty for developers who are trying to make signficant technical and business decisions (and for the lawyers trying to advise them).   But, over the years, companies quietly developed their own practical strategies for dealing with the issue, and there were no GPL enforcement actions involving LKMs.

Recently, however, some comments by Alan Cox, a leading kernel developer, resurrected the issue.  On the LKML mailing list, there was discussion about the interaction of a proprietary, non-GPL driver with the GPL Linux kernel.  Cox made clear that he (and other kernel developers) took a different view from Torvalds:

The GPL covers *all* derivative works. EXPORT_SYMBOL doesn’t magically make code non-derivative. If you need to modify the kernel to make your driver work *and* you want to claim it is not derivative then I hope there are good lawyers involved

The kernel is GPL, all derived works of a GPL codebase are required to be GPL. There is no magic rule about modules. I’ve stated that repeatedly for anything containing a line of code I own. GregKH [Greg Kroah-Hartman, another leading kernel developer] has made it very clear for his code, and so it goes on.

(Given this, I can’t help but wonder about Cox’s view of the “scrubbed” Linux kernel headers in Bionic.)

What’s more, Cox apparently wants to preserve his ability to enforce his rights and seek multiple damages for willful infringement:

I’m a rights holder. . . . The code I provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the kernel be modified to match it) cannot call it. I’m recommended by my lawyer to always remind people of this when such a claim is made. It ensures that triple damages for wilful infringement will apply unless the other party can show it reviewed the situation carefully and its appropriately qualified legal staff reached a different conclusion.

It seems unlikely that Cox is seriously considering imminent legal action against companies distributing proprietary kernel modules, but his comments are a timely reminder that Linux kernel developers don’t speak with one voice.  And when his comments are read in their entirety, Cox seems to show particular frustration with the kind of wink-and-nod exceptions to the GPL that seem to happen.   In this he’s not alone.  As Eben Moglen has observed:

it would be very helpful if the kernel developers had decided to formalize the nature of their exceptions, and the Free Software Foundation and I have made a few attempts to discuss that matter with kernel developers. I had conversations with Ted Ts’o, I talked to Linus about it and I understood there were some reluctances to clarify, in a full and complete way, what was going on. There may have even been disagreements among kernel developers about that, I wouldn’t know. But I continue to think that it would be useful, for a whole variety of people who are trying in good faith to do the very best they can, and who may be navigating some dodgy legal territory, for them to be able to refer to something beyond the COPYING file which — with all due respect — I think probably doesn’t contain all the terms that are relevant to the use of the kernel.

Unfortunately, for the foreseeable future, many of us are left to navigate dodgy legal territory, relying only on blogs, mailing lists, and our wits. Blogs

If you’ve seen the apocalyptic articles on the tech news sites following the jury’s verdict on the copyright claim in Oracle v. Google, you may have already begun building an underground shelter and arming the kids against the impending zombie onslaught. But is it really the end of days for software? Not so much.

The Java language, platform, and APIs

Some of the clamor may be misinformation, but I think a lot of the confusion stems from the imprecise use of terminology, partly because Java is both a programming language and a platform. So let’s start by getting the details right.

The Java programming language was created by Sun (now Oracle) and designed specifically to be able to run on as many hardware and software environments as possible. The Java language has been made available under the General Public License, a free software license.

Programs written in the Java language run on the Java platform, which is a software environment that runs on top of other hardware-based environments (e.g., it runs on Windows, Mac OS, Linux, etc.). The Java platform consists of the Java Virtual Machine and the Java Application Programming Interface (“API”). The Java Virtual Machine is the virtual (software-only) processor that runs programs written in the Java language. The Java API is a collection of prewritten software components called class libraries, that provide useful functions (such as networking, database, security, encryption, etc.). Developers writing programs in the Java language can “call to,” these components to use their functionality, and thus can avoid having to re-write this code themselves.

This prewritten code is organized into methods, each of which provides a specific function. The methods are grouped into classes (and subclasses), which are grouped into packages. These elements are interrelated in a complex way. Interfaces define the relationship between different classes that share common characteristics, for instance, and methods can use parameters that are defined in different classes. This is true even if the classes are in different packages.

Each class library has an accompanying specification. A specification (or “spec”) is the documentation that describes the pre-written code in the library. It describes the elements that make up the library, including the classes, the methods, the interfaces, exceptions (errors), parameters, and fields. The Java API specifications, in other words, lay out a detailed blueprint for the prewritten code, comprising hundreds of classes, methods, interfaces, parameters, and fields.

When it created Android, Google substantially copied the structure, sequence, and organization (“SSO”) of 37 Java API packages and specifications. It admitted this at trial. Google also admitted that the 37 Java API packages are sufficiently original to meet the requirements of the copyright law, and that its copying was more than de minimis. The jury – assuming that the API packages were protected by copyright, as it was instructed – found that Google infringed the copyrights in the API packages, and that Oracle did not lead Google to believe that copying the SSO of the 37 API packages was permitted.

After the jury decided that there was infringement of the software code in the API packages, a flurry of articles appeared, all echoing the notion that the verdict jeopardized a “long-held practice of API copyright exemption” and arguing that programming would be all but impossible if the API packages were allowed to be copyrighted. These claims have been repeated throughout the technology press, accompanied by dire warnings of doom, but neither stands up to any scrutiny under copyright law.

APIs have long been understood to be copyrightable

The first claim, that API packages have been regarded as subject to some kind of “exemption” from copyright law, is — not to put too fine a point on it – nonsense. Google made this argument last summer, but it did not identify a single case that held that API packages were unprotected by copyright. Judge Alsup rejected Google’s argument, ruling that the API packages are not categorically exempt from copyright protection. (Judge Alsup also ruled that individual method names alone cannot be protected by copyright, which is why the suggestion that there will be a “land rush” to copyright method names is just silly.)

Judge Alsup got it right. The Java API packages are, under copyright law, “literary works.” This category is broad, covering pretty much any written expression, whether on paper or electronically, including fiction, nonfiction, poetry, textbooks, reference works, directories, catalogs, advertising copy, compilations of information, and even databases. It was decided long ago that software source and object code are to be treated literary works. The only requirement is that the work must meet the copyright law’s low threshold for originality. (Remember that here Google admitted the originality of the Java API packages.)

I’ve been advising software companies on copyright law for more than 17 years. In my experience, software lawyers and developers routinely treat APIs as copyrightable and proprietary. Virtually every software license agreement declares that the software is copyrighted, and some of the best-drafted licenses I’ve seen specifically state that the APIs are copyrighted.

It’s not just me: this software attorney explains why software companies need API licenses to protect their IP. And most software developers follow this advice and provide access to their APIs subject to an API license agreement. Intel’s is here; eBay’s is here; Garmin’s is here; Yahoo’s are here; Twitter’s is here; VMware’s is here; Microsoft’s is here. The US Postal Service presents you with a 33-page document if you want to use their address mapping API. All of these companies (and many more than I can list) believe that their APIs are protected by copyright, and they make them available precisely because copyright gives them protection.

In the financial services industry in particular, proprietary APIs for high-performance electronic trading are commonplace. The idea that these proprietary APIs, developed at great expense, are not protected by copyright and can be freely copied would be regarded as heresy.

And Oracle’s assertion of copyright in its Java API packages is hardly groundbreaking. In the 1990s, for example, 3Dfx Interactive aggressively asserted its copyrights against others who distributed utilities that sought to emulate its proprietary Glide 3D graphics API.

Copyright is critical to free and open computing

It’s true that some APIs are made freely available, either on a royalty-free basis or under a FOSS license. Even when APIs are made available under a liberal open source license, such as OpenGL (a cross-platform 3D graphics API licensed under various open source and commercial licenses) and OpenMP (a widely used API for parallel shared-memory, multiprocessing programming), copyright is asserted in the API.

Indeed, copyright ability isn’t a threat to open computing. It’s essential to it. Open source licensing of APIs or code works precisely because copyright applies to the API or code and allows the copyright owner to impose the terms and conditions of the open source license. Richard Stallman explains this better than anyone in his famous essay on copyleft:

The simplest way to make a program free software is to put it in the public domain, uncopyrighted. This allows people to share the program and their improvements, if they are so minded. But it also allows uncooperative people to convert the program into proprietary software. They can make changes, many or few, and distribute the result as a proprietary product. People who receive the program in that modified form do not have the freedom that the original author gave them; the middleman has stripped it away.

In the GNU project, our aim is to give all users the freedom to redistribute and change GNU software. If middlemen could strip off the freedom, we might have many users, but those users would not have freedom. So instead of putting GNU software in the public domain, we “copyleft” it. Copyleft says that anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it. Copyleft guarantees that every user has freedom.

To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program’s code, or any program derived from it, but only if the distribution terms are unchanged. Thus, the code and the freedoms become legally inseparable.

Proprietary software developers use copyright to take away the users’ freedom; we use copyright to guarantee their freedom. That’s why we reverse the name, changing “copyright” into “copyleft.”

Copyleft is a way of using of the copyright on the program. It doesn’t mean abandoning the copyright; in fact, doing so would make copyleft impossible.

In a very real sense, then, we shouldn’t be at all worried about a ruling that the Java API packages are protected by copyright. Most of the industry (excepting Google, I guess) already has assumed this. But a ruling that APIs cannot be copyrighted would have serious implications, for both proprietary developers and the FOSS community alike.

Over the past twenty months, the case has inspired many gigabytes of commentary by journalists, bloggers, and interested bystanders.  At first, the discussion focused on the broad issues:  whether software patents were good or evil, the importance of competition in the mobile space, the value of an open source mobile platform.  The discussion became more granular as the case progressed – with detailed analyses of “the Lindholm Email,” for instance, and the subpoena served on the Apache project.  And through the trial, law and tech geeks could follow the liveblogs and Twitter feeds to get the minute-by-minute action.    Bloggers have assessed every witness, expounded on the importance of every question and answer, and have variously extolled and denounced the lawyers.

Trials being what they are, Oracle’s and Google’s cases are framed for jurors in familiar narratives:  Oracle tells the jury that Google built Android using Oracle’s property without permission; Google argues that it simply used the freely available Java language and APIs to build Android.

Oracle accuses Google of infringing its copyrights in the “compilable code” and “documentation” of two versions of Java 2 Standard Edition (J2SE): Version 1.4 and Version 5.0, and, more specifically 37 API packages from those two versions.  As defined by the court, the “compilable code” includes the method names, class names, declarations, definitions, parameters, organization, and implementation.  The “documentation” includes the specifications, the English language comments to the code, and all of the method names, declarations, definitions, parameters, and organization in the reference materials for programmers.

Oracle contends that Google copied the structure, sequence, and organization of the compilable code for the 37 API packages as a group.  Google does not dispute that the Android specifications for the 37 API packages at issue “have substantially the same selection, arrangement, and structure as the J2SE specifications.” Google denied that the material at issue is copyrightable, but Judge Alsup instructed the jury that the copyrights in question cover the structure, sequence, and organization of the compilable code.  Google also denies that the elements it has used are infringing, and claims that it made “fair use” of Oracle’s copyrighted material.  Those issues will go to the jury.

With regard to the names of files, packages, classes, and methods, Judge Alsup has instructed the jury that the names cannot be protected individually, on a standalone basis, but that they are necessarily part of the structure, sequence, and organization of the code, and to that extent are protected by copyright.

Oracle has also accused Google of copying the English-language comments from the Java code and reproduced them in the Android API documentation.  Google acknowledges similarities in the wording, but denies that it copied or infringed Oracle’s copyrights.  Google contends that the similarities are attributable to the fact that the Android APIs perform a function similar to those performed by the Java APIs, and also claims that its use was fair.

Oracle also accuses Google of copying verbatim 11 files of compilable code.  Google essentially does not deny copying, but insists that the copying was de minimis, and thus excused.

Yesterday, Judge Alsup sent the case to the jury.  The court has instructed the jury that to find infringement of the copyright in the API code, the Android code must be substantially similar to the Java code.  By contrast, to find infringement of the API documentation, the jury must find that the Android documentation is virtually identical to the Java documentation.

To make these determinations, and to determine whether Google’s copying was de minimis, the jury has been instructed to consider the “works as a whole.”  Oracle and Google have vigorously disputed what constitutes “the work as a whole.”  The court has now instructed the jury that “the work as a whole” should be measured against Oracle’s copyrighted work, not against all of Android.  The idea here is that an infringer accused of copying an excerpt from a book cannot avoid infringement by including the copied excerpt in a much larger work.  Further, for purposes of determining infringement of the API code and documentation, the work as a whole is not the entire work covered by the copyright registration – i.e., not all of J2SE – but is all of the 166 API packages in J2SE.  For purposes of determining whether Google infringed the copyright in the 11 files copied verbatim, however, the work as a whole is each individual file.  Oracle has the burden of proving that the copying was more than “de minimis,” that it was not “so meager and fragmentary compared to the work as a whole that the average audience would not recognize the appropriation.”

On its defenses of fair use and its claim that Oracle made the J2SE API code and documentation freely available to the public, Google bears the burden of proof.

The jury’s findings will be very important, but they won’t be the end of the story.  Judge Alsup has told the jury, for instance, that it must assume that Oracle owns the copyrights, but Google has filed a motion that challenges the effectiveness and scope of Oracle’s registration.  Judge Alsup has also told the jury that the structure, sequence, and organization of the API code is protected by copyright, but he has not made a final ruling on that issue.   Stay tuned for more on those legal issues. Blogs

Whether you agree or disagree with the ultimate decision, the reasoning is problematic both scientifically and legally.  From a scientific standpoint, what constitutes the effective dose of thiopurines for a particular individual is hardly a “law of nature” akin to the laws of thermodynamics, for instance.  It is, rather, a contingent, individually variable, and empirically determined statistical relationship.   It is also the kind of empirically discovered fact that has long been patentable:  it may be true that the correlation between thiopurine levels, therapeutic efficacy, and toxicity is a natural phenomenon, but so, too, is the fact that bacteria die in the presence of certain compounds, or that materials behave as semiconductors under certain conditions.  Virtually every useful technological advance involves the recognition and application of a natural phenomenon.

It’s this invocation of “law of nature” that makes the decision problematic from a legal standpoint as well.  The Court recognized that “all inventions at some level embody, use, reflect, rest upon, or apply laws of nature, natural phenomena, or abstract ideas.”  The label “law of nature” thus can be hung on many method patents to invalidate them, but the Court provides little concrete guidance for lower courts, lawyers, and businesses to know when to apply it.  We know that Prometheus’ method claims don’t satisfy the requirements of Section 101, but it’s not clear what diagnostic methods might be patent eligible.  The Court expressly declined to provide any guidance:  “We need not, and do not, now decide whether were the steps at issue here less conventional, these features of the claims would prove sufficient to invalidate them.”

The sky isn’t falling.  The Mayo v. Prometheus decision depends to a significant extent on the way that Prometheus’ claims were drafted, and I expect that skilled patent lawyers can write claims in a way that avoids the problems that Prometheus faced.  But the Court’s approach – applying a conclusory label like “law of nature” instead of applying a cogent analysis – is deeply flawed. Blogs

Groklaw suggested that Oracle engages in copyright misuse because of the way it licenses its Java specifications.  As best as I can tell from the public filings, Google hasn’t actually pursued this argument, but it intrigued me because I’ve run into this issue in nearly a dozen cases over the years; sometimes I’ve argued for a finding of copyright misuse, and other times I’ve defended against the claim.

Copyright misuse is not mentioned at all in the Copyright Act.  It’s a common law, judge-created doctrine that serves as a defense to copyright infringement.  It’s an “equitable defense,” a principle that courts invoke when they think that it’s fundamentally unfair to grant a party relief, even if strictly speaking they are entitled to it, because they’ve behaved in a way that’s oppressive or otherwise objectionable.

Framed in the most general terms, copyright misuse is “the use of the [copyright] to secure an exclusive right or limited monopoly not granted by the [Copyright] Office and which it is contrary to public policy to grant.”   Lasercomb America, Inc. v. Reynolds, 961 F.2d 211 (4th Cir. 1990).  At this level of abstraction, it may seem like the doctrine is simply some free-floating veto that judges can use to pick a winner.

But it isn’t.  Over the past twenty years there have been dozens of court decisions discussing copyright misuse.  Those decisions define what copyright misuse is, and, as importantly, what it’s not.

The cases that have found copyright misuse share a common feature:  the copyright owner grants a license to its copyrighted work on the condition that the licensee agrees not to develop a competing work.  This was precisely the situation in Lasercomb, the case that first recognized the doctrine of copyright misuse.  Lasercomb licensed complex tool-making software, on the condition that the licensee must not develop competing software for a period of 99 years.  Lasercomb’s copyright in the software gave it certain rights (the right to prohibit copying, modification, or distribution without permission) but the Copyright Act did not give it the right to prohibit the development of competitive works.  Thus, its attempt to prohibit competition was copyright misuse.

Other cases have similarly found copyright misuse when a copyright owner includes anticompetitive restrictions in license agreements.   For instance, the American Medical Association developed a copyrighted system of codes for identifying medical procedures (the “CPT”).  The AMA licensed the CPT to the federal government for use in connection with reimbursement decisions.  The AMA’s license of the CPT expressly prohibited the government from using any competing system and required the government to use the CPT in all programs whenever possible.  The Court of Appeals for the Ninth Circuit held that this was copyright misuse.  Practice Management Information Corp. v. American Medical Association, 121 F.3d 516 (9th Cir. 1997).

Given this case law, you’d think that most copyright owners would know not to include restrictions on the development of competitive works in their licenses.  In fact, they’re surprisingly common.  I’ve handled two cases that involved anticompetitive license terms that were virtually identical to the one condemned in Lasercomb.

But not every restriction in a copyright or software license agreement is copyright misuse.  In fact, just a few months ago, in Apple Inc. v. Psystar Corporation, the Court of Appeals for the Ninth Circuit held that it was not copyright misuse for Apple to license its software on the condition that it could be used only on Apple hardware.  This restriction, the court explained, was permissible because it did not prevent the licensee from developing competing software.

Oracle’s license for the Java API specifications expressly allow licensees to develop their own independent implementation of the specifications, and the license does not attempt at all to prevent licensees from developing competing specifications.  Groklaw apparently claims that Oracle has engaged in misuse because its license for the Java API specifications states that licensees will lose their license (and thus infringe Oracle’s copyright) if they breach the terms of the license.

This provision isn’t copyright misuse.  It’s standard in virtually every license:  a licensee gets the benefit of the license only if it is in compliance with and does not breach the license.  Google’s licenses for its various APIs, for instance, also condition the license on compliance with the terms.  Even the GPLv2 contains a provision (Section 4) that terminates the license automatically in the event of breach.

The Oracle v. Google case presents plenty of fascinating IP issues, but I don’t think copyright misuse is one of them. Blogs

A few weeks ago, Rob Landley sparked a firestorm of controversy within the FOSS community when he criticized the GPL enforcement campaigns conducted by the Software Freedom Law Center (SFLC) and Software Freedom Conservancy (SFC).  One of the principal developers of BusyBox and a lead plaintiff in some of the lawsuits involving that project, Landley declared that “GPLv2 BusyBox is legally speaking one of the most _dangerous_ pieces of software you can ship.” He announced a project, called Toybox, to rewrite BusyBox and release it under a more permissive, non-GPL license, to “stop BusyBox from being used as a bludgeon against the world at large.”

In the past few days, both Bradley Kuhn and Harald Welte have defended their enforcement programs. Kuhn and Welte are the biggest GPL cops on the beat: Kuhn heads up the SFC and previously worked with Landley on the BusyBox cases, while Welte, through his organization gpl-violations.org, is the primary GPL enforcer in Europe.

Kuhn and Welte vowed to continue their enforcement efforts.  Kuhn declared that he’s “going to keep enforcing [the GPL], until there are no developers left who want to enforce it.”  Welte warned that GPL enforcement actions will continue:

Let me conclude with a clear statement to anyone who thinks that by replacing Busybox with a non-GPL licensed project they can evade GPL enforcement: It will not work.  There are others out there enforcing the GPL.  Last but not least gpl-violations.org.  Despite the notoriously outdated webpage, we are still alive and kicking, churning down on the violation reports that we receive.

In fact, Welte called for increases in enforcement activity:

I think there are still far too many GPL violations out there, and we need to see more enforcement in order to get all the major players in their respective lines of business into compliance.

This isn’t all that surprising; Kuhn and Welte are passionate advocates of free software and unrelenting in their enforcement.  What was surprising to see the vehemence with which Welte and Kuhn attacked Landley, even suggesting that he’s been co-opted by “anticopyleft” forces.

For instance, Welte accused Landley of spreading FUD about the SFC’s enforcement tactics. According to Welte, the FSC assured him that they did not demand the right to review the code for new products prior to their release to ensure GPL compliance:

There also have been rumors about a requirement on submitting future source code releases to a compliance audit by the Conservancy.  According to SFC sources, there never was any such demand, and the rumors are likely spawned by some incorrect claims of a defendant in a court case, which ended up in the public record.  If there was such a requirement, I wouldn’t think it is just – at least not for a first-time non-intentional infringement case.

There are far more than mere “rumors” about this, however.  In the Best Buy case – which was a “first-time, non-intentional infringement case” – multiple witnesses provided sworn testimony that the FSC had in fact made those demands.  The SFC never contradicted this evidence or denied the assertions. To the contrary, the SFLC’s Compliance Guide notes compliance audits often are required: “Many copyright holders wish to monitor future compliance for some period of time after the violation.”

Kuhn, for his part, didn’t deny that the SFC demanded to audit or review future source releases. Rather, he accused Landley of engaging in an “anti-copyleft political ruse.”  According to Kuhn, Landley is just a “copyleft opponent” who used a “sophisticated political strategy” to exacerbate “minor strategy disagreements among those who do GPL enforcement.”  Anti-copylefters like Landley, Kuhn says, “just want to distract the debate away from the only policy question that matters: Is copyleft a good force in the world for software freedom?”

But that’s not fair at all.  Landley (and his colleague Tim Bird, and others who support the ToyBox effort) aren’t diverting attention away from the key policy question; they throw it into high relief. Their actions – rewriting GPL’d BusyBox under a non-copyleft permissive license – make clear that they think that copy left has not been a good force.  And their words explain why: because (in their view) the GPL creates too much uncertainty, which prevents GPL’d projects from being adopted commercially.  Landley even gives a specific example, describing how Cisco, to avoid the GPL risk, terminated all in-house Linux development, started looking at non-Linux embedded operating systems, and reassigned its former Linux developers to work on Windows.  Other recent data supports the idea that commercial open-source projects are increasingly turning away from the GPL in favor of non-copyleft permissive licenses.

Landley’s criticisms of the SFC/SFLC were pointed, to be sure, but by attacking him as an agent of anticopyleft forces, Kuhn missed the opportunity to convince us why copyleft – as actually practiced – is a force for good in the world. Blogs

A developer who owns copyrights on files in the Linux kernel and who is leading a project to port Android to the TouchPad sent a demand that HP provide the source code for the modified version of the kernel that is embedded in these units.  HP declined, on the ground that it didn’t authorize the shipment of devices with Android embedded.

HP apparently relented to these demands and released the source for the Android kernel and for some other GPL components that it had modified.  The developer says that HP “was kind enough” to release this code because it “supports the [FOSS] community.”  True enough, I suppose, but consider that HP relented only after receiving a demand letter from a law firm that was sent on his behalf.

The developer is not entirely satisfied, moreover, because HP apparently has not released the source for a proprietary WiFi driver, presumably because the source reveals confidential information about HP’s hardware.  There’s been a long running debate in the Linux community as to whether closed source drivers can link to the kernel without becoming subject to the GPL.  The developer insists that the driver at issue here is a derivative work that is subject to the GPL because it is linked against at least 10 kernel files with “GPL ONLY” symbols.  HP is said to be investigating this claim.  Stay tuned.

In the meantime, I observed earlier that this situation highlights just how important it is to manage the supply chain for complex hardware and software projects.  HP’s decision to provide the source here likely will establish a precedent, as a practical matter if not a legal one, that even unauthorized distributions of GPL’d code trigger source disclosure obligations. Blogs

I wrote about the BusyBox lawsuits a few months ago.  BusyBox itself is a lightweight set of utilities licensed under GPLv2 that is widely used in embedded Linux devices.  It’s been a vital tool in a GPL enforcement campaign by the Software Freedom Law Center (SFLC) and Software Freedom Conservancy (SFC).

Those enforcement demands and lawsuits generally involved consumer devices such as BluRay/DVD players, DVRs, and wireless routers.  The devices included Busybox, but the manufacturers or distributors of the devices (including Cisco, Verizon, Best Buy, and others) allegedly failed to provide the corresponding source code for Busybox.

Landley and his colleague Erik Andersen, represented by the SFLC/SFC, took the position that the failure to provide source code as required by GPLv2 (a) automatically terminated the licensees’ right to distribute GPLv2 code, and (b) could not be cured simply by providing the corresponding source after the fact, but required the licensees to obtain the express permission of the relevant copyright holders.  The SFLC/SFC and the copyright holders apparently demanded many concessions from the licensees before agreeing to reinstate the license, including the release of source code for a number of proprietary libraries and programs, as well as the right to review all of the code for new products prior to their release to ensure GPL compliance.

Busybox was critical to the SFLC/SFC’s strategy.  First, it was found in many consumer devices. Second, in many cases the companies targeted by the SFLC/SFC had simply manufactured or distributed products that included chips on which the BusyBox code had been embedded.  The targeted companies, therefore, had to obtain the corresponding BusyBox source code from their upstream chip supplier.  As a practical matter, it was generally difficult for these companies to obtain the right version of the code.  Taken together, these factors gave the SFLC/SFC tremendous leverage.

This is exactly why Landley says that “GPLv2 BusyBox is legally speaking one of the most _dangerous_ pieces of software you can ship.”  According to Landley, he initially became involved in the BusyBox lawsuits because he thought that they would improve the software:

when I thought that hooking up with a lawfirm to launch BusyBox license enforcement lawsuits would result in any code added to the BusyBox repository, THAT was naive. Zealots grabbed that and used it to inflict completely unrelated crap like “license compliance officers” sending reports to the Free Software Foundation (which WAS NOT INVOLVED, yet somehow managed to hijack this to further their own agenda).

Landley now believes that the lawsuits were a bad idea:

The BusyBox lawsuits are something I personally started.  They were a bad idea, they have done more harm than good (I have personal, firsthand experience with this), and it’s my responsibility to stop them.

On an engineering note, they never contributed a single line of code to BusyBox.  NOT ONE.  I thought they would, but they didn’t, so I stopped pursuing them.

Instead they were picked up by zealots to pursue a wider agenda that had NOTHING TO DO WITH MAKING BUSYBOX A BETTER PIECE OF SOFTWARE.  You yourself admit that this is what happened, and the idea of STOPPING this is exactly what you are objecting to.

I’m an engineer.  I respond to problems by writing code.

Zealots respond to problems by telling OTHER people what they “should” do, and freaking out when they don’t do it.

Landley explains that he wants to rewrite BusyBox under a non-GPL permissive license to “stop BusyBox from being used as a bludgeon against the world at large.”

The BusyBox license enforcement lawsuits were a HORRIBLE IDEA, I regret having started that ball rolling, I couldn’t stop it.  I can only render it irrelevant with fresh development.

But others, particularly Matt Garrett, have excoriated Landley, because they believe that creating a non-GPL alternative to BusyBox will make it easier for others to violate the GPL:

the reason for writing this replacement isn’t to avoid infringing Busybox’s license, as such, but to avoid Busybox being used as a tool to enforce the license of other GPLed code (primarily the Linux kernel). . . .

The problem of vendors wilfully violating the GPL isn’t one that can be solved by writing code.  People who own the copyright to bodies of BusyBox have chosen to enforce that copyright as part of a larger overall strategy to force vendors to release the source code to other GPLed works that they’re infringing.  They have the right to do that.  You’re choosing to work on a replacement for BusyBox in order to make it easier for people to avoid enforcement actions.  You also have the right to do that.  I think your approach results in us seeing a larger number of wilful GPL violations than would otherwise be the case, but it’s absolutely your choice.

For his part, Landley has little good to say about the SFLC/SFC:

I wrote up fairly extensive guidelines about what I did and did not consider infringement:

http://lists.busybox.net/pipermail/busybox/2008-October/033327.html

I.E. using vanilla unmodified code is not infringing, we just want your IMPROVEMENTS.  I did’nt care about forcing you to mirror source tarballs like the FSF did to Mepis, or exploiting crazy loopholes.  If you honestly haven’t got any code we’d want, there’s nothing in it for us.

The SFLC/SFC didn’t work that way.  They wanted settlement money so they could afford to file the next suit, and they used BusyBox to sue over OTHER software packages which is disingenuous.

So from my point of view, “Is your code vanilla unmodified BusyBox” could be answered “yes”.  From the SFLC’s point of view, the answer had to be accompanied with a $20k check and the right to go through your refrigerator looking for expired mattress tags.

I’m aware that you care deeply about the mattress tags, but you’re being a slimy weasel exploiting other people’s loopholes to get your way, and you’re upset that the loophole is closing.  You find it an INJUSTICE that the loophole may no longer be leverageable for unrelated purposes.

Both Landley and Garrett are passionate advocates for FOSS, but it’s evident that they view the problem from diametrically opposite perspectives.  Garrett sees GPL non-compliance as a serious problem that will be made bigger by the loss of BusyBox as a tool for enforcement.  Landley believes that the BusyBox litigation hurt the adoption of Linux and other GPL’d code.  Landley’s collaborator Tim Bird sums it all up soberly and succinctly:

Matthew correctly points out that the busybox litigators use busybox as a leverage for asking for more than just the busybox source.  I believe they do not have this right (either legally or morally).  It is this aspect of the situation that some companies find undesireable.  It represents a business risk that is beyond the value that busybox provides.

The intent of this project is not to shield GPL violators.  It is intended to prevent violation in the first place.  I view the need for this project with some sadness, as I myself have worked hard for many years to encourage GPL compliance.  I will continue to do so.

I think that reducing the legal uncertainty involved with using GPL software increases the likelihood of adoption and compliance.  This is in stark contrast to the direction that the SFC has taken with their re-compliance requirements.

What Matthew argues here is that the ends justify the means, in terms of GPL enforcement. I respectfully disagree.

Landley and Bird have framed the problem well, but they can’t solve it simply by rewriting BusyBox.  In his response to Landley, Bradley Kuhn declares that “I’m here to enforce the GPL,” and Garrett himself urges Linux kernel copyright holders to step into the breach left by Landley.  “The mushroom cloud of legal uncertainty” surrounding the GPL and the Linux kernel will continue. Blogs