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. 

Footnotes

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

How the Penguin Became a Benedictine Monk: Open Source and Codes of Community Conduct

Recently, a popular open source database project, SQLite, adopted a code of conduct for its participants.  Codes of conduct are not news — they have become increasingly common in open source communities in recent years.  But this one was different: the project adopted Rule IV of the Rule of Saint Benedict, written in the 6th century by Saint Benedict of Nursia, and still used as ethical precepts for the Benedictine order of monks.  Rule IV, Instruments of Good Works, contains such elements as “To do as one would be done by” — which is hard to argue with.  But it also contains elements like “To deny oneself that one may follow Christ” and “To be frequently occupied in prayer” — which were more controversial, and probably not applicable to code development.  Well, maybe prayer helps to find some of the more elusive bugs.

The actual reach of the code of conduct was limited.  The project consisted of only a few developers who all agreed on it, and it was in place for months before anyone objected.  The SQLite project said of the Rule:

This code of ethics has proven its mettle in thousands of diverse communities for over 1,500 years, and has served as a baseline for many civil law codes since the time of Charlemagne.

When the adoption of the Rule was publicized, the open source world wondered whether it was a prank, or perhaps merely a performance-art commentary on the recent spate of codes of conduct adopted in open source world.  After community complaints, the Rule was retracted and replaced with the more conventional Mozilla Community Guidelines. Although the SQLite developers’ hearts were probably in the right place, the Christian underpinnings of the code, and its original formulation for an exclusively male community, were a bridge too far. The project now styles it as a voluntary code of ethics for the founder only.

How did this happen?

#METOO and Volunteer Communities

In the United States, the #METOO movement recently shined a spotlight on tacit approval of sexual harassment across many sectors.  Private businesses have long employed codes of conduct to avoid harassment claims, but now the spotlight is on all organizations.  The open source development community, self-organized and ideologically resistant to central control, has slowly begun to adopt similar codes of conduct — but the road has been a zigzag path.  If managing an open source community is like herding cats, applying a code of conduct is like making cats take a loyalty oath.

Adopting codes of conduct has two related goals: elimination of bias and inclusiveness.  Elimination of bias is remediative — it seeks to give participants the opportunity to participate on a level playing field, by avoiding conduct that discourages participation.  Codes of conduct prohibit racist, sexist, or otherwise hateful speech or actions. Inclusiveness is proactive — it seeks to attract new participation in the community by persons in underrepresented groups.  The tools to achieve inclusiveness are, at this time, less consistently used.

In tackling these goals, the open source community slipstreams on best practices in private employment, which have been developing for quite some time.  Most private businesses today, for example, have express anti-harassment and policies and a process for reporting and assessing harassment claims. These policies were developed mostly as a response to employment-related legal claims under state and federal law arising from the existence of a “hostile work environment.”  Written policies are helpful to avoid liability and communicate business culture.  

Some businesses have taken proactive steps to promote inclusiveness.  An example is the “Rooney Rule” adopted by the NFL.   Businesses that seek to promote hiring or advancement of minorities or women tread a fine line, though — establishing quotas or preferences can expose them to claims of reverse discrimination.  See, for example, City of Richmond v. J. A. Croson Co., 488 U.S. 469 (1989).  Thus, most tools for inclusiveness avoid strict quotas or preferences.

Settling the Wild West

Those trying to civilize behavior in open source communities probably feel like Ransom Stoddard in The Man Who Shot Liberty Valance — an optimistic and naive lawyer treated with derision by the outlaws and heroes alike.  Behavior in an open source community is often analogized to the “wild west.” But in a sense, this wildness is the quintessence of open source: a private business is a cathedral and the open source community is a bazaar.  Open source communities usually develop without central control, and many participants chafe under even the most lightweight management.  Moreover, while private businesses can enforce their anti-harassment policies with the economic hammer of the threat of termination of employment, kicking participants out of voluntary communities is both rare and tricky to accomplish.

Some features (or, depending on your point of view, bugs) of the open source community tend to discourage newcomers.  For example, the anonymity and asynchronous nature of online communication can lead to aggressive behavior that participants might not undertake in face-to-face or real-time interactions.  Lack of inclusion can also arise from the mechanics of open source development. In open source projects, one or a few committers control what contributions are approved for inclusion in the software, and becoming one of these committers  is both a matter of high prestige, and dependent on personal reputation. New participants can have a hard time breaking in to a community that can seem cliquish and insular. Much open source work is voluntary and unpaid, and this introduces a Room of One’s Own factor — women and minorities with heavy workloads and child-rearing commitments may not have the resources or time to participate without pay in order to earn their stripes as contributors.

Sometimes, successful projects are unprepared for the need to manage the behavior of a large and disparate community.  One of the key functions of open source project management is to coordinate user and developer conferences. In geographically dispersed open source projects, participation in developer conferences, presentations and meetings is essential, not optional.  As with any conference that brings many people together, open source conferences can become a venue for harassment and hostile behavior.

Bias in the Open Source Community

Reported incidents of overt bias in the open source community have mostly focused on bias against women: Geekfeminism maintains a list of incidents.  

