Good and not Evil: the Advent of Ethos Licensing

For years, my clients have asked me what to do about the “Good not Evil” license, which is most famously applied to JSON (JavaScript Object Notation), a widely used format for storing and transporting data between servers and web pages.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. The Software shall be used for Good, not Evil.

https://www.json.org/license.html

A reader could be forgiven for missing the problem in that clause. That license is essentially a conventional MIT-type license until its last line: The Software shall be used for Good, not Evil. *

This license is widely understood to violate the open source definition. The FSF’s page “Various Licenses and Comments about Them” makes this comment about the JSON license: “This is a restriction on usage and thus conflicts with freedom 0. The restriction might be unenforceable, but we cannot presume that.”

FSF’s comments represent the prevailing view about a class of licenses that might be called ethos licenses. They are open source licenses, overlaid with restrictions or conditions that are intended to change licensee behavior according to the licensor’s political beliefs. Freedom Zero, the most important quality of free software licenses, is “The freedom to run the program as you wish, for any purpose.” Its analog in the Open Source Definition straddles a few of the elements of the definition, such as “No Discrimination Against Fields of Endeavor.”

Nevertheless, the JSON license has resulted in little practical controversy, because most users could convince themselves that they were not engaged in evil activities.

More Ethos Licensing

In the last couple of years, there has been a spate of new ethos licenses. They have ranged from DIY “crayon licenses” (the pejorative term used to refer to licenses drafted without benefit of any professional license drafting experience) to sophisticated attempts to be open source licenses or something like them. Here is a list of the ethos licenses that have received the most attention.

  • Anti-996 License. A professionally drafted license with its own GITHUB discussion page, Anti-996 was intended to address working conditions for software engineers and others by requiring licensees to adhere to local labor laws, or at a minimum, the UN “Core International Labor Standards” which include prohibitions against human trafficking. “996” refers to a working day of nine a.m. to nine p.m., six days per week. This license remains the most professional and serious ethos license out there.
  • Anti-ICE License. A “crayon license” that was issued and quickly withdrawn, this license purported to withdraw permission to use the software to any organization that contracted with US Immigration and Customs Enforcement.
  • Hippocratic License. This license requires the licensee to use the software to do “No Harm: The software may not be used by anyone for systems or activities that actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of other individuals or groups, in violation of the United Nations Universal Declaration of Human Rights.” It clearly violates Freedom Zero.
  • Vaccine License. This license was professionally written, addresses the needs for vaccination and an implied disdain for the anti-vax movement. It was submitted to OSI in October, 2019, resulting in a fair amount of discussion on the OSI discussion lists, but its chances for approval are probably nil. The license was submitted under the name Filli Liberandum, which roughly translates as “free the children.” The anonymity of the submission caused as much controversy as its content, and some have posted that it was submitted to test OSI’s appetite for ethos licenses.

The Arcane but Crucial Difference between Restrictions and Conditions

Comparing the Anti-996 License and the ICE License illustrates some of the controversy over ethos licensing and the OSD. Of the licenses listed listed above, Anti-996 comes the closest to meeting the open source definition. It is a thoughtfully drafted document, and its authors include a WIKI explaining some of their drafting choices. Its development team says it is “designed to be compatible with all major open source licenses.” The conditions of the license say:

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 ….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.

While this is properly written as a condition rather than a restriction, the license is thought by some not to be OSD compliant, perhaps because the conditions do not relate to the use of the software or the exercise of the copyright. The license was never submitted to OSI for approval, so the isuse of its OSI compliance was never examined in detail. Moreover, this license is clearly not compatible with GPL, because it imposes conditions that are not in GPL, and GPL expressly prohibits imposing additional conditions.

In contrast, the ICE license prohibited use by any organization that contracted with US Immigration and Customs Enforcement and specifically banned 16 organizations, including Microsoft, Palantir, Amazon, Northeastern University, Johns Hopkins University, Dell, Xerox, LinkedIn, and UPS. The project to which the license was applied, Lerna, had not been implemented by all of these companies. The license has been withdrawn but its pull request for the project is here. This prohibition was a clear violation of Freedom Zero. The prohibition had been applied by one of the developers of the project, apparently without the consensus of other developers of the project, but with the approval of the core maintainer, who later stated:

Despite the most noble of intentions, it is clear to me now that the impact of this change was almost 100% negative, with no appreciable progress toward the ostensible goal aside from rancorous sniping and harmful drama….I am reverting the license changes. In the future, such changes (if any) will go through a much more thorough, completely public, and fair-minded process.

The project withdrew the modified terms and kicked the developer out of the project for various conduct violations.

Access vs. Licensing

But licensing is not the only tool in the developer/activist’s arsenal. Take, for example, the problem caused earlier this year in the Chef development product environment.

In September,2019, the developer of an open source Ruby library called Chef Sugar (a Ruby library useful for Chef) pulled his code down from his personal repository, where the code resided stating that “Chef was found to have entered into an agreement with US Immigrations and Customs Enforcement (ICE), best known for their inhumane treatment, denial of basic human rights, and detaining children in cages.” The code was developed while the developer worked at Chef, but resided in the developer’s person GITHUB repository; the developer had continued to maintain it after he moved to a different company. The takedown of the code resulted in broken links that disrupted the use of Chef in the field. Chef quickly restored the code to a different repository. The controversy continued, however, until Chef promised not to renew its contracts with ICE.

This disruption echoed an earlier takedown that “broke the internet” by removing a very simple white space padding routine (left-pad) on the popular NPM repository, a massive code development platform used to locate open source Javascript dependencies. Ironically, this disruption happened because of a trademark dispute between the developer and a company that asked him to rename a routine he had posted to NPM. The dispute became heated and profane, NPM joined in asking the developer to rename his routine, and the developer reacted by simply removing his code from NPM. (The dispute was characterized by the developer as a patent dispute, but that does not appear to be accurate.) The takedown included not only the routine that was the subject of the dispute (kik), but the 11-line left-pad. Suddenly, many software packages would no longer build properly. left-pad was a dependency — direct or indirect — for many software packages. The alternative package left-pad.io was created, and the issue was soon solved, but not before wreaking havoc for a day or two. The left-pad crisis was not an overtly political dispute, but it demonstrated that build chains are only as strong as their weakest link, and those links may be subject to the whims of developers, political or not.

What Works, and What Doesn’t

There is a war of ideology at work here. Free and open source software is built on the premise that use of software should be like free speech: without moral and political judgement that function like a prior restraint. Today’s developers, however, being just as politically polarized as the society at large, prefer to impose their ethical strictures upon others. While the two approaches are mutually exclusive, open source philosophy has already won. But a few things are clear.

First, ethos licensing inevitably results in a crazy quilt of incompatible, possibly unenforceable, and often vague restrictions. As a result, the most likely result is that no one will adopt software under such licenses. The administrative burden of ensuring compliance is significant, even if the user is morally upstanding. That adds to the already non-trivial cost of open source compliance, and most users will weigh the costs as heavier than the benefits of using the software. I have not yet had a client ask me whether it is compliant with the Hippocratic License, but I doubt any lawyer could responsibly answer that question.

Second, ethos licensing tends to focus on political issues that, by their nature, are ephemeral in the grand scheme of things. Even if one agrees that a company should not supply tools to ICE in 2019 because doing so facilitates inhumane treatment, what happens when ICE changes its policies? What if vaccinations become obsolete due to gene therapy? The license restrictions in ethos licenses may be a cure that outlives the disease — they will persist long after their justification is gone. Those who have tried to write open source licenses know how difficult it is to write terms that will work for the foreseeable future. Licensors may assume that, once conditions change, they can then re-state the license terms. But that is an assumption that only young people make. Unfortunately, licensors, too, are ephemeral, because we are all mortal. Developers who want to create a legacy with the fruits of their labor needs to think about the effect of their actions in the long term.

Third, ethos licensing is not an effective tool to control behavior. If ethos licenses impose license conditions, then the only real remedy for violating them is an injunction not to use the software. There is no legal mechanism to curb immoral behavior, nor compel good behavior, with a license condition.

