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.

2018 Roundup on Open Source Licensing

Here is my list of the top developments in open source licensing in 2018.

  • Huge business exits.  Red Hat, GITHUB, Elastic, Mulesoft,
    Magento, Pivotal and Heptio all had big financial wins this year, proving the viability of open source businesses.
  • Microsoft joined OIN.  Microsoft joined the open source community and agreed to limit patent aggression.
  • GPL Cure Commitment.  Many companies hopped on the GPL cure commitment bandwagon, in the effort led by Red Hat.
  • Licensing paradigm shifts.  Redis, Elastic, Confluent, MongoDB, and other businesses adjusted their business and licensing models, largely in reaction to the explosion in cloud based services using their software.
  • OSS Capital! Obviously I am not neutral about this one, but a venture fund targeted to open source developers is off to a roaring start.

Thanks to everyone who read, reposted, re-tweeted and commented on my blog this year.  Have a happy (and free and open) new year!

Source Available Scorecard

The release of the Commons Clause in August 2018 created a flurry of debate and media attention.  Now that the dust has settled, here is a recap of how Commons Clause served as a bellwether of a licensing trend. The Commons Clause was an early iteration in a new wave of licensing called “source available” — an awkward term, but probably the most accurate and broadly used term at this time.

State of the Art

Here are examples of source available licenses being used today.(FN1)

In an effort to help standardize this category of software, in 2019 we started a project called the PolyForm Project, which offers a menu of peer-reviewed, publicly developed, plain language forms for the most popular kinds of license scopes, with limitations such as non-commercial, free trial, and non-competition. The first tranche of licenses was released over the course of the last year, and projects have begun to adopt them.

So in sum, this category — its awkward name notwithstanding — is alive and growing as we start into the 2020s.

Is this Open Source? No.

Much has been made about putative confusion created by the “source available” category. But source available licenses have been around for a long time; there just wasn’t a recognized term for them. People mainly just called them source code licenses. Any confusion with open source, such as it is, goes beyond the category of source available, and comes from the gulf between a layman’s view of open source, and a specialist’s view. That gulf has been around for decades.

For those who specialize in software licensing, “open source” has a specific meaning: meeting the Open Source Definition. That definition, as demonstrated by months of controversy over MongoDB’s SSPL,(FN1) is becoming ever more like a holy text than a working definition. It has not been updated in over 20 years, and the advent of new trends in computing, like cloud computing, have made it harder for even the most ardent pundits to interpret. (FN3) But even so, it is still concrete enough to distinguish between open source and source available.

The gulf in meaning is driven mainly by two qualities shared by both categories: whether the license is generally available at no royalty, and whether it is deployed in a frictionless manner.

What is a Scope Restriction?

Commons Clause is an example of a license scope restriction.  It was created as a “portmanteau” approach to apply a restriction side by side with an underlying open source software license grant (of the licensor’s choice).  The Open Source Definition does not allow scope restrictions (FN4), so two sets of terms taken together in this way are not open source.  Similarly, licenses like the Confluent Community License and the PolyForm licenses — and Creative Commons Non-Commercial — all have license scope restrictions. But unlike Commons Clause, they all were written from scratch, without incorporating the terms of an existing open source license.

The easiest way to understand a scope restriction is to look at the sister Free Software Definition, promulgated by the Free Software Foundation. It says, in an elegant and charmingly-numbered fashion.

A program is free software if the program’s users have the four essential freedoms: The freedom to run the program as you wish, for any purpose….

“Freedom Zero”

How could a license violate this freedom? Let me count the ways: field of use restrictions, user restrictions, server restrictions, enterprise restrictions, CPU restrictions, site restrictions, and all the other metrics that commercial software vendors use to tot up their license fees. Open source is blissfully free of not only these restrictions, but the compliance tooling necessary to avoid violating them.

Engineers and businesspersons frequently ask if there is an open source license that only allows non-commercial use, or doesn’t allow SaaS use, and the answers is no. Those are license restrictions, so they can’t be open source.

Free as in Free Beer

