Tag: ethics

Open Source Licenses and the Ethical Use of Software

Recently Coraline Ehmke announced a new software license, the Hippocratic License, a modified MIT License, amended “to limit the impact of the unethical use of open source software.” Coraline states that she intends to submit the license to the Open Source Initiative even though she acknowledges it does not meet their criteria for an open source license as outlined in the OSI’s Open Source Definition.

This new license comes on the heels of Seth Vargo pulling popular Chef packages he created and to which he still had access in order to protest Chef doing business with ICE. Chef recovered ownership of the code and rubygems namespace but nevertheless publicly committed to not renewing their contracts with ICE.

It’s great that folks want to do the right thing and are looking for ways to exercise their power to do so.

However, the Hippocratic License and the way Coraline is going about getting it recognized and adopted is a deeply misguided effort that will absorb the scarce resources of our community without yielding the results we want. The folks who think this is a good idea are possibly not as well-versed in the history of free and open source software and its basis in copyright law as they need to be in order to work effectively with the status quo to drive the outcomes they desire. If they were, I think they would understand that what’s needed are multiple coordinated efforts toward creating alternatives along side and with our existing ways of building, licensing, and distributing software.

Before I dive into why I think there are more effective strategies toward addressing ethical use of software, let’s review some necessary background information.

The origins of free and open source software (FOSS)

Software as intellectual property subject to copyright protection

To understand the origins of free and open source software you need to understand its legal foundations.

Software is a form of intellectual property (IP). The most common IP law that applies to software is copyright law, but patent law also applies and so do trademarks when you’re talking about a software’s brand, including logo and associated names.

In the early days of computing, software wasn’t really a thing in and of itself. It came with the computer hardware you bought and was generally what we would call today “open source.” That is, you could examine and modify the code. Lots of code and improvements to that code was shared among users of a given hardware platform. But then in the late 1960s the US federal government filed suit against IBM for antitrust violations. As a result, IBM unbundled their software from their hardware and the market for software was born.

While this was happening, the legal community was trying to figure out what kind of intellectual property law should apply to software. I won’t rehash all the details here, but it’s kinda fascinating if you’re into the topic so follow that link to Wikipedia and enjoy. For everybody else, what you need to know is that software is considered a literary work under the US Copyright Act. Copyright is implied for any given literary work, including software. You’ll often seen “Copyright so and so” on a work but such notices aren’t necessary in order for the creator of a work to legally own it. This is why you can’t just copy and use content you find on the Internet without knowing its provenance.

Once software was a thing with commercial value in and of itself, and once it was established that copyrights applied to it as if it were a literary work, end-user license agreements (EULAs) became a thing. Licenses are essentially contracts that say what people who use your software can and can’t use it for and under which conditions. Software producers started restricting access to the source code of the software they originated and started controlling its distribution.

Richard Stallman, the GNU project, and the start of free software

Around this time a computer scientist named Richard Stallman (RMS) was working at MIT. He did not like where things were going in the world of software. Specifically, he didn’t like that he had less and less access to the source code of programs he used and as such was no longer free to do whatever he wanted with them. Bizarrely, he was also against user passwords. But, if I go into RMS’s peculiarities we’ll be here all night.

Long story, short: Stallman fights against the scourge of “proprietary” software by starting the GNU Project, with the goal of creating a completely free (as in freedom) operating system. In order to preserve users’ freedom to do whatever they wanted with GNU software, Stallman utilized his power as its creator and copyright-holder to license GNU software with a new license, the GNU General Public License, known simply as GPL. The GPL is a considered a copyleft license, “copyleft” being another term that Stallman originated to differentiate his use from the typical ways copyright is applied. (Because “left” is the opposite of “right, get it?)

Copyleft licenses stipulate that derivative works may be created and distributed but if they are distributed they must have the same license as the original. If you make changes to a program licensed under the GPL and then distribute the modified program, it must also be GPL licensed with source code available. These kinds of licenses are also known as reciprocal, the idea being that if you take from the commons you can’t benefit from distributing your modifications without giving back to said commons.

To support his vision for free software, Stallman founded the Free Software Foundation (FSF). The FSF published their definition of free software and the four freedoms.

Today the main activities of the FSF include: maintaining the Free Software Definition, along with a number of other historical articles about the free software movement, sponsoring the GNU Project, and holding and enforcing the copyright for a number of free software projects.

Linux kernel created, released under GPL

The original goal of the GNU project was to create an entirely free operating system. Operating systems have many components, including several utilities and a kernel. By the early 1990s, the project had several completed utilities but still lacked a functioning kernel (GNU’s is called Hurd). In 1992 Linus Torvalds released the Linux kernel he created the year before under the GPLv2 license. It combined with GNU utilities made for a complete free and very functional operating system. As a result the Linux kernel became very popular, bundled and distributed in all kinds of configurations. (Incidentally, this is why Stallman insists we say GNU/Linux instead of just Linux.)

