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.