Don’t Miss the Open Core Summit, Sept. 19-20 at the Palace of Fine Arts, SF

What to learn about the business and licensing paradigm of the future? Come to the Open Core Summit, and hear from the top commercial open source companies in the industry. September 19th–20th, 2019 Palace of Fine Arts, San Francisco.

If you are an open source developer who wants to start a sustainable business, or a software procurement professional who wants to understand how open source vendors do business, or you are already in a successful open source business and want to share best practices, the Open Core Summit is a new opportunity to learn and connect.

Registration, speakers, and more information is here.

Musings on the Eternal Question of Patent Indemnities

If there is a heaven for technology licensing lawyers, it is a perfect place where patent indemnities don’t exist. I have been advised, by those who know me best, that I am not going there, and undoubtedly they are right. Where I go, presumably, I will spend eternity negotiating a patent indemnity in a dark, cramped conference room in an airport hotel — against a real estate lawyer.

Patent indemnities are fundamentally impossible to negotiate correctly. Accepting this truth is an important milestone in any licensing lawyer’s career. Asking what is “normal” or “right” in a patent indemnity negotiation is like asking the meaning of life. We can, and should, consider it. But we can’t ever truly know.

What to do about this eternal question is one of the one of the most common requests I get from clients, many of whom are experienced lawyers.  To analyze the question, it’s helpful to step back to consider why and how one allocates risk in an agreement, to begin with. In most contract provisions, both parties are trying to minimize uncertainty and risk. But indemnity provisions don’t limit risk, they just move it around.

Indemnities are therefore hard contract terms to negotiate; they are often the last bridge to cross in negotiating a deal. At that point in the deal, all the business people have left the conference room, or started answering their emails on their phones, or just expired of boredom. The IP lawyers must soldier on. Allocation of risk provisions like indemnities and liability limitations are difficult to negotiate because they are zero-sum games. One party wins and the other loses. Unlike the business terms of contracts, they don’t lend themselves to win-win outcomes.

Mindful of the difficulty of the task and the lack of a true answer, here are some comments that might help you deal with this eternal question.

He who calls the tune pays the piper. One oft-quoted theory of indemnities is that the party who can better control a risk should bear it. This is sensible on face. It creates the right incentives, and makes lots of sense for negotiating risk allocation for IP infringement like copyright and trade secret. But in fact, ability to control third party patent infringement risk is mostly theoretical. IP lawyers know this, but most other people don’t (nor should they be burdened with such horrific knowledge). You can infringe a patent without doing anything wrong, and without knowing you are doing anything wrong, and without any reasonable means to figure out whether you are doing anything wrong.

If you accept that the provider of technology is not in a position to control this risk, the parties should share the risk.  Depending on context, that usually means the licensor indemnifies up to a cap. If the counterparty in a negotiation does not understand how patent infringement works (i.e. that it can happen without a wrongful act) one needs to respectfully explain that.

Follow the Money. Another, sometimes simultaneously applied, theory is that the party that gets the money bears the risk.  Theoretically, the party getting money can take a risk-discounted reserve against its revenue to offset the cost of the indemnity. Under this rule, the vendor bears liability in commercial transactions, particularly where the volume of sales (and thus infringement damages) is correlated to revenue.

Buy Insurance.  This is the most economically efficient approach but rarely feasible, because there is little insurance available to defend patent claims that is not prohibitively expensive. If you could allocate liability for patent infringement by insuring against the claim, it would reduce the negotiation to a simple money discussion. This is another thing that happens in licensing heaven, I guess.

Vendor Bites the Bullet.  This applies mostly to commercial deals selling products. In reality, most vendors would not want their customer defending patent claims. Those claims are likely to be crucial to the vendor’s business. Out of self-defense, many vendors will undertake defense of their own products regardless of what their contracts say about indemnities.  Placing the onus on the customer can actually be risky for the vendor. There is material conflict of interest for customer to handle infringement claims; the customer will be too willing to settle, possibly for a small amount per units associated with the customer’s modest use. Patent plaintiffs find it easier to sustain claims and get damages if they have successful licenses under their belts. This sets a dangerous precedent for the vendor, whose heavier practice of the patent can add up to significant damages. Also, at least for legal fees (rather than damages), it is cheaper for a vendor to handle the claim than for a bunch of customers to form a defense group.