But the lay use of open source is sometimes broadened to mean any license that is free of charge. Anyone who has worked in the field of software licensing has seen this at work for many years. These days, in most financing, M&A, or even commercial software licensing deals, companies must disclose which open source software they are using. Almost every company answers this disclosure request by including everything it downloaded from the web for free. In fact, there is a lot of free-of-charge software licensed only in binary form that is not open source, or even source available. That category of software is often called freeware, and includes products like the Adobe PDF reader. But as Richard Stallman famously said, free software means free as in free speech, not as in free beer.

Frictionless Licensing

Sometime lay persons call software “open source” for a reason that has little to do with the actual license terms applied to the software. For example, I have heard many engineers call anything with a click-to-accept mechanism a “EULA.” That’s not accurate either, but it’s instructive to consider the root of both these misconceptions. Open source and proprietary software licenses are not only different in content, they use different delivery mechanisms.

One aspect of open source licensing that is often given short shrift is its lack of a click-to-accept mechanism. The Open Source Definition requires:

Distribution of License. The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

OSD Section 7.

In contrast, most end user licenses require each licensee to execute an assent mechanism, which is a way for the licensee to indicate its agreement with the terms of the license and form a license contract.

The reason limited licenses and open source licenses have historically worked differently is rooted in some slightly arcane software licensing law. As GPL2 says,

You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

GPL2 , Section 5

And this is the nutmeat of the legal issue. A license is a take-or-or-leave-it proposition. Either you accept the license, or you don’t. If you don’t, you can’t exercise the rights. If you do, you have to accept all the terms of the license. Note that the implicit acceptance of the license is triggered by “modifying or distributing” but not use. GPL2 section zero says that “Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted.” It is no coincidence that under US law, mere use of a program does not require a license. US copyright law says:

[I]t is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:
(1)that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner…

17 USC 117(a)

So, mere use does not require a license. Any attempt to limit use of a program, as opposed to copying, modification or distribution, would require the licensee to bargain away the right to take actions that do not require a license. That must be done by agreeing to a contract. Therefore, it has long been considered a best practice for commercial software vendors to restrict use with a click-to-accept mechanism. And that is why lay persons equate the click-to-accept mechanism with an end user license agreement, or EULA. EULAs are the most common kind of limited license, and those with which every user is familiar.

But today, deploying software is no longer a question of making one copy for use on one machine, which is what 17 USC 117 allows absent a license. Using software at scale in our cloud and container world requires making many copies. Section 117 was written to enable single-machine use. It it not carte blanche to deploy thousands of containers. And that’s why source available licensing works in “frictionless” style, when traditional EULAs don’t. Source available licenses are usually not mere end user licenses. They often grant rights to modify, redistribute, and copy at scale.

The State of Play Today

Source available is an emerging category of limited licenses, but it is probably stealing more territory from binary licensing than open source licensing. Open source and limited licenses have co-existed for many years. To understand how this works, we need to understand a few things about how the software business works.

  • Platform software. The trend toward source available is most prevalent among the kinds of software sometimes called platform software or middleware. It is no accident that so many of the splashy adoptions of source available licenses in 2019 took place in the database sector. Applications have always been dominated by proprietary licensing, and infrastructure has become dominated by open source. That’s because software in ubiquitous use, like infrastructure software, is usually most valuable when is it standardized, and the cost to develop it is shared by the industry. For infrastructure like the Linux kernel or Kubernetes, plenty of industry players are willing to collaborate to maintain this infrastructure, so they can leverage it for their businesses. Specialized applications at the top of the stack, in contrast, usually have a smaller audience, and need private funding to develop. Platform software is somewhere in between: more like applications in monetization, and more like open source in the need to deliver source code to enable compatibility and security.
  • Source code delivery expectations. One side effect of the success of open source software over the last 30 years is that users now strongly prefer to receive source code from vendors, and exercise their bargaining power to demand it. For a long time, there was a tension between a vendor’s unwillingness to provide source code, and a user’s desire to get it. During the 1990s, commercial vendors tended to deliver binary only software, backed up by a mechanism called a software escrow, from which the source code was released if the supplier failed to maintain the software: for example, if the vendor went bankrupt or retired the product. This was always an awkward model, and escrows were difficult to negotiate and even more difficult to use if the code was actually released. Today, source available licensing acknowledges the need to deliver source code, even for proprietary products.
  • Software security. Security of software has become a huge issue, and most technologists agree that security by obscurity doesn’t work. Transparent software is more secure, and most source-available licenses grant the right to modify, so licensees can fix security flaws quickly on their own, if necessary. So many customers care more about transparency of software than the right to modify or use it free of charge.
  • The true landscape is a mix. Source available licenses are often used as part of an overall model that includes some mix of open source, source-available, binary-only and SaaS parts. SaaS is not a license at all, and users get no access to the software. As computing moves to the cloud, source available elements provide what customers need in source code form, even if they are commercial products.