It’s probably safe to say that the Linux kernel is one of if not the most successful software project license under the GPL. Likewise, Linux sees a great amount of commercial support that the whole global software community benefits from because it has a copyleft, reciprocal license. WordPress and Drupal are also popular software projects with a GPLv2 license.

Debian project and the Debian Free Software Guidelines

One early Linux distribution is the community-supported, non-commercial Debian project started by Ian Murdock (RIP) in 1993. The history of Debian is pretty interesting, follow that link when you have time to learn more, and I’ll include an excerpt here:

At that time, the whole concept of a “distribution” of Linux was new. Ian intended Debian to be a distribution which would be made openly, in the spirit of Linux and GNU…Debian was meant to be carefully and conscientiously put together, and to be maintained and supported with similar care. It started as a small, tightly-knit group of Free Software hackers, and gradually grew to become a large, well-organized community of developers and users.

Debian has a social contract, which includes the Debian Free Software Guidelines (DFSG).

For the first year or so, Debian was sponsored by the FSF. Then they created their own non-profit, Software in the Public Interest, which acts as a fiscal sponsor for many free and open source projects today.

Creation of the term “open source” and founding of the OSI

Now we’re to the late 1998s. The internet bubble hasn’t burst yet. Linux is wildly popular and getting mainstream recognition. In January 1998, Netscape announced “bold plans to make the source code for the next generation of its highly popular Netscape Communicator client software available for free licensing on the Internet.” This was the beginning of the Mozilla organization.

The license chosen for Mozilla code was a new one written by Mitchell Baker called the Netscape Public License (NPL). It differed from the GPL in that Netscape retained the right to redistribute the code under any kind of license, even a proprietary one. The NPL was further refined into the Mozilla Public License (MPL), which itself has been revised a few times. The current version is 2.0, is GPLv2-compatible and considered weakly copyleft.

Netscape’s announcement that they were going to freely license the next version of Navigator motivated some folks in the free software community to build on the moment and further advocate for the adoption of free software and its “open development” production model within the business community. To support their advocacy, they sought to create a more business-friendly term for free software. In February 1998 these folks got together and brainstormed how to get the corporate world to listen and what new term for free software might help them do that.

The term they came up with was “open source.” Here’s an excerpt from Christine Peterson’s account of how she coined the term ‘open source’:

“The introduction of the term “open source software” was a deliberate effort to make this field of endeavor more understandable to newcomers and to business, which was viewed as necessary to its spread to a broader community of users. The problem with the main earlier label, “free software,” was not its political connotations, but that—to newcomers—its seeming focus on price is distracting. A term was needed that focuses on the key issue of source code and that does not immediately confuse those new to the concept. The first term that came along at the right time and fulfilled these requirements was rapidly adopted: open source.”

And here’s another description, from History of the OSI:

“The conferees believed the pragmatic, business-case grounds that had motivated Netscape to release their code illustrated a valuable way to engage with potential software users and developers, and convince them to create and improve source code by participating in an engaged community. The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label “free software.” Brainstorming for this new label eventually converged on the term “open source”, originally suggested by Christine Peterson.”

Eric Raymond (ESR), then lead developer of Fetchmail and author of The Cathedral and the Bazaar, was in town helping to prepare Netscape’s free software release of Navigator. He attended this brain storming session and later that month he and Bruce Perens founded the Open Source Initiative.

The first board of the OSI decided that the organization’s primary activities would be “general educational and advocacy” and “focus specifically on explaining and protecting the ‘open source’ label.” The OSI initially applied for trademark protection for the phrase “open source” but ultimately decided to let their application lapse with the understanding it is too generic to be trademarked.

One of the first things the OSI did was to create the Open Source Definition (OSD). Bruce Perens was familiar with the Debian Free Software Guidelines (DFSG) because he had served as the project’s second leader. Perens made minor modifications to the DFSG to create the OSD. It has remained relatively static since then, with one exception:

“In 2004 the OSI added clause 10 to the OSD to deal with some issues surrounding click-wrap licensing. Otherwise the OSD has been stable since its inception, with only minor wording clarifications in other clauses.”

The OSI used the OSD to create a list of “OSI-approved” licenses. These approved licenses include a lot of the ones you’ve likely heard about, such as the Apache License 2.0, BSD 3-clause, BSD 2-clause, GPL, and MIT. Some OSI-approved licenses were in use and had been for a long time prior to the formation of the OSI and their OSD (e.g. GPL). Others were brand new (e.g. MPL), and others have been created since.

The OSI has a license review process by which licenses can be submitted for consideration for OSI-approval. If approved, software using that license may use the “OSI Approved License” trademark to identify the software thusly.

Why the “OSI Approved License” designation matters

Why does the “OSI Approved License” status matter? Like any certification against a standard, it matters because it signals that what we call an “open source license” adheres to expected norms and qualities.

