Friday, September 30, 2016

React JS Licensing: Additional Patent Grant

I recently reviewed the license documentation applicable to the React JavaScript library. The library provides a web user-interface function allowing views for HTML data. Facebook maintains the library as a project on Github, and it offers licensing documentation for the library on that site.

I’m critical of the license approach used by Facebook for React for at least three reasons. More on that below. But since Facebook’s approach is unconventional, I first offer a brief explanation of the history and substance of that approach.

I. History and Structure of React Licensing.

All I know about React licensing is what I’ve seen on the Internet– notably, on
Initially, in May 2014, React.js was offered under the Apache License, v. 2.0.

In October 2014, Facebook changed its licensing and began to offer React.js under the BSD License. But, unusually, in addition to the BSD License, Facebook issued an addendum-like document titled “Additional Grant of Patent Rights” that gave an “additional” license to use the library under Facebook patents. Even more unusually, this Additional Grant of Patent Rights included a termination provision that stated, in part, that Facebook’s grant of patent license would terminate if the software licensee were to initiate or participate in certain patent infringement lawsuits, including, filing any patent lawsuit against Facebook or its affiliates.

Apparently in response to criticism, in April 2015 Facebook issued a second version of the Additional Grant of Patent Rights that softened the termination provision to say that the React software licensee would not lose its right to use the software under Facebook patents in the special case in which the licensee brings a patent lawsuit that is a counterclaim against Facebook or its affiliates that is unrelated to React.js. The second version of the Additional Grant of Patent Rights, in addition to the BSD license, is what governs use of React.js today.

II. Criticism

A. The Additional Grant of Patent Rights is Unnecessary.

It is unknown to me why Facebook issued an Additional Grant of Patent Rights in the first place. If Facebook was trying to make developers feel better by publishing an express patent license grant, then their effort was unnecessary. To the extent it created  complexity and questioning, it was misguided. True, the BSD License does not explicitly state that the licensee receives the right to use the licensed software under the licensor’s patents. But I’ve never heard any lawyer postulate that that document does not grant a license to fully exploit the licensed software under all of the licensor’s intellectual property. Anyone who pushes that view is thinking too hard.

Similarly, I’ve never heard of any BSD licensor claiming patent infringement for any use, distribution, or other exploitation of software it has offered under the BSD License. That would be very strange. Developers-licensees (or, more to the point, their lawyers) have traditionally been very confident that the BSD License does not leave room for a licensor to successfully sue under patents.
Facebook’s Additional Grant of Patent Rights does not add anything to the simple and heavily relied-upon BSD License.

B.  Facebook’s Licensing Language is (a bit) Inelegant.

I’ll say upfront that my second criticism of the Facebook Additional Grant of Patent Rights is pretty wonky. Perhaps I’ve written too many software licenses, but here it goes.
You will note that the Additional Grant of Patent Rights uses the defined term Necessary Claim, which it defines as follows:

A “Necessary Claim” is a claim of a patent owned by Facebook that is necessarily infringed by the Software standing alone.

The document then grants rights under only Necessary Claims.
The defined term “Necessary Claim” is, err, unnecessary to the purpose of the Additional Grant of Patent Rights. The document would be more economically, and thus more gracefully, written if it simply granted the right under all of Facebook’s patents to exploit  the software. Indeed, version 1 of the Additional Grant of Patent Rights did just this. 
Put another way, the Additional Grant of Patent Rights, although a patent license, is still only a software license.  There is ordinarily no reason to define the licensed patent claims in a software license grant because the behavior one wants to license is bounded by the software itself. Expert technology licensing practitioners will note that the “necessary claims” or “required claims” concept arose in the practice of granting patent rights to implement written technology specifications (not software), where it is more important to carefully bound the scope of patent claims under which permission is granted.

C.  This is Not Open Source Software.

Facebook touts React.js as open source software. But in my mind the license termination provision of the Additional Grant of Patent Rights takes the offering outside the realm of open source software.
The patent license offered in the Additional Grant of Patent Rights (v.2) is conditioned upon the licensee not bringing a patent infringement lawsuit against Facebook or its affiliates. Thus, the licensee pays a price to use the library. It is not a price paid with money. The price demanded by Facebook for use of the library is that the licensee refrain from exercising any of its patent rights against Facebook or its affiliates.

I could be missing something, but I have never seen any other software license use such a condition and also claim to be an open source license.