Rule One: Sue People With Money. There are a couple of other considerations to keep in mind, to prevent you from fighting to gain advantages that don’t really exist. Never forget that you can’t get blood from a stone.  A serious patent claim can bankrupt small vendors. As one of my clients said once, “I’ll agree to a liability cap of $10 million. I only have $1 million in capital. Hey, let’s make it $100 million!”

Don’t be an Ostrich. There is a subtler reality to keep in mind. Some lawyers on the vendor side negotiate as if, when they don’t agree to an indemnity, they don’t have any liability. That is usually not true. Patent plaintiffs can sue vendors directly for infringement that they induce in their customers, and in fact, its easier for plaintiffs to do that than to sue the customers. So, by offering an indemnity, a vendor is taking on only the marginal liability consisting of the difference between inducement damages and direct damages (and of course the related fees and costs). While that delta is not zero, it is not the entire patent infringement risk from the deal. Patent infringement risk is a price of doing business, and you can’t de-risk your business completely by sloughing off liability on your customers.

It’s Good to be the King. In actual practice, bargaining power almost always wins the patent indemnity argument, regardless of other facts.  If you represent a vendor, your client is either big enough (in relation to its customers) to set terms, or not. A small vendor probably has to bear unlimited liability. A bigger one can disclaim all the liability it wants. Lawyers can burn up a lot of time and political capital negotiating patent indemnities, but vendors will usually prioritize present income over contingent and later costs, and disregard their lawyers’ warnings of risk.  That may hurt the lawyer’s feelings, but it is usually economically rational. And by refusing to concede on indemnities you can actually kill a deal, which may not serve your client.

Beyond Good and Evil. The eternal question of patent indemnity is not a moral question.  It is a business question.  Indemnities are costly because bearing risk is costly, whether or not the risk actually matures to harm — which is why insurance companies charge money. Characterizing undertaking a patent indemnity (or refusing to do so) as moral right or wrong may be an amusing negotiating ploy, but it’s not a good way to solve the question. If you are a customer and want to guarantee you will not resolve the eternal question, you should cry “You ought to stand up for your product!” Preferably while banging on the table. If you are in a negotiation and someone does this to you, you might consider offering to make them a cup of soothing herb tea.

There is no Normal. Market positions on patent indemnities are all over the map. Whether it is an M&A deal, or a commercial deal, or something in between, the allocation of risk on patent infringement can range from zero to unlimited. Anyone who says (while pounding the table), “I have never in all my career seen anyone refuse to agree to X” (where X is whichever position along that spectrum one may choose) or (with a proper show of indignity) “All our business partners agree to these terms and how dare you not do that!” either is acting, or lying, or needs to get out more. Extra points if the person uttering these words has worked at the same company for decades and is drawing from an N of one.

YMMV. These principles don’t apply in all cases, of course.  A commercial sale of semiconductors is not the same as a patent license to settle litigation or public-public M&A deal. The facts matter, and drive the most common outcomes. One significant fact that gets overlooked is jurisdiction. If a patentee cannot get jurisdiction over one of the parties in your deal, to bring an infringement claim, the other party becomes a substitute target. In some contexts, vendors can reduce risk by doing freedom to operate studies or entering patent pools, and then feel more comfortable bearing risk. But these tactics are not always available or feasible.

Enjoy! I hope this helps you with the mental torture of negotiating patent indemnities, at least until you leave this mortal coil. After than, you will either be blissfully unconcerned — or I guess I’ll see you in the airport hotel conference room.

Polyform Project Publishes its First License Draft

I am thrilled to announce the first publication of the Polyform Project.
Our first license document was released for community comment this week. Please visit our new web site for details.

The web site will allow you to review the first draft and make suggestions on how to improve our license.

Polyform is a project to draft and make freely available plain-language source code licenses with limited rights. Polyform licenses will come in a few useful “flavors” that adopters can pick to suit their needs. There will be options like non-commercial, testing only, and others.

Until now, there has been no standardization of this kind of source code license, even though it has become increasingly common. This has resulted in confusing and overlapping licenses, which need to be analyzed one at a time. The objective of the Polyform Project is standardization and reduction of costs for developers and users.

Don’t Try to Fool a FULA: Ubiquiti’s Complaint is Dismissed

