Ninth Circuit Affirms Thin Protection for Databases under Copyright

In Experian Information Solutions, Inc. v. Nationwide Marketing Services, Inc., No. 16-16987 (9th Cir. 2018), the Ninth Circuit affirmed the limited protection available for databases under copyright.

Plaintiff Experian Information Systems, Inc., created its ConsumerView Database, containing names and addresses of more than 250 million consumers.  This information was valuable, because marketers will pay significant fees for accurate pairings of names and addresses.  Experian expended significant efforts to collect the data from many sources, such as real estate deeds and warranty cards.  It also used both human and automated methods to maximize the reliability of the data.

Experian discovered the basis for its lawsuit when a broker tried to sell Experian its own data — at a low price — on behalf of defendant Natimark.  Experian sued for copyright infringement, and when that claim was dismissed, trade secret misappropriation.

Examining the issue of whether such data is protectable under copyright, particularly, given Experian’s significant effort to ensure the data was accurate, the Ninth Circuit held that the database was copyrightable as a compilation (disagreeing with the district court).  But it affirmed summary judgment dismissing the copyright claim because Experian did not show “bodily appropriation” of the work, in part because Natimark’s database was “materially smaller” than Experian’s.  However, it held that with proper efforts to keep the information confidential, Experian’s lists could be protected as trade secrets.  The court remanded on the trade secret issue only.

This case underscores one of the thorny doctrinal difficulties for “open data licensing.”  Data that is publicly available (and therefore not protected by any trade secret interest) has very limited copyright protection.  Absent a contract binding a recipient to limited use, it is hard to enforce a condition in a copyright license to data, because most uses other than wholesale copying would be non-infringing.  Recipients  can “engineer around” a thin copyright by supersetting, subsetting, or changing the data. Accordingly, licenses that attempt to apply a “copyleft” condition to “derivative works” of data have an even bigger challenge than corresponding software licenses.  Such conditions are premised on the power of copyright.  It is extremely difficult to tell whether one data set is “derivative” of another, and very difficult to preserve any copyright interest in the face of downstream modifications.


Open Source Project Closes as a Political Protest on Immigration, then Re-Opens

The Lerna project, a tool for managing JavaScript packages, previously licensed under MIT, recently (and briefly) added a statement purporting to revoke its license to “collaborators” with the US Immigration and Customs Enforcement (ICE).

At least one other contributor  protested by asking the project to remove all his contributions.  The license change was quickly retracted.

One of Lerna’s lead developers said in a comment, “All technology is political, open source is especially political. It would not exist if not for political reasons. Open sourcing something is in itself a political act.”

I’m not commenting here on whether it is right or wrong to apply license restrictions based on ethical or political views.  It’s not generally unlawful to set whatever license restrictions you want, with a few limitations as to enforceability.  It’s not the first time that has happened — the do-no-evil license of JSON (“The Software shall be used for Good, not Evil.”) is ubiquitous and widely tolerated.  And strange license conditions, like the Chicken Dance License, have cropped up periodically.

But color me impressed: if you wanted a lesson on how not to draft or release a license restriction, this would be it.  I think this gets the prize for most drafting mistakes in the least number of words.

  • The phrase “shall not be granted” ought to make any licensing lawyer wince.  Does this mean that the license was never granted?  That is won’t be granted by the licensor(s) in the future?  That a licensee must not grant it?  (Just joking — there’s no sublicensing in open source.)  The passive voice is a dangerous drafting technique.  Perhaps it’s use here was a stylistic homage to the passive-voice MIT license itself:  “Permission is hereby granted…” But seriously, the problem with passive voice is that it doesn’t identify the subject of the grant or covenant.  At least the MIT license says “hereby granted,” indicating that the grant is made immediately.  Unfortunately, there is case law saying that a covenant to grant (“shall grant”) is not a present grant of license, merely a promise to grant (or in this case, not to grant) later — and knowing the difference is one of the tricks of the licensing trade.
  • The copyright notice suffers from a common and unfortunate tendency of open source authors to apply notices that are so ambiguous and generic that they no longer constitute a notice of anything.  No specific date.  No specific owner.   The purpose of a copyright notice — assuming there is any remaining material purpose under current law — is to put the reader on notice of when the work was published and who claims the copyright.  If you can’t say either, it’s best to omit a notice.
  • What does it mean to “collaborate” with one’s own government?  If a company is on the list but did not actually “collaborate” would this limitation still be effective?  What if that collaboration is required by law?  Would this only apply to companies that collaborated beyond the requirements of law?  If not, is a license restriction that requires one to violate the law by, say, refusing a government subpoena or order, actually enforceable?
  • Defined term “ICE” is never used.  Just saying.

