Guidance on how to adopt ethical source

[JonRowe]

👋 As the maintainer of a Ruby gem, RSpec, I love the concept of ethical source and am considering how to adopt it, a page of guidance on this would be great.

[CoralineAda]

Hi there! I really like your suggestion and this is content that we're planning on providing soon.

That being said, by my reckoning Rspec already meets most of the criteria, except for number 4 ("Its creators have the right to prohibit its use by individuals or organizations engaged in human rights violations or other behavior that they deem unethical."). I think to meet that criteria you would have to consider a license with an ethics clause, which MAY have the side effect of moving the project into incompatibility with existing OSD-compliant open source licenses. For that you might want a legal review.

[CoralineAda]

@JonRowe Would love to chat if you have time— https://where.coraline.codes/contact/ for first contact?

[zspencer]

I'm in the process of writing up some lessons learned from the adoption of the Hippocratic License by VCR; which is also an MIT licensed project.

Traditional caveat: I am not a lawyer. Do not consider this legal advice.

My current understanding is:

1. You may not remove the MIT license from your code without express written consent from every past contributor. In the United States, intellectual property rights stay with the author of the work unless there is clear transfer of those rights to another entity.

2. You may be able to add the Hippocratic-MIT license to the existing repository, so that future contributions and any contributions made by contributors who agree to re license are distributed under the terms of the new, ethical license.

3. You should clearly communicate that some of the work is licensed under the MIT license. Hat tip to @richardfontana for demonstrating this here: https://github.com/vcr/vcr/pull/805/files

4. You may want to create an issue stating your intent to change the license for future contributions to the project to an ethical license, and request that past contributors who wish to also re license their contributions to the new license grant explicit written consent in a public place.

[nateberkopec]

Re: pt 4, I wonder if we could build tools to help maintainers do that?

[zspencer]

@nateberkopec - For sure! That said, I don't know what legal or other structural considerations to think about when designing those tools at this time.

[tobie]

For sure! That said, I don't know what legal or other structural considerations to think about when designing those tools at this time.

This is regularly done by the Apache Foundation when onboarding new projects and requires signing a CLA:

"A specific process exists do donate code to the ASF, which podlings also need to follow, based on Software Grants and/or CCLAs." —http://incubator.apache.org/cookbook/#importing_the_initial_code

Here's an example of this process for CouchDB, for example: apache/nano#265

From a legal perspective (IANAL, but I'm fairly often involved in such discussions), a tool that would allow contributors to accept the license changes using their GitHub account (through text written by a lawyer and being clear about their intent to do so) would be sufficient. You'd need a log of that info somewhere with timestamps, preferably downloadable by the maintainer(s).