In 2018, a company called Ubiquiti Networks Inc. filed a 15-count lawsuit against a rival wireless networking company, Cambium Networks, Inc. The lawsuit claimed various wrongs due to Cambium selling hacking firmware that uses Ubiquiti’s devices as a launching point for Cambium’s own service. The claims were based on, among other things, alleged infringement of a “proprietary user interface,” “configuration code,” and “calibration code.”

Cambium’s competing software, called Elevate, and how it is used on Ubiquiti devices, is explained here. Whether using the software is “hacking” or mere compatibility is probably a matter of opinion.

Along with its product, Ubiquiti promulgated a “FULA” — Firmware User License Agreement — with various restrictions, including against using the firmware on any other device, or copying or modifying the firmware. But the user terms also stated that the product included open source software, including software under GPL.

Last week, an Illinois federal judge dismissed the complaint, saying “The disconnect between the broad claims articulated in the complaint, on the one hand, and Ubiquiti’s acknowledgement that the GPL and other open source software licenses limit its rights and therefore the scope of its claims, on the other, makes the scope of defendants’ allegedly unlawful conduct unintelligible.” The complaint included a creative list of claims including violation of RICO, the Computer Fraud and Abuse Act, the DMCA, and the Illinois Computer Crime Prevention Law — not to mention copyright infringement. The court dismissed the complaint as violating FRCP 8(a)(2), which requires a plaintiff to submit “a short and plain statement of the claim showing that the pleader is entitled to relief.”

Because the complaint was dismissed without prejudice, it can be clarified and re-filed.

Vendors promulgating customer terms and conditions that apply to products as a whole should be careful that those terms do not contradict the terms of licenses like GPL that apply to components of the product. Contradictions in terms might not only be a violation of copyleft licenses — which do not allow contradictory restrictions — but may also make it difficult to enforce the overall terms for other components of the product.

996 ICU and Ethos Licensing

Recently, software developer activists have begun to release software under source code licenses expounding ethical conditions. The latest example of this trend is the Anti-996 License, which imposes a condition to comply with labor laws. “996” refers to a practice of requiring workers to work 9am to 9pm, 6 days a week. The term “996 ICU” refers to working 996 hours at the expense of one’s health (ending up in the Intensive Care Unit of the hospital).

The GITHUB repository called “996 ICU” is a new creature, part web site landing page, part journalistic advocacy, part software. The GITHUB page exhorts adherents to:

  • Update this list with evidence to help every worker.
  • Add this badge to your project to support 996.ICU.
  • License your awesome projects with the Anti 996 License.
  • Add proposals to give advice about the development of 996.ICU.
  • Go home at 6 pm without feeling sorry.

Prior ethical licensing efforts have met with less sympathy. Examples include the “Good not Evil” license that applies to JSON, whose condition is largely ignored due to its vagueness, and the ill-fated anti-ICE license noted previously on this blog that was withdrawn within days of its release. But Anti-996 is much more professional than prior efforts. For one thing, the license is thoughtfully written. It is essentially the MIT license with two added provisions, both of which are written in a lawyerly style.

“The individual or the legal entity must strictly comply with all applicable laws, regulations, rules and standards of the jurisdiction relating to labor and employment where the individual is physically located or where the individual was born or naturalized; or where th legal entity is registered or is operating (whichever is stricter). In case that the jurisdiction has no such laws, regulations, rules and standards or its laws, regulations, rules and standards are unenforceable, the individual or the legal entity are required to comply with Core International Labor Standards.

“The individual or the legal entity shall not induce, suggest or force its employee(s), whether full-time or part-time, or its independent contractor(s), in any methods, to agree in oral or written form, to directly or indirectly restrict, weaken or relinquish his or her rights or remedies under such laws, regulations, rules and standards relating to labor and employment as mentioned above, no matter whether such written or oral agreements are enforceable under the laws of the said jurisdiction, nor shall such individual or the legal entity limit, in any methods, the rights of its employee(s) or independent contractor(s) from reporting or complaining to the copyright holder or relevant authorities monitoring the compliance of the license about its violation(s) of the said license.”