Corporate legal and compliance departments as well as individuals know certain things about a license if it is OSI-approved. First and foremost, they know they can use the software for any purpose whatsoever, including modifying it. OSI-approval doesn’t tell you everything about a given license, of course. It doesn’t tell you, for example, if the license is a copyleft/reciprocal license. That’s why most FOSS organizations discourage use of obscure and novel licenses. And also why it’s a good idea to have at least a cursory understanding of how the GPL differs from common permissive licenses. Larger companies will often require engineers to take a training on this.

Why did the OSI want a business-friendly free software?

The folks who created the OSI were clearly interested in creating a business-friendly version of free software in order to have the business community adopt open source software licensing and development practices. Why they wanted to court the business community isn’t so clear, at least from the sources I’ve looked at. I think they were motivated by a few key things:

  • Genuine belief that cross-organization open development practices create the best software products.
  • Hatred of Microsoft and its monopoly power. Remember when Internet Explorer and Windows NT were ubiquitous?
  • Their own desire for freedom in their professional lives as developers. If the code you write for an employer is open source, you can showcase and re-use that work after you’ve left that employer’s service.
  • The belief that including the business community, even through the use of non-reciprocal licenses, would have an overall positive effect on the global software commons.

I also think that for a lot of the early open source (OSI), permissive licenses aligned with their notions of how free speech should operate. How many of us have hear the “not free as in ‘beer’, free as in ‘speech'” bit?

Summary: The creation of the global software commons

Both the free software and the open source movements have resulted in the creation and maintenance of a global software commons used by individuals and organizations across the globe. They both have done this through a clever use of copyright law. The open source movement specifically aimed to create a business-friendly version of free software.

These are the categories of software copyrights and how they relate to the maintenance of the global software commons:

  • “Proprietary” software: Creator retains ownership of copyright and licenses to whom they want on a case-by-case basis, using a variety of custom licenses, usually with a fee. Does not contribute to the global commons. Could contribute to sub-commons via membership-based organizations such as co-ops and trade associations.
  • Free software: Creator retains ownership of copyright and licenses their work in such a way to contribute to the global commons. The free software community generally has a greater focus on copyleft licenses where reciprocity is required.
  • Open source software: Creator retains ownership of copyright and licenses their work in such a way to contribute to the global commons. The open source software community generally has a greater focus on permissive licenses where reciprocity is not required.
  • Public domain software: Creator relinquishes their ownership of copyright such that the work falls into the public domain and thus contributes it to the global commons with no responsibility for others to reciprocate.

Most, if not all, software with a FSF-approved free software license would also qualify as “open source” in the OSI sense, and visa versa. (Thanks @dgutov for the suggestion to add this clarification.)

I’ve used quotes around “proprietary” above because, in legal terms, technically all software not in the public domain is “proprietary”, because it is subject to the proprietary rights of copyright. While I’m fine with using proprietary in a colloquial way to distinguish from software released under a FOSS license, I think it’s a good idea to remember that FOSS is based on a clever use of copyright law in which the owner of the copyright doesn’t actually relinquish it.

Contributions to a project with a FOSS license are generally considered to be contributed under the same terms of the parent project. Some projects and licenses are more explicit about this that others. Some projects require contributors to sign Contributor License Agreements (CLAs) to make it explicit under which terms the contribution is given, even going so far as to require the contributor to assign their copyright to the parent project.

Where we are today

Fast-forward twenty years later and we find ourselves in a world where FOSS is nearly ubiquitous. Even if the code they produce isn’t released under a FOSS license, most all programmers use FOSS code in their work or as part of their toolchain. Companies like Google. Microsoft, and Amazon Web Services utilize FOSS work extensively in their product offerings, directly or indirectly.

Github over the last decade or so had a lot to do with making FOSS mainstream. But in a sense Github was just in the right place at the right time to take advantage of all the advocacy work of the OSI and the FOSS community in general throughout the preceding years.

Most people using open source and even releasing their own code as open source know nothing more about free or open source software licensing other than they picked that kind of license. Some folks think if code is available on a public Github repository, then it’s “open source,” regardless of the actual license of the project.

In this regard, the FOSS community has been more successful in driving adoption of an open production model, rather than the FOSS licensing model. Don’t get me wrong: There are certainly folks for whom contributing to and maintaining a global software commons is of paramount importance.

But, I think what a lot of us value about “free software” and/or “open source” are the technology communities we’ve participated in that have areas of overlap with the global software commons made possible by FOSS but are not exclusively defined by that commons, or by extension the OSD.

We’re in a “third-wave” of FOSS

My friend and colleague Audrey Eschright describes the era of FOSS that we’re in now as its third wave. The folks that came of professional age during this era have a different set of dominating concerns than previous generations. FOSS has largely “won” in that it’s everywhere, so driving adoption is not among those concerns. We’re concerned about the monopoly power of tech companies, the sustainability of our FOSS communities, the shortcomings of “meritocracy” and the lack of diversity and inclusion, and more. Go read Audrey’s essays for a further deep-dive into those topics.

