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!

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.