Microsoft Joins OIN

In a move that represents what may be the swan song of its formerly anti-Linux position, Microsoft announced on October 10, 2018 that it joined Open Invention Network.  The OIN Announcement is here.

Microsoft had previously taken a few steps to align itself more with open source communities, including joining the Linux Foundation, joining the License on Transfer Network, and joining the Red Hat-led GPL pledge (“We doubled down on this new approach when we stood with Red Hat and others to apply GPL v. 3 “cure” principles to GPL v. 2 code.”)

OIN is a patent pool relating to Linux — broadly defined to include many elements in the Linux stack.

Microsoft has historically been one of the few non-NPEs to exact patent royalties for Linux, and famously licenses patents for Android devices (which use the Linux kernel).  The prior linked article explains some of the history of Microsoft’s enforcement efforts, which were focused in part on the  FAT (File Allocation Table) patents.  However, news reports have been unclear on the exact effect that joining OIN will have on Microsoft’s Android patent license program.



Snippets and Stack Overflow

I recently came across an online discussion that mentioned this very interesting article, Usage and Attribution of Stack Overflow Code Snippets in GitHub Projects, by Sebastian Baltes, Stephan Diehl, is a study of certain licensing issues in Stack Overflow, a discussion site for software developers.  Stack Overflow applies the CC BY-SA 3.0 license, a copyleft license for content, to contributions, and there is an ongoing debate as to the suitability of those license terms.

The study analyzes the attribution of “non-trivial” Java code snippets to estimate rate of usage that did not comply with CC-BY-SA notice requirements. The study found that “at most 1.8% of all analyzed repositories containing code from SO used the code in a way compatible with CC BY-SA 3.0. Moreover, we estimate that at most a quarter of the copied code snippets from SO are attributed as required.”

It is a fascinating topic, and it is refreshing to find a practical and empirical analysis of a licensing issue.  (This article by Chaiyong Ragkhitwetsagul, Jens Krinke, and Rocco Oliveto also reports the results of surveys of Stack Overflow answerers and visitors to assess awareness to outdated code and software licenses.)

Those who do M&A deals and other open source compliance efforts know that the average code audit usually turns up a handful of these items.  While many so-called snippets are short and may not enjoy copyright protection, that legal conclusion can be challenging to make, and unsatisfying to the risk-averse.  To avoid uncertainty, buyers often want such snippets removed, resulting in additional engineering costs that are expended to manage small but non-zero legal risks.  It is in economic terms a tax on development activity.

A project to convert Stack Overflow code contributions to a permission license, MIT, died on the vine in 2016.  That is unfortunate.  Discussion boards would better serve their community by requiring contributors to apply permissive licenses — or even public domain dedications or licenses with no attribution requirements — to small code examples.  At least that should be the default choice.  It seems doubtful that most contributors care enough about any copyright they may have in code snippets to apply — or enforce — significant conditions on what they contribute.  Given the choice, they would probably be happy with permissive terms.  Moreover, many of the contributions are taken from other sources and contributed without attribution of upstream license terms, which may or may not be compatible with CC-SA.

OSS Capital

I am thrilled to announce the launch of OSS Capital, a new venture capital fund focusing on commercial open source companies.  I will be acting as a Portfolio Partner.  OSS Capital invests in OSS startup companies.  Open source software is the future, and I am honored to be a part of OSSC, helping companies with open source business and licensing strategy.

And for those of you who are wondering…I will be continuing my law practice as well.


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.