Part of this third wave, and in conjunction with the mounting transgressions and abuses of the Trump administration, we’ve become more and more concerned about how the product of our labor is being used. This isn’t a new topic in the realm of FOSS. Throughout its history, folks here and there have tried, with varying levels of success, to attach various kinds of ethical use clauses to the terms under which they released software.

But now we have this third wave, this third generation of FOSS that has a concerns around social justice that haven’t been adequately address by the previous generations. Folks are seeing that open source is being used by government and private actors in ways they consider reprehensible and they are wanting to exercise what power they can do do the right thing and lessen complicity with these terrible acts.

Our existing FOSS software institutions have generally been going about their regular business and have been unresponsive to the needs of this newer generation. The Free Software Foundation, long hampered by the misconduct of its founder and, until recently, board president Richard Stallman, remains mostly an invisible niche player. It’s mostly die-hard free software folks and a handful of MIT students in close proximity to the org who pay attention to what the FSF does or attends its events such as the annual LibrePlanet conference.

The OSI mostly contributes to these conversations by chiming in to remind people about the OSD and to request that they not call any license “open source” that doesn’t conform to the OSI.

There are other orgs in the FOSS that are doing better and have demonstrated greater responsiveness towards the evolving needs of the community. If I start to catalog them here, I’ll never finish this post.

The limits of licensing

The use of licensing to ensure software users’ freedom, or to bring free software and open development methodologies to the business community is a very clever use of copyright that has served those purposes very well.

Licensing and copyrights, however, has limits. I don’t believe licensing will end up being an effective avenue for ensuring ethical use of software we create.

For one thing, we already have a mechanism for controlling how our software is used: proprietary licensing. If you don’t want to give permission for anyone anywhere to do whatever they want with your software, just don’t release it with a free software or open source license. You can even still give it away if you don’t want to charge money.

But ultimately, once someone has your code, or binaries compiled from it, it’s very hard if not impossible to control what they do with it. Most if not all DRM can be circumvented eventually. The mechanism we have for enforcing adherence to software licenses is the court system, which is part of the government. Not only does it usually take considerable resources to enforce license adherence, but if the ultimate facilitator of that process is an extension of the government, and we can’t trust the government, then…well you see my point.

A lot of folks seem to want to prevent their labor via software contributions from facilitating either ought to be illegal or already is illegal but the current administration is not acting lawfully. Neither of those situations can be addressed with software licensing.

Who is writing code and under what conditions?

One aspect that seems largely absent from our recent discussions about FOSS licensing and ethical use of technology is any information about who is writing this code, under what conditions, and how that affects their ability to select licenses for their work.

These scenarios cover most contributions to open source:

  • Scenario A: Individuals contributing open source code in the domain of employer while employed.
  • Scenario B: Individuals contributing open source code not in the domain of employer while employed.
  • Scenario C: Individuals contributing open source code while self-employed or unemployed.

(There’s a version of Scenario A and B where your employer is the government. I’m not going to speak to those scenarios because I just don’t know enough about the applicable laws and practices. For example, I have read that code written as part of Federal employment must be release to the public domain.)

Scenario A matches Seth Vargo’s situation with chef-sugar (and perhaps the other Chef-related packages he pulled; I only looked into the one). Though the code for this project was hosted under his own personal GitHub, he started the project while employed by Chef. Unless his employment contract was very unusual, Chef owned that code, even though Seth continued to maintain it on his personal GitHub after he left Chef’s employ.

Regardless of the specifics with Chef, the fact remains: code you write for an employer, even if open source, is generally owned by that employer and you’re not going to have the power to specify any license terms you want. So something like the Hippocratic License could never apply unless the whole business decided to adopt it and I’ve already talked about why that’s highly unlikely and will talk about it some more in just a bit.

Lots of work falls under Scenario B. Supported by a day job, folks contribute to open source that interests them, sometimes with explicit permission from their employer, sometimes just by flying under the radar. Some employers make this very difficult, if not impossible, by stating in employment contracts or policy that employees are not allowed to contribute to open source projects except by explicit permission. And usually in those cases the employer claims ownership of the work product of those outside contributions as well. So, whether or not something like the Hippocratic License could apply to work done under Scenario B depends on employment status as well.

Scenario C sounds like it offers the most flexibility to change or determine the license terms of one’s open source contributions. If you start an open source project you can pick any license you want for it, of course. But what if you did not start the project? Or what if you did start it but now have lots of contributors and want to change the license? Unless you’ve required contributors to sign CLAs assigning their copyright to you prior to accepting their contributions, you’ll need to go to each one of them and have them sign off on the license change.

And, let’s say your project uses an open source license with an ethical use provision and later on down the line contributors to the project disagree on whether or not license terms have been breeched. How do you go about deciding to pursue enforcement or not?

Changing the OSD # 5/6 would break the global commons

Coraline makes it very clear that one of her goals with the Hippocratic License is to get the OSD to change its definition of open source:

My call to arms: amend clauses 5 and 6 of the Open Source Definition to usher in a new era of ethical development, and for fucks sake #NoTechForICE.

Changing the OSD would be a backwards-incompatible breaking change that would destabilize FOSS, not improve it, and wouldn’t ensure ethical use of the fruits of developers’ labor, for all the reasons I’ve already stated.

(Coraline has changed her position on this. See this Twitter thread for my response.)

Even if ethical clauses could be enforced, it would fracture the global commons into myriad sub-commons, based on different groups interpretations of ethical use.

Because we have been so focused on the shortcomings of FOSS, I think a lot of us have forgotten the benefits we derive from it. There’s a huge support structure that’s been built to support open source development. Labor and access to a computing device and internet aside, most folks contributing to open source receive a large number of subsidized infrastructure services. FOSS contributors get to benefit from portability of their portfolio as they move from employer to employer. FOSS contributors get to use and build upon a HUGE existing body of work that comprises the global commons.

These benefits largely came about because of the widespread commercial adoption of FOSS, which came about because of the OSD and the advocacy work the OSI and others in that space did over years.

It’s not “us” vs “them”

Coraline makes a number of assertions, including that the OSI holds some kind of moral authority over us, that the OSI and the FSF have some kind of unearned power over us.While I understand the power of an ‘us’ vs ‘them’ rhetoric, I find these assertions unhelpful and ahistorical.

Whatever stature these organizations have they do so because they earned it by doing years of advocacy work. We do not need to take power away from these organizations in order to cultivate and exercise our own power. We are not in a zero-sum game.

Furthermore, while I understand where the idea comes from, the OSI and the FSF aren’t the moral arbiters of anything. Neither is the ISO or the IETF, which are apt analogies because the OSI and the FSF both act like standards bodies.

The FOSS community has a deep vein of FOSS is (morally) right, proprietary is (morally) wrong. While true that this belief is held by some individuals at these organizations and likely drives their participation in FOSS, I don’t believe that it’s objectively true that these organizations determine what is right or wrong for all of us. I believe this idea has done more harm that good and that we should not continue to feed it. We determine what is right and wrong action, for us as individuals, and in our various communities and workplaces.

Our efforts will go a lot further if instead of tearing down the people and organizations who represent prior art in this area, we listen to what they have to say and make requests that are reasonable of them.

The primary stewardship role of the OSI today is to maintain the OSD, maintain a list of approved licenses, and to facilitate the license review process. The OSI is also a mostly a volunteer-run organization. They have some paid staff. I don’t know if any of them are even full-time. The folks involved in license review are volunteers except for one paid person who summarizes license-review discussions.

Asking the OSI to do work, unpaid or otherwise, not in line with their mission wastes their resources and yours. I disagree with the politics of some of the founders and current stewards of the OSI, and wish they would refrain from claiming authority over the greater cultural aspects of open source. That said, they are performing an important role in the ecosystem and we should recognize that rather than trying to undermine them.

We should be trying to learn from the work they did to establish the software commons we have today and finding ways to work together on shared interests and looking elsewhere for allies in areas of divergence.

We should also recognize that some of the folks involved with our founding institutions are “us”. They members of this third wave of FOSS and they care deeply about these issues just like we do.

Why is it so important to you to have an OSI-approved open source license?

If you really want to keep releasing software under a free software or open source license, as defined by those orgs, have you thought about why? Do you want wide-spread adoption via commercial entities? Do you want the free shit you get as a FOSS project? Do you want the good feelings that come with a FOSS license because the tech community is saturated with the idea that open source is the best or only way to do it? Is it important to you give give back to the commons with your labor? Do you want to maintain compatibility with the entire ecosystem of FOSS?

If you aren’t interested in any of these things, or don’t find them a worthwhile enough tradeoff to relinquishing control of who uses your code and for what, maybe what you need is a simple EULA framework you could apply to your work.

If you are interested in those things, or in a subset of those things, you need to recognize that they come as a package, and are dependent on licenses that do not restrict use.

Those wanting a new license category with restrictions around use and wide-spread adoption of projects licensed thusly, and interoperability with other projects, we’re gonna need a deep, sustained, focused effort to develop and drive adoption of it. And you probably also need to recognize that if licenses are involved in such an effort, they will probably be considered “proprietary” by most of the open source community who follows such things.

I don’t see a new license paradigm happening inside the OSI because of how singularly focused their efforts at commercial adoption of OSS have been, how much changing the OSD would be a backwards-incompatible change, and because they are a tiny organization with limited resources. That’s okay. It’s okay for organizations to be focused narrowly on their stated mission. It doesn’t mean they are doing anything wrong.

There are many ways to do community-driven, values-based work

The thing is, you don’t need an OSI-approved license to do all kinds of “open source” community-driven, values-based work. Nor do I think an OSI-approved license precludes that kind of work. As @ehashdn and @ameschright and others have said, there are mechanisms outside of software licensing for engaging in activism and right action.