Notably, the license casts its requirements as license conditions instead of license exclusions, perhaps in an effort to bring it within the ambit of the Open Source Definition (OSD). However, Free Software Foundation was quick to categorize it as non-free. The conflict between ethos licenses and the OSD or Free Software Four Freedoms has not been widely discussed, but the arguments either note that ethos licenses restrict certain recipients (labor law violators) from exercising the license, or restrict certain uses of the software — both of which arguably violate the OSD.

Casting labor law compliance as a condition of the license also means the result of violating the condition might be limited to loss of license rights leading to resulting copyright remedies, rather than a breach of contract claim leading to damages for failure to adhere to law. So lawyers might question whether the license can net the most obvious desired result — compelling companies to stop violating labor laws. But the license has accomplished a significant objective already, which is to call attention to the workers’ complaints. Moreover, violation of labor laws would normally yield its own separate remedies.

In case you were wondering, the catchall in the first paragraph, Core International Labor Standards, apparently refers to the nine core international human rights instruments of the
, international standards promulgated by the United Nations on topics like human trafficking, rights of disabled persons, migrant worker rights, children’s rights, and women’s rights. Presumably local labor laws would be a much higher bar.

Anti-996 is probably not the last ethos license we will see, and if this trend continues,it may portend dispute about whether ethos licenses can be written to meet the OSD.

Meanwhile, I will do my part and do my best to go home at 6 p.m. without feeling sorry.

FINOS Releases Open Source License Compliance Handbook

The Fintech Open Source Foundation (FINOS) announced the initial release of the Open Source License Compliance Handbook, a resource of practical compliance information about the most common free and open source software licenses.

The Handbook is itself an open source project, available on Github. It consists of:

  1. Structured compliance data about open source licenses, stored in a simple YAML format for easy consumption by machines and lawyers alike (licensed CC By-SA 4.0),
  2. A Python script to compile the license entries and introductory material into an asciidoc-formatted markup document (licensed Apache 2.0), and
  3. Binaries” of the document in docx and PDF formats (as well as an intermediate DocBook version) (CC By-SA 4.0).

Congratulations to FINOS for preparing this excellent resource.

Blue Oak Council and the Permissive License List

I am writing to announce the launch of Blue Oak Council, a new effort in the art and science of software licensing. Blue Oak publishes materials to help everyone — developers, lawyers, and others — to better understand software licensing.  It will be our ongoing mission to provide clear, easy-to-use materials that are practical and freely available. We hope Blue Oak will be a home for many projects in the future. But today, we have released our first project, and I am excited to tell you about it.

Our first project is a list of permissive public software licenses.  That might be sound like a simple thing, but it’s both highly useful and not so easy to create.  There are countless variations of permissive licenses. We could not possibly include them all. But as a realistic start, we included all the permissive licenses on the OSI and SPDX lists. Then, we rated each license from gold to lead, based on criteria we developed, like clarity of drafting, simplicity, and practicality of conditions.  We published our results as a data package, as well.

To show the list “in action”, we also published some example provisions for contracts and grants, as well as an example corporate open source policy that “green lights” permissive licenses.  That policy is loosely based on one I have been using in my practice for years, but it was streamlined and improved for this purpose.

As a byproduct of working on the list, we found ourselves preparing a model permissive license, working backwards from the informal criteria we used to rank existing licenses. While that license began as a thought experiment and reference point, it is also free for anyone to use.

I am thrilled to see this project launched, but I want to emphasize that I am not alone in it. The process of sorting out the rankings and the model, among Kyle Mitchell, Luis Villa and me, was a great exercise in challenging our assumptions and learning from each other.

Blue Oak welcomes feedback, ideas for projects, but most important, we would love to welcome other lawyers into the fold, and to serve as a conduit and facilitator for more practical group projects that can help spread knowledge and advance the state of the art.

Open Source and the Eradication of Viruses

This blog post appeared elsewhere in 2013, but the link is now broken, so I revived it here.

It’s cold and flu season, and what better time to try to eliminate the “viruses” from open source software licensing?

Open source advocates can be pedantic about terminology, and flame wars about using the right words are tedious.  Many in the technology world are put off by wars of words, because they don’t think they are important.  But eradicating the word “viral” from discussions of open source licensing is long overdue, because this word has skewed and limited understanding of open source licensing principles.