Fourth, ethos licensing is ineffective in gross. What actually works best is good old-fashioned advocacy. For example, the Anti-996 License was as much an exercise in advocacy as in licencing, and it generated robust interest and discussion about working conditions. And the Chef/ICE issue had a real result, but not because of the takedown, which was ultimately toothless and at most mildly disruptive; it happened because of the concomitant advocacy, mostly by those in the community at large.

In short, ethos licensing is a publicity stunt. If we believe in free speech, then we must acknowledge that people can write whatever licenses they want in order to garner attention. But developers should not be so quick to trample Freedom Zero, which is an idea so powerful that it has fundamentally changed the world.

* Lexicographers might ponder why the terms “Good” and “Evil” are capitalized. If you think this does not matter, you are not a lawyer! Perhaps the author spoke German as a native language, or was referring to avatars of good and evil? But no, the capitalization is probably not the key to understanding this license.

A Chronicle of a Sad Time for Free Software: the Fall of RMS

I am ambivalent about writing this post, because it almost seems like piling on. But the recent scandal regarding Richard Stallman is such big news in the open source community that many people have asked me what happened. Also, some of the information is not persistent (for reasons explained below), so here is a summary for those who don’t follow the day-to-day developments (or can’t bear to read them). Also, the Stallman scandal demonstrates some of the themes I have written about previously here regarding changing community norms in open source licensing.

Richard Stallman (often referred to as RMS) is the prime mover behind the GPL, founded the Free Software Foundation, and founded the GNU project. He worked at the MIT artificial intelligence laboratory for many years and acts as an tireless spokesman for free software. He was also, famously, a prickly character, and could be callous in his interactions with others. To me it seems everyone has a Stallman story:

Nevertheless, he has been respected widely by the open source community for his vision and leadership, and for begetting the copyleft model, which is, and always will be, a brilliant judo move that uses the power of copyright law to make people share their copyrightable works.

Stallman has for many years espoused eclectic political views alongside his views on free software. His personal blog has never shied away from controversy, and even today, advocates Netflix shutting down, that US states form a union to collectively bargain with large corporations, and for a holiday called grav-mass (celebrating Isaac Newton’s birthday as an alternative to Christmas), to name a few. But it also contains many, more mainstream, electronic freedom positions against abuse of facial recognition, e-voting, and non-cash transactions.

Many of his personal political positions enjoyed sympathy, and he clearly separated his personal views from FSF or GNU. In September of this year, however, things went terribly wrong, causing the two to collide at the expense of both Stallman and the organizations with which we was affiliated.

September 7, 2019:

MIT Media Lab director Joi Ito resigned after criticism that he sought to conceal donations by financier and sex offender Jeffrey Epstein, including by marking them as anonymous.

September 12, 2019:

Stallman makes “catastrophically insensitive” statements in an MIT listserv post.

I think it is morally absurd to define “rape” in a way that depends on minor details such as which country it was in or whether the victim was 18 years old or 17. I think the existence of a dispute about that supports my point that the term “sexual assault” is slippery, so we ought to use more concrete terms when accusing anyone.

Richard Stallman

The same listserv string contains this rather prescient statement:

When this email chain inevitably finds its way into the press, the seeming insensitivity of some will reflect poorly on the entire community. Regardless of intent, this thread reads as grasping at straws to defend our friends around potential involvement with Epstein, and that isn’t a reputation I would like attached to my [CSAIL] affiliation.

(Author unclear from context of the string)

The email string was promptly published on Medium in a post calling for Stallman’s removal. The Medium article quotes another statement by Stallman, which was what eventually got the most press:

We can imagine many scenarios, but the most plausible scenario is that she presented herself to him as entirely willing…. Assuming she was being coerced by Epstein, he would have had every reason to tell her to conceal that from most of his associates. I’ve concluded from various examples of accusation inflation that it is absolutely wrong to use the term ‘sexual assault’ in an accusation.