There’s more good news: participating in the global commons is not mutually exclusive with building other kinds of commons.

With OSD-compliant open source, you as a developer exchange your freedom to have a say in who uses your code for the freedom to contribute to and access the global commons. Because, by definition, the resources of a commons have to be made available to everyone in the society that owns the commons.

But we can create sub-societies with sub-commons based on a shared set of values, to drive a shared set of ethical practices and behaviors. I think that kind of community building is totally worthwhile. But it’s also a monumental amount of work. Legal and financial work. People management work. Movement building. It won’t be based on heroic individual efforts and we shouldn’t be rewarding these. And while we can learn from one another and share certain resources, including knowledge, this cannot be templatized or made turnkey.

We should continue to work together to identify and refine the existing ways to leverage what power we do have as contributors to the global commons. Leveraging intellectual property law is just one facet of this. The other facets include building the power of organized labor, building systems to buffer against the destructive nature inherent to capitalism, and more.

Conclusion

We don’t need to shake up open source licensing in order to build communities around shared values and mutual aid. All kinds of people are already doing this all over the place.

Any attempt to “shake up” or evolve open source licensing needs to:

  • a) Demonstrate a firm understanding of the foundations of FOSS so all those involved in the movement, but especially leaders, are clear about how we got where we are today, why, and what’s been tried before.
  • b) Grounded in praxis. If you’re writing manifestos largely on your own, before you’ve done much actual community-building work, you’re doing it wrong.
  • c) Collaborative. Multiple groups coalescing to address any given problem is fine (and necessary). It’s important that we make a concerted, good faith effort to consult and recognize the folks doing similar work as us.

I’m opposed to efforts that violate these tenets and I think Coraline’s Hippocratic License and its companion Ethical Open Source Movement do. Coraline doesn’t seem to have a deep understanding of the history of FOSS. She confused the OSD with the GPL, for example, and then when corrected, tried to brush off the inaccuracy as immaterial. Near as I can tell, the Hippocratic License isn’t grounded in practice. Coraline hasn’t even applied the license to her own projects, aside from the license text itself. Coraline asserts that these are community efforts and anyone is welcome to contribute, but I see little evidence that she incorporates a wide range of input from other SMEs, nor do I see her recognizing much prior and/or simultaneous work in this area. If you look through the repos on her GitHub, you’ll see a lot of open, unanswered issues.

I have no problem with folks experimenting in public. That’s not what’s going on here. Coraline has a good deal of influence. In this case she is using her influence to demand the change she alone thinks is needed, without the the requisite knowledge gathering or community-building. Heroic, singular efforts may be effective at generating publicity, but I do not think they are wise nor should they be rewarded or regarded as exemplary. It is always my concern that such efforts are not just neutral, but have potential for harm because they take away resources and attention from other, more sound efforts that could be more effective and more beneficial for the community at large.

More thoughts about the neveragain.tech pledge and what you can be doing instead

The neveragain.tech pledge continues to gain traction (if you can call it that) and I continue to analyze why I find it so troubling. For my initial thoughts, see this blog post.

A code of ethics or a call to collective action?

It’s not clear what the pledge is supposed to be. Is it a code of ethics and and conduct for our profession, or is it a call to collective action? I think it’s trying to be both, and it’s doing both very poorly.

Our profession already has a code of ethics.

In terms of trying to be a code of ethics: our profession already has this and has for some time. In fact is has a few to choose from. There’s the ACM Code of Ethics and Professional Conduct, the joint ACM/IEEE-CS Software Engineering Code of Ethics and Professional Practice, and the IEEE Code of Ethics. One of these are referenced by the pledge, but only way on down in the resources section and without context.

Whenever you eschew an existing standard, you ought to give a compelling reason why. Otherwise you give the impression of ignorance (not knowing about it in the first place) or egotism (doing something new so you can put your name on, h/t @JohnMetta).

I suspect a lot of us have never heard of any of the existing codes of ethics for our profession, or if we have it hasn’t been in any serious context of actually applying the code in our day to day work. If this is because so many of us are self-taught, or because these codes aren’t taught in computer science curricula, or some combinations there of, I don’t know. I am interested in finding out and in helping to educate my colleagues and put these codes into wider practice with commensurate accountability mechanisms.

If these existing codes are flawed and need revising, let’s work on that together. You can comment on the ACM’s revised draft now through 15 January, 2017. If you care about this stuff, go do that now. Don’t put it off.

In terms of serving as a code of ethics for our profession, the neveragain.tech pledge is significantly lacking. It is simultaneously uncomprehensive and overly prescriptive.

A poorly thought call to action.

In many ways, the pledge looks much more like call to collective action, especially given the part that commits signers to resigning their employment if they are forced to comply with behavior defined as misuse of data. This is a kind of direct action.

But in this it fails too, for any metric more significant than shallow performance. Where is the accountability, the support, the education, the building of trust required for effective collective action? Where is there any clue that the organizers of the pledge actually understand how to lead a collective action?