Importantly, one should note the breadth of the patent assertion condition used by Facebook. Facebook is not saying only that a licensee’s rights to use React will terminate if the licensee claims patent infringement by the React library itself. This more limited approach, in my mind, would not disqualify React licensing from open source status. An open source licensor may employ a non-assert condition if the spirit of that condition is to protect the integrity and promote the use of the licensed software. But that is not what Facebook did. Instead, it wants to terminate its license if it is sued by a React developer under any patent. Facebook is using its publication of React source code as leverage to win some protection against patent lawsuits generally. In my mind, this is too greedy an approach for Facebook to claim open source status.

I don’t know what the Open Source Initiative (OSI) has to say about the Facebook Additional Grant of Patent Rights (v.2), if anything. The OSI definition of open source may leave enough room for Facebook to validly claim open source status. But one would need to read the word “fee” in the first paragraph of that definition narrowly.

I’d like to hear from anyone who disagrees with me.  Corrections and differing views welcome!

Tuesday, September 9, 2014

Nguyen v. Barnes & Noble

Those interested in the validity and interpretation of electronically-formed contracts will take note of the opinion of the Ninth Circuit Court of Appeals in Nguyen v. Barnes & Noble.  In the case, the court interpreted, and then found unenforceable, a so-called "browse-wrap"  terms of service found on the website of national bookseller Barnes & Noble.

In August 2011, Barnes & Noble liquidated its inventory of discontinued Hewlett Packard Touchpads by advertising a "fire sale" on its website.  Kevin Nguyen acted quickly and purchased two of those Touchpads.  He received an email confirming the transaction.  The next day he received an email telling him that his order had been canceled. He sued Barnes & Noble in California on behalf of himself and a putative class of consumers whose orders had been canceled, alleging deceptive business practices.

Barnes & Noble moved to compel arbitration, as its website's Terms of Use included an arbitration clause. The Terms of Use also stated that the law of New York would apply.

The company's website included a hyperlink to its Terms of Use at the bottom corner of every page  (including the checkout process pages). This hyperlink sat alongside  various other hyperlinks. Thus, in this case, the Terms of Use were offered as a so-called "browse-wrap" agreement that did not require the user to manifest assent to the terms and conditions expressly. Instead, as Barnes & Noble argued, in this browse-wrap agreement each user gives his assent simply by using the website.

The court, applying New York law, found that Nguyen had no actual notice of the Terms of Use and was not required to affirmatively acknowledge those terms before completing his online purchase.  As such, the validity of the browse-wrap agreement turned on whether the Barnes & Noble website put a hypothetical reasonably prudent user on inquiry notice of the terms of the contract. The answer to this question depends upon the design and content of the website and the agreement webpage.

In this case, the Terms of Use hyperlink on the bottom of each page of the Barnes & Noble website, and "close proximity" to the site's checkout button, was not enough to put a reasonably prudent user on constructive notice of the terms of contract.

According to the court:

"Where a website makes its terms of use available via a conspicuous hyperlink on every page of the website but otherwise provides no notice to users nor prompts them to take any affirmative action to demonstrate assent, even close proximity of the hyperlink to relevant buttons users must click on—without more—is insufficient to give rise to constructive notice."
Lesson to web developers.


☐  Purchase.  By checking this box I agree to the Terms of Use.


☐  Purchase.  Check this box to complete your purchase.

Terms of Use

Saturday, February 22, 2014

New Domain

This blog is no longer hosted on blogger.  If you would like to read Robert's blog, please visit his website at


IPv4 Address Space Transfers

Robert Pierce recently assisted a North American client with an agreement for the purchase of more than 15,000 Internet addresses. The addresses are unused and valid on networks employing Internet Protocol version 4 (IPv4). They were originally assigned to the seller by a predecessor to the American Registry for Internet Numbers (ARIN). This open-market approach is a response to the shrinking pool of available  IPv4 addresses.

Internet Protocol version 4 (IPv4) routes most traffic on the Internet. IPv4 addresses are 32-bit (four-byte) addresses. This limits the total address space to only 4,294,967,296 (232) unique addresses. This must have seemed like a very large number of addresses in the early days of the Internet, but by the 1990s it was clear that the pool of available IPv4 address numbers would be exhausted. Exhaustion occurred in early 2011. As a result of this limitation, and for other reasons, IPv6 was developed. IPv6 is a 128-bit protocol that creates a vastly larger address pool.

The world is migrating to IPv6, but hosts that employ only that protocol cannot directly communicate with IPv4 hosts.  For the time being there is  a need for parties to acquire IPv4 addresses. This is done in private sales with the (conditional) blessing of the Internet registries, including ARIN.