Blue Content.  Male open source developers have used sexualized or nude images of women in presentations, or even code or sample content.  While these incidents are not directed at a particular individual, they can create a culture that discourages participation by women, LBGT — or others who simply find it inappropriate.

  • Lena.  Use of a Playboy centerfold image in the development of image processing.
  • Perl playmate API lightning talk — a TED talk on a joke Perl module designed to download the measurements of Playboy magazine Playmates from the Playboy website.
  • Upskirt blogging post of candid “upskirt” photo posted on a personal blog and syndicated to Planet Fedora website.
  • Mark Pesce’s use of sexual images at official presentation at Linux Australia, which led to implementation of a code of conduct.

Harassment.  These incidents are directed at particular individuals.  They take place not only at in-person official community group meetings, but at associated social activities, or online.

  • Particular problems occur when the harasser is a core member of the community.  For example, Morgan Marquis-Boire, a cybersecurity expert, was alleged to have sexually assaulted several women.  Several organizations disassociated themselves with him as a result.

I’m Taking my Ball and Going Home.

In one of the more unusual developments arising from negative reaction to a Code of Conduct, a Linux kernel developer who claimed to be a lawyer said that those objecting to the new CoC could rescind the license to their contributions in protest. Which was, actually, not correct as a matter of law.

A Culture of Brutal Honesty, and Great Code

Codes of conduct sometimes seek to address baseline notions of civility, rather than overt bias.  Linus Torvalds is the original developer of the Linux kernel, and he remains the gatekeeper for the Linux kernel (making him arguably one of the most powerful human beings in the world, in practical terms).  But Torvalds is notoriously and cuttingly honest. He is well known for his profanity-laced posts to discussion groups and withering reactions to pull requests, but to be fair, most are in service of code quality and he is not known for sex or race bias.   Recently Torvalds took a hiatus and promised to get counseling.   He wrote:  

I am not an emotionally empathetic kind of person and that probably doesn’t come as a big surprise to anybody. Least of all me. The fact that I then misread people and don’t realize (for years) how badly I’ve judged a situation and contributed to an unprofessional environment is not good.  This week people in our community confronted me about my lifetime of not understanding emotions. My flippant attacks in emails have been both unprofessional and uncalled for. …I know now this was not OK and I am truly sorry….I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely….I am going to take time off and get some assistance on how to understand people’s emotions and respond appropriately.

But Torvalds is not alone.  At the risk of engaging in a cultural stereotype, coding can attract those for whom emotional intelligence is not a strong suit, at the least, or even those on the Autism spectrum.  For some, this is not a bug but a feature — those who struggle with interpersonal skills can find a haven in the pseudonymous, technical world of open source.  (This author included.)  But having poor social skills causes problems in a model of development that needs a robust community to thrive.

Best Practices

There is extensive legal writing on best practices to implement codes of conduct in private business: Have a written policy that is as concrete as possible, enforce it consistently, establish protocols for confidential reporting and assessment of claims, and try to do all this without stifling First Amendment protected expression.  Here are a few best practices that are more specific to open source communities.

    • Localization.  Open source communities are often international, so policies need to take into account local language and culture. A private business may be able to mandate communications in its home language, but volunteer communities cannot.  What should or should not be mentioned in a code of conduct may also be limited by local norms.
    • Self-Governance. Codes of conduct for open source communities need to be created by, or at least approved by, the members of the community. Some are also self-administered, but this can make confidential assessment of complaints challenging.
    • Conferences.  Community participants may interact with the project only, or for the first time, at conferences.  Codes of conduct should be promulgated at each conference, in addition to the more persistent public facing materials for the project.  Those submitting presentations should confirm adherence to the code of conduct. The code of conduct should cover all official and unofficial conference events and related online interactions.
    • Fighting the Echo Chamber.  Self-organized communities can tend to be insular.  Projects may wish to 360-degree accountability by ensuring important decisions are made by multiple stakeholders.
    • Using AI.  There are some technology tools to improve quality of conversations online.  AI can screen for both positive and negative communication and alert those running the project to problems before they get worse.

As the open source world struggles to get along — as the larger world does — codes of conduct will inevitably become more common.  But they will continue to be more difficult to enforce in open source communities than in private enterprise. 

Below are some resources for additional reading on bias, codes of conduct, and related topics.

Useful Links:

  • Sexism field guide.  This is a collection of tactics to deal with sexism on an immediate and daily basis.  They range greatly and therefore offer options that may suit different preferences for the level and nature of response.
  • Airbnb’s bias and discrimination toolkit

Some Codes of Conduct:

Thanks to Luis Villa of Tidelift and Katie Gosewehr of O’Melveny for their work preparing the analysis and research that formed the basis for this article. Credit only to them; any errors are mine alone.

 A presentation on this topic will be given at the PLI conference in San Francisco, Open Source Software 2018 — from Compliance to Cooperation, November 28, 2018, and will be eligible for MCLE credit on Elimination of Bias.  

Microsoft Joins OIN

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

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

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

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

 

 

Snippets and Stack Overflow

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

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

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

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

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

OSS Capital

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

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