Laying aside pure drafting concerns, the re-licensing effort was criticized by developers for being done in the wrong way, at the wrong time in the development cycle.  There is an interesting practical discussion on license change and versioning here.

The request of the contributor to remove contributions is also interesting.  Presumably, any previous contributor to the project contributed under MIT (or less likely, another permissive set of terms).  So as a baseline, such a contributor has no legal right under copyright to revoke his license.  But perhaps the issue was that this new licensing statement purports to set terms on behalf of all “Lerna Contributors”?  At least, it claims a joint (?) copyright by all the contributors.  (Heaven help them if they try enforcing copyright terms imposed by a joint authorship team, one of which has left the fold.)  Of course, any contributor can ask for his contributions to be removed on personal grounds, but if the contributions have been placed under MIT before, they couldn’t be removed on copyright grounds.

Below is the text of the restriction, which I have reproduced here before it disappears from the web entirely:

Copyright (c) 2015-present Lerna Contributors

The following license shall not be granted to the following entities or any subsidiary thereof due to their collaboration with US Immigration and Customs Enforcement (“ICE”):

– “Microsoft Corporation”

– “Palantir Technologies”

– “, Inc.”

– “Northeastern University”

– “Ernst & Young”

– “Thomson Reuters”

– “Motorola Solutions”

– “Deloitte Consulting LLP”

– “Johns Hopkins University”

– “Dell Inc”

– “Xerox Corporation”

– “Canon Inc”

– “Vermont State Colleges”

– “Charter Communications”

– “LinkedIn Corporation”

– “United Parcel Service Co”

A note: I know there has been a furor over Commons Clause lately, and I will post more about that eventually, as soon as I catch up.  Some have suggested that the release of Commons Clause encouraged the Lerna project action.  As far as I know they are unrelated, and it seems to me highly unlikely that the Lerna project was taking cues from Commons Clause.




UC Releases Guidance on Open Source Licensing

University of California recently issued guidance on open source licensing, and provided resources on understanding open source licenses, particularly with a view to informing professors and other UC personnel about the process of releasing open source code developed at the university or using university resources.

Kudos to UC for doing this (go, Bears) — more university offices of technology licensing need to understand the open source paradigm and how it benefits their professors, students and staff.  Historically, universities have been laser focused on patents, and so there is a spectrum of sophistication among universities on software copyright alone, not to mention open source licensing.

These materials should be helpful to professors who — during or after their time in academia — want to start companies leveraging software and other technology developed at the university.  That can be a bit of a puzzle, as the rights of the university, the individual professor, and a newly formed company need to be sorted into buckets, and sometimes licensed from the university.  (If you want to know more about university technology transfer generally, see this article.)

The UC system promulgates some policies system-wide, and there are also policies for each campus.

(Thanks to Angus MacDonald, Senior Counsel, Intellectual Property at University of California for the heads-up on this information.)

The guidance below also provides information on common open source licenses and various UC IP policies.


More GPL Cure Period Commitments

Fourteen more companies, including Amazon, ARM, Intel, MariaDB, Pivotal and VMware — have joined in the Red Hat-led GPL Cooperation Commitment, a cure period pledge for violations of GPL and LGPL version 2 licenses, bringing the total number of pledging companies to 24.  The pledges now represent 39 percent of corporate contributions to the Linux kernel and six of the top 10 corporate contributors.  Red Hat has also invited individual Linux contributors to join.

There is a GitHub page with more information about the GPL Cooperation Commitment and instructions on how to join.

See my prior posts here and here.