More About the Commons Clause

The Commons Clause was adopted by Redis Labs, Dgraph, Neo4j, and others in 2018 and early 2019. Today, it is not used much in the wild, but it did serve as a catalyst for discussion and adoption of source-available licenses. So, this section is mostly for historical interest.

An FAQ about the clause is here.  The Clause has been mis-characterized as a “non-commercial restriction” — in fact, it is a more lenient restriction, unlike CC-NC, or PolyForm Non-Commercial, which are in fact non-commercial restrictions.

In the highly political world of open source, the media responses to the Commons Clause were polarized. Here are some examples to give you a flavor of the controversy.

Note: I coordinated the drafting of Commons Clause and advised several clients on adopting it, and drafting forms of source available licenses, so I have kept the information here as neutral as possible while communicating the facts of this trend.  Any opinions expressed in this blog post or in the articles cited here should not be attributed to my clients, and I have not written this article on behalf of any client. 


(FN1) Many people discussing this trend put MongoDB in this category, but technically, it is not. It adopted the Server Side Public License, a modified form of Affero GPL3 with enhanced source code sharing requirements, which was the subject of a controversial submission to the Open Source Initiative. The SSPL does not contain license scope restrictions.

(FN2) Creative Commons Licenses are not software licenses; they are general copyright licenses, mostly applied to content like images, music, and video. But the lack of a suitable non-commercial software license caused many companies to adopt Creative Commons Non-Commerial for software. Let’s hope PolyForm Non-Commercial gives them a better option.

(FN3) At this point, the OSD runs the risk of devolving to an “I know it when I see it” standard; indeed, OSI has added a requirement for approval. The license must not only meet the OSD but also “guarantee software freedom” — without guidance on what that might mean.

(FN4) The planks of the Open Source Definition that prevent license scope restrictions are less pithy than Freedom Zero, but they make the point clear nonetheless. They are:

  • 5. No Discrimination Against Persons or Groups
  • 6. No Discrimination Against Fields of Endeavor
  • 8. License Must Not Be Specific to a Product
  • 10. License Must Be Technology-Neutral

Technology Licensing: A Primer — Fourth Edition

I have finally published the new edition of my tech licensing book.  It’s a great stocking stuffer…well, maybe not.  But this old favorite has been updated and revised and is available on Amazon.com.  The Kindle version will also be available soon.  Both now have a much more reasonable price point than the one set by my prior publisher.  

OpenSSL Moves to Apache 2.0 Software License

OpenSSL has completed a re-licensing effort, resulting in adoption of Apache 2.0.   The project announced this effort in 2015.  The project got permission from contributors via a CLA.

The OpenSSL/SSLeay license was a non-standard permissive license, which included attribution clauses of the kind deprecated in Apache 1.0, such as:

All advertising materials mentioning features or use of this software must display the following acknowledgment: "This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)"

and the mysterious statement:

The licence and distribution terms for any publically available version or derivative of this code cannot be changed.  i.e. this code cannot simply be copied and put under another distribution licence * [including the GNU Public Licence.]

This caused many to wonder whether the license was truly permissive.  Over the years, users (and reluctantly, their lawyers) accepted it as permissive, but not without some angst.

Kudos to the project for clarifying and harmonizing the license for this ubiquitous bit of software.