ARIN makes resources and services available in order to facilitate the transfer of IPv4 addresses between organizations.  According to ARIN, IPv4 address space issued by ARIN or its predecessors may be transferred  to another organization only under two circumstances.  First, as a part of the acquisition of assets that use IPv4 addresses via a merger, asset acquisition, or similar transaction.  Second, an organization with unused IPv4 address space may release the space to a  recipient specified to ARIN who qualifies for it under ARIN policy. ARIN policy requires, among other things, that the recipient organization provide ARIN with evidence of its need for the addresses. More information about so-called Merger and Acquisition Transfers and Specified Recipient Transfers may be found at the ARIN website.

Any prudent buyer wishing to purchase unused IPv4 address space on the open market under ARIN’s Specified Recipient Transfer rubric should either obtain pre-approval from ARIN as a qualified recipient before entering into a purchase and sale agreement, or, alternatively, enter into a purchase and sale agreement with a closing (and payment) contingent upon receipt of such approval.

Thursday, July 18, 2013

Non-Disclosure Agreements and the Failure to Designate: Convolve v. Seagate

Earlier this month the Federal Circuit issued its opinion in Convolve, Inc., et al. v. Compaq Computer Corporation, et al.  Convolve sued Compaq and Seagate Technology for, among other things, misappropriation of trade secrets. In its ruling, the Federal Circuit affirmed an earlier district court dismissal of the misappropriation claim as it related to most of the information that Convolve argued was its trade secrets.

According to the opinion, during business meetings held in 1998 and 1999, Convolve verbally disclosed to defendants information that it argued included trade secrets. The meetings were held under a written Non-Disclosure Agreement (NDA) that called for a party who wished to disclose trade secrets to mark or otherwise designate the disclosed information as confidential. For example, if disclosed in writing, by stamping it “CONFIDENTIAL” or, if disclosed verbally, by following up the verbal disclosure with a separate letter identifying the information as confidential. Under the terms of the NDA, information that is marked or designated as confidential must then be kept secret by the receiving party. Conversely, the receiving party assumes no obligation of secrecy or non-use over information that is not marked or designated as confidential.

The Federal Circuit concurred with district court’s earlier finding of fact that Convolve had not designated as confidential the information it verbally disclosed during its meetings with the defendants. According to the court, after disclosure of the information and failure to designate it as confidential, the information immediately lost its legal status as trade secret. Convolve lost its ability to sue for misappropriation of that information.

In the most interesting portion of the opinion, the court held that Convolve lost its claim not only under California contract law, but also under the statutory framework of the California Uniform Trade Secrets Act (CUTSA). Both its breach of contract claim and its CUTSA claim hinge upon its satisfaction of the requirements of the NDA.

The opinion did not precisely address whether, or not, the information at issue remains classified as trade secret for purposes of later misappropriation claims against different parties. Arguably, the right to sue other parties also evaporated at the time of disclosure to Compaq and Seagate.

It is worth noting that the confidentiality designation language used in the Convolve-Seagate NDA is of a type commonly used in Silicon Valley practice. Lawyers write protective documents, often requiring process that is not, and realistically cannot be,  followed by business executives in the rough and tumble real world. That's the tension.

But the opinion of the court in the trade secret portion of the case is straightforward. When technology companies sign non-disclosure agreements that define the contours of their intellectual property in trade secrets, they need to be prepared to take the protective measures called for under those agreements. Failure to do so can lead to a loss of rights.

Thursday, May 2, 2013

Craigslist Rights Grab

On Monday a federal district court in California made a remarkable ruling in Craigslist Inc. v. 3Taps Inc., et al.  In the case, Craigslist sues three companies for allegedly harvesting and reproducing the contents of Craigslist's website. In sum, as alleged, these companies aggregate and republish Craigslist ads after "scraping" them off the Craigslist site. They then offer users the ability to search and access Craigslist postings in ways that Craigslist itself does not allow. For example, a way to search Craigslist sites in multiple cities at the same time. Craigslist alleges multiple causes of action, including trespass, breach of contract, copyright infringement, trademark infringement, and violation of the federal Computer Fraud and Abuse Act (CFAA).

In his ruling, District Judge Breyer allowed Craigslist's copyright claim to survive a motion to dismiss.  Defendants had argued that Craigslist had no standing to sue for infringement of copyright in user-created ads because those copyrights are neither owned nor exclusively licensed by Craigslist. According to the defendants, because the ads are generated by Craigslist users, they are owned by those users. As we all know, only the owner of an exclusive right under copyright is entitled to sue for infringement. A party may not assign the right to sue for infringement without also granting an exclusive license or ownership. Silvers v. Sony Pictures Entm't, Inc. 402 F3d 881, 889 (9th Cir. 2005) (en banc).  And  the grant of an exclusive license requires a writing. 17 U.S.C. 204(a).