I have heard several stories about how this term began to be associated with free software in general, or the GPL in particular, and I hesitate to repeat any of them because I can’t verify them.  But one thing is clear: when people in the technology business, particularly lawyers, want to describe a class of open source licenses, they often use the word “viral.”  Unfortunately, the word is not only inflammatory, it is inaccurate.  For lawyers, inflammatory is part of the game, but inaccuracy is a sin.

First, we need to know the right term.  There are options: free software, copyleft, reciprocal, hereditary.  I have always thought “hereditary” the most accurate, but it hasn’t caught on.  So, these days I suggest “copyleft.”  A copyleft license is one that requires, as a condition of distribution of software binaries (or in the case of licenses like AGPL, a lower threshold such as making them available via a network), that the distributor make the corresponding source code available under the same licensing terms.  A copyleft license “sticks” to the copyright of the software; no matter how many downstream distributions occur, the license terms stay the same.  To a lawyer, this is like an “easement” — an encumbrance that runs with title, no matter how many times the property is sold.  Copyleft licenses include GPL, LGPL, MPL, EPL, and a smattering of others.

Unfortunately, using the word “viral” to describe this concept is misleading, and leads to unnecessary fears.  In all the years I have been advising clients in this area of law, the single most significant misconception about copyleft licenses is due, I think, to the use of this word. 

Here is what companies worry about. In GPL discussions, combining GPL code with other code in a single program is often referred to as creating a “derivative work.”  That is because GPL says if there is any GPL code in a given program, all of the code in the program must be made available under GPL.  Anything else is a violation of GPL.  Companies, with visions of viruses dancing in their heads, worry that if GPL and proprietary code are combined into a single program, the GPL licensing terms “infect” the proprietary code, and the proprietary code is automatically licensed under GPL.  The author of the proprietary code then worries that it will be obligated to provide the source code to its own proprietary code.  This is a software company’s equivalent of unleashing the big scary monster that hides under the bed.

But this is simply not how copyleft works.

In fact, if a company were to combine GPL and proprietary code in a way that violates GPL, the result is that GPL has been violated — no more, no less.  What that means, legally, is that the author of the GPL code may have remedies for violation of GPL, and if the license is terminated as a result, remedies for unlicensed use of the GPL software.  Both of these, essentially, are copyright infringement claims.  The legal remedies for a copyright infringement claim are damages (money) and injunction (stop using the GPL code).

In fact, there is simply no legal mechanism for GPL “infecting” proprietary code and changing its licensing terms. For software to be licensed under a particular set of terms, the author has to take some action that reasonably leads a licensee to conclude that the licensor has chosen to offer the code under those terms.  In contrast, combining proprietary and GPL code in a single program in violation of GPL is a license incompatibility — meaning the two sets of terms conflict, and cannot be satisfied simultaneously. The better analogy for this kind of licensing incompatibility is a software bug, rather than a software virus.  Just think of the robot on the old TV show Lost in Space flailing his arms and saying “DOES NOT COMPUTE,” and you get the idea.

For the law geeks (me included), I should explain that I have long been on alert to find any formal legal underpinnings for the “virus” model.  The only ones I have found are Pickett v. Prince, 207 F. 3d 402 (7th Cir. 2000) and Anderson v. Stallone, 11 USPQ2D 1161 (C.D. Cal. 1989).  Both of these cases discuss the principle that an unauthorized derivative work is not entitled to copyright protection. 

But these cases both involve very different facts from your typical GPL compliance problem.  First, in each of these cases, the infringing derivative work arguably did not meet a threshold level of creativity necessary for legal protection. The law sets this threshold very low. Any self-respecting blob of proprietary code would easily meet this threshold. Second, in each of these cases, the putative owner of the infringing derivative work was trying to sue the author of the infringed underlying work — something that requires a fair amount of good-old-fashioned chutzpah. These facts cannot reasonably be extrapolated to the situation where the developer of a proprietary software module, which has been inappropriately combined with a GPL software module, tries to enforce its rights in the proprietary code standing alone, against a third party.  The analog would be where a proprietary developer takes a blob of GPL code, changes one line of it, then sues the GPL author for copyright infringement — which would be nonsense. In other words, this legal construct “does not compute.” 

So, let’s dispense with this idea once and for all.  Meanwhile, drink plenty of fluids, keep the tissues handy, wash your hands regularly, and we can win against the viruses.