It may be surprising to learn that the person who published the post, Selam G., did not know Stallman’s reputation when she first published about it. Her follow-on post about the fallout from her initial publication makes for interesting reading. But ironically, it may have taken someone who was not overawed by RMS to call out his comments at face value.

September 14, 2019: As this scandal unfolded, Stallman retracted a previous statement about pedophilia, one of his more unorthodox personal views.

Many years ago I posted that I could not see anything wrong about sex between an adult and a child, if the child accepted it. Through personal conversations in recent years, I’ve learned to understand how sex with a child can harm per psychologically. This changed my mind about the matter: I think adults should not do that. I am grateful for the conversations that enabled me to understand why.

September 15, 2019: Unsurprisingly, the fallout from his statements on the listserv was quick and far reaching. First, Stallman resigned from CSAIL.

I am resigning effective immediately from my position in CSAIL [Computer Science and Artificial Intelligence Laboratory] at MIT. I am doing this due to pressure on MIT and me over a series of misunderstandings and mischaracterizations.

September 17, 2019: After that, Stallman resigned as head of the Free Software Foundation, the non-profit organization he started in 1985. (Interestingly, the Wikipedia page for FSF is, as of October 14, 2019, silent on the Stallman scandal and resignation.)

September 29, 2019: Stallman’s web site stallman.org was hacked, then restored and moved. Some speculated that unauthorized changes were made by an FSF employee or one of the volunteers who update the site daily.

After this point, it became unclear whether Stallman was still the head of the GNU project, the main project of FSF.

28 September 2019: According to archives, Stallman wrote, “I hereby step down as head of the GNU Project, effective immediately.”

But it’s unclear whether this statement was legitimate or part of the suspected hack.

On October 7, 2019, 28 maintainers of the GNU project issued a joint statement saying “Stallman’s behavior over the years has undermined a core value of the GNU project: the empowerment of all computer users. GNU is not fulfilling its mission when the behavior of its leader alienates a large part of those we want to reach out to.”

On October 7, 2019, Stallman wrote:

I recently resigned as president of the FSF, but the FSF continues to provide several forms of crucial support for the GNU Project. As head of the GNU Project, I will be working with the FSF on how to structure the GNU Project’s relationship with the FSF in the future.

As of October 14, 2019, Stallman’s continued control of the GNU project is hard to handicap. The FSF is seeking a new president. Stallman’s unexpected departure may result in substantial change of direction for the organization, and some speculate that FSF will re-take the reins of enforcement activity that it has eschewed in the recent past.

This stream of events illustrates a few points worth considering.

  • Inclusiveness, diversity and community conduct are important ongoing issues in open source community stewardship. The last few years have seen a spate of blowups over codes of conduct and hateful behavior. The blunt and freewheeling exchanges that have been common in open source discussions are no longer viable now that open source has eaten the world. In this respect, open source is a victim of its own success; scrutiny of casual discussion within projects is now intense because so many more people pay attention.
  • The old guard is being phased out. The first generation of engineers, businesspersons, (and lawyers!) involved in open source are ageing, retiring, sometimes dying, sometimes faltering in their leadership, and need to pass the torch. Perhaps it’s no surprise when the views of the first generation sound retrograde. Open source was once known for the libertarian views of leaders like Stallman and Eric Raymond, but in an era of deep political division, those views are every more likely to generate conflict and discourage participation.
  • The popularity of the BDFL (benevolent dictator for life) paradigm may be fading. Many open source projects have been run for a long time by men with strong personalities and sharp tongues, who have a tendency to shout others down in the name of code quality or ideology. The cost of that behavior can’t be easily measured; people vote with their (virtual) feet or by staying silent when they otherwise might contribute. It’s notoriously hard to set standards for behavior that simultaneously promote excellence, candor and respect, but the social trend is toward greater emphasis on formalizing the rules of civil discussion.
  • The lines between personal and professional communication are breaking down. Everything we say online is persistent and public, and we will be held to account for it, for better or worse. Most of us already knew that. Any who think they are immune will eventually be unpleasantly surprised.

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
OHCHR
, 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.