Well, the court found a written grant of such an exclusive license in the Craigslist user terms as they existed from July 16, 2012 through August 8, 2012.

During the summer of 2012, Craigslist had included in its end-user ad-creation workflow a notice as follows:

"Clicking 'Continue' confirms that craigslist is the exclusive licensee of this content, with the exclusive right to enforce copyrights against anyone copying, republishing, distributing or preparing derivative works without its consent."

After some public criticism of this approach by folks like the Electronic Frontier Foundation, Craigslist removed this provision after three weeks. The EFF and other public commentators say that to include a transfer of ownership of copyright in website TOS is abusive of users. But, for a short time it was there and ads were created by users after agreeing to this grant of exclusive rights. Craigslist registered its copyrights in the ads created within the 3-week window and brought suit for infringement thereof.

All of this is remarkable for two reasons.

First, this is a case of a court validating a transfer of ownership of copyright made in a website's click-thru terms of use. It is fair to say that US courts have not yet entirely worked out what promises made by an website user in a click-thru agreement will be enforceable and which will fall into the category of unconscionable and therefore unenforceable. That process continues at the usual snail's pace. This ruling pushes the envelope in the direction of enforceability of what is, conceptually at least, a pretty heavy contractual provision.  The transfer of an exclusive intellectual property right.

Second, it is surprising that Craigslist, after backing away from the license provision as a result of public outcry from the EFF and other do-gooding digerati, relied upon this grant of rights in its litigation. Disappointing to some. Of course, Craigslist has no copyright case without pulling the provision out of its quiver. 

Thursday, April 4, 2013

Source Code Escrow Agreements

My clients include software developers who periodically ask for advice on whether to place source code assets into escrow. Occasionally, a software developer's customer will request that the source code version of a licensed product be placed into escrow. The deposited assets may be released if a certain event occurs, for example, the breach of an agreement by the developer or the developer's bankruptcy. Software developers sometimes feel compelled to satisfy their customers by making such deposits.

I have at least two pieces of advice to software developers facing a request for source code escrow.

1. Is an Escrow Arrangement Really Helpful?

Whenever escrow is suggested, both the would-be depositor (usually a software developer) and the would-be escrow beneficiary (usually the licensee of a product in binary format) should carefully consider the real-world need and the usefulness of escrow.

In my experience, the request for source code escrow by a customer is almost always ill-considered.  Typically, such a customer fears that if the developer of delivered object code stops supporting that code, the customer will no longer have a way to obtain bug fixes and other updates to the code. With this thinking, the customer concludes that it needs a way to access the source assets so it can do the work itself.

But how realistic is the belief that a customer will have the expertise and an understanding of the code necessary to make effective modifications, even if it had access to the source? Does the customer have the required manpower? Is the code so well documented that the customer's staff can pick it up and make effective changes? The answers are typically no. Granted, if a developer stops fixing and improving its software as agreed, this is a big problem for the customer. But, in my experience, it is usually not realistic to think that the problem can be solved by access to source code assets.

 2. Those Wacky Escrow Agreements. 

My second piece of advice to software developers who are considering the placement of their valuable source code into escrow is to pay attention to the typically atrocious contracts used by the major escrow agents.

A source code escrow agreement is a fairly simple beast. It is often posed as a three-party agreement among the (i)  depositing software developer, (ii) beneficiary customer-licensee, and (ii) escrow agent. The basic idea is that the software developer promises to deposit its source assets into escrow for safekeeping by the escrow agent. In turn, the escrow agent promises the developer that it will keep those assets confidential and safe until a permitted release, if any. Finally, the escrow agent makes a promise to the beneficiary that it will release the source code assets to the beneficiary upon the occurrence of one or more well-defined events.

Note that the central promise that the software developer depositor receives under an escrow agreement is the promise of confidentiality and safekeeping.

Importantly, and detrimentally to depositing software developers, you will find that in almost all escrow agreements offered by escrow agents, the escrow agent will seek to limit its liability for not keeping its promise to the depositing software developer. They are hoping that you will not look at the small print. But if you look  at the section concerning limitations of liability, you'll likely see that escrow agents hope to get away with limiting their liability to a very small amount. This severe limitation of liability has the real effect of destroying any meaningful promise of secrecy and protection of source assets.

A software developer that ultimately decides that it should or must deposit its code into escrow should fight hard against any limitation of the escrow agent's liability for failing to keep the code secret and protected. Secrecy and protection of valuable assets is what the escrow agent is being paid (handsomely) for.  It should not expect to win contractual limitations on its liability.