There are some glaring statements and omissions that make it clear to me they do not. First, the pledge requires people to quit their jobs rather than comply. Now, resigning might be the right thing for an individual to do based on their own sense of dignity or respect or emotional well-being. And, it might feel like a righteous and just action. But it isn’t necessarily the most effective action to take. For it to be effective many people would have to quit at once. And perhaps not even then. In their guide on Effective Strikes and Economic Actions, the IWW says “Workers can be far more effective when they take direct action while still on the job.”

It’s clear the organizers are overwhelmed and delighted by the volume of response to the pledge. However, it’s not clear to me they’ve given any real thought to the number of people required to partake in a collective action in order to make it effective and whether or not those numbers are achievable starting with this kind of online pledge.

How many does it take to be effective?

There’s no definitive participation rate at which strike-like actions are guaranteed to be effective. While we have a rich history of labor organizing upon which to draw, every direct action is different. What we do know is that whatever the circumstances, enough of the labor force needs to participate such that the target organization feels or fears significant, negative, long-term financial consequences.

Let’s say, for sake of this thought exercise, that the number is 20%. (Here is where I would love to hear from managers or executives about which percentage would cause you concern and make you change course.) According to the Bureau of Labor Statistics, approximately 4 million people are employed as tech workers. This doesn’t include those who are self-employed, and it might also be excluding those who have other job classifications but happen to write software. Again, this is a thought exercise, not a scientific paper. The idea here is to get a rough idea of scope.

20% participation x 4 million tech workers = 800,000 signers to pledge

As I’m writing this, 1943 people have signed the pledge already.

1943 / 800,000 = 0.24% towards goal

What would it take to reach the goal of 800k? Let’s say another 8k folks hear about the pledge through word of mouth, are sold right away, and show up to sign the pledge. That would bring the total to 10k.

10k / 800k = 1.25% towards goal

Now what would it take to get those additional 790k signers? Each existing signer would need to convince 79 of their colleagues to sign.

Applying the 20% goal to individual companies looks something like this to reach 20%:

  • Google (Alphabet): 13.9k
  • IBM: 75.5k
  • Facebook: 3.14k
  • Oracle: 27.3k

I’m using these companies global workforce numbers, because that’s what is most readily available, but you get the idea.

I bring up these numbers not to shit on the efforts of the neveragain.tech pledge organizers. I bring them up because I continually see our community fail to coherently, meaningfully discuss and analyze our tactics for driving change. It’s not enough just to have enthusiasm. You also need to know what you’re doing and have a good plan!

(The above numbers assume that everyone who signs the pledge will also follow through on their commitment to take direct action in their workplace. Assuming 100% is highly optimistic.)

There is more at stake than a Muslim registry. And there has been for a long time.

I say this not to minimize the threat to Muslim Americans or Muslim refuges living in America. That threat is very great.

It is also great to women, Latinos, Blacks, queer folks, those who are trans and gender non-conforming, those who are neuroatypical, those living with differently-abled bodies, those who struggle with houselessness, and those who are poor. The scale and nature of likely harm to individuals with differing intersections of these identities will vary, of course. I list them here not to equate them, but to demonstrate the scope of probable harm to our fellow citizens (of America and of the world).

Moreover, these folks have already been subject to varying kinds of harm and oppression and for quite some time. This did not start with the election of Trump. Tech has always had an obligation to stand up for these folks and by and large it has done a very bad job. Just look at how many of your co-workers are not white, straight, cis, male, and abled-bodied.

Every conversation about diversity and inclusion you stood by and watched or played “devil’s advocate” in was a missed opportunity to stand up for injustice. Every time you did not take us seriously about Gamergate. Every time you let your “difficult” colleague (who was likely a women, or Black, or queer, etc.) stand alone and be ostracized for raising an issue about how something your company was doing would have negative effects.

Tech colleagues, you’ve had a lot of opportunities that you’ve just completely squandered. I personally, have very little confidence, you will suddenly start to do markedly better.

And my confidence is not raised when the mechanism by which you are promising to do better repeats the very same mistakes we as a community have been making all along.

Continuing the status quo.

In my earlier blog post, I mentioned that I can’t join a movement when I don’t know who its leaders are. It turns out that the organizers of the pledge aren’t anonymous. They are revealing themselves to the media and on Twitter and probably elsewhere. But this isn’t the same as transparency or accessibility.

The pledge itself gives no background on how it was created or by whom. One should not have to dig for this information. It should be available via the pledge itself or no more than a link away.

Obfuscating leadership and process doesn’t promote individual responsibility nor does it make an effort more inclusive. All it does is obscure the context and motivation conferred by the project and make leadership less accountable to participants.

In tech, we have a long history of imposing our solutions on those who are marginalized, without their input or consent. We compound this error by ignoring or dismissing feedback when given.

Because the organizers have chosen to obscure who they are and by what process they created this pledge, I can only assume this same pattern is true. This is all the more true when at least one of the organizers is has a history of being hostile towards others’ religious practices and of ignoring the feedback from the people of color in communities they steward.

What I do see is a lot of (white) people on Twitter defending the pledge and Black folks saying it’s performative, shallow, and not helpful and not being listened to. Go see for yourself.

Not every effort deserves merit.

In my earlier blog post, I countered the idea that the pledge is the least folks can do. I want to expand on that by saying it might actually be quite counterproductive to support this thing.

It can hurt and does hurt to give attention to ill-conceived efforts. Attention is a finite resource. Giving our attention to poorly conceived or implemented efforts means there is less to give to ones that are better designed and better serving of their communities. Positive attention often brings benefits of all kinds: social and financial capital, credibility, etc. Folks with greater privilege, like white folks, receive more than their fair share of these benefits for work of lesser quality. And once they do, their projects and methods are remembered as good examples. And thus the cycle of mediocrity reinforces itself.

This is dangerous and counter-productive. It inhibits our ability to learn and grow. It reinforces the status quo and is antithetical to building solidarity.

Right action is way more complicated than you think.

Something else implied by this pledge is that there will be definitive moments where you know you are being asked to do something wrong and you will have a clear choice to comply or to walkaway.

In my experience, the actual situations we end up facing are nothing like this. They are complex and confusing and how best to act is quite often not clear. It takes continual, stumbling practice and a trusted network of advisors to gain enough experience to skillfully embody the ethical action we commit to.

And, for the most part, steps towards wrong action are gradual and indirect. I’ll illustrate this with a story.

Once upon a time, at my old job, I was on a call with the marketing team. We were discussing a project aimed at raising awareness about the importance of the open web. I noticed that the team, who was solely responsible for sourcing content for this project, was all men. I asked about the plan for including some women on the team. The response was deafening silence and the energy completely drained from the “room.” After some moments, someone responded with some kind of non-answer so empty I don’t recall now. The call continued and then concluded.

Sometime later, this same project published a pro-gamergate piece. All hell broke loose. Leadership had to deal with the ensuing PR mess. The project lead left the organization. We lost yet more credibility with our community.

Now, I’m not saying that having a woman on the team would have prevented the selection and publishing of a pro-gamergate piece. But I think it would have lessened its likelihood.

More importantly, the team’s and leadership’s failure to respond to the diversity issue I raised is directly related to the giant misstep it look later in publishing that gamergate article. No one was asked on that call to find and publish a pro-gamergate piece. They weren’t even asked to stay silent about the topic I raised; they simply did so because that was the prevailing culture. And in doing so, they took a small step towards creating the conditions for that later bad action to occur.

The lesson here? Start developing your senses now. Be on the look out for repercussions five, ten, twenty steps down the line. Speak up for all the little things because they lead to big things. Listen to your “difficult” colleagues when they raise issues even if you don’t quite understand where they are coming from. Use your privilege to assert publicly that what your colleague is saying is important and needs to be addressed. Start spending your social capital. Don’t wait for a rainy day, it is already upon us.

Some things you can do.

There are things you can do that require a lot more work than signing a pledge, but will be much more meaningful and impactful. Starting with the most specific and moving to the most general:

Read everything you can about labor organizing. If you’re curious about strike actions in particular, start here. Haymarket Books has a good collection of books about the labor movement and is having a 50% sale. While you’re ordering books from Haymarket, you might as well also get some on black politics and feminism. Read everything you can on IWW’s website. Then join if you are eligible. Figure out how to apply what you are learning in your workplace and in your community. A general strike is being planned for inauguration day. Learn about it and figure out if it makes sense for you to participate and how.

Commit publicly to abiding by one of the established codes of ethics for our industry. If you can’t decide, use ACM’s. Write a blog post saying that you’re committing to it and why. Tweet about it referencing neveragain.tech so folks following along know there is another option. Ask your colleagues to commit publicly as well. Encourage them if they hesitate. Start brining up the code of ethics in your daily work. You can do this by asking questions in your team meetings such as, “How does feature X abide or not abide with the code of ethics we’ve agreed to uphold?” Do this for processes that are already in place as well as new ones you are asked to create. Do this until it feels natural and then keep doing it. Hold your colleagues accountable, in whatever mechanism makes most sense, if you see them doing something contrary to the code. Likewise, support them if they seem to be struggling to uphold the code or being pressured to ignore it. Share your experiences doing all of these things, via which ever channels make most sense.

Find ways to materially and emotionally support the existing efforts of those who are most marginalized and at greatest risk. Support these efforts publicly, when it makes sense. Ask others to support these efforts. Listen deeply and learn from the folks leading these efforts without burdening them or colonizing their spaces.

Look for ways to build and support community where you live and to help meet the needs of those living closest to you. Pay attention to your neighborhood. Be a meaningful, respectful part of it.

Find ways to do the hard work of changing yourself. Prepare to give up things you have long taken for granted.