Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

License update to dual MIT and Apache 2 #6301

Merged
merged 6 commits into from
May 6, 2019
Merged

License update to dual MIT and Apache 2 #6301

merged 6 commits into from
May 6, 2019

Conversation

momack2
Copy link
Contributor

@momack2 momack2 commented May 6, 2019

This series of commits aims to update go-ipfs to follow a dual-licensing best practice based on research into open-source licensing by @ianjdarrow. He recommends a dual MIT and Apache 2.0 license -

This has two major benefits:

  • There are concerns in the open source community about whether the MIT license leaves users vulnerable to patent infringement claims. We think the pure legal risk is small, but the way the open source community interacts with our project is really important. It makes sense to pick the license that makes the largest number of people comfortable.
  • There's now no reason to adopt a separate DCO, since the Apache-2 license grant addresses the same issue.

Why use a dual license, instead of just Apache-2? The Apache-2 license is incompatible with the GPLv2 license, which includes things like the Linux kernel. With a dual license, GPLv2 projects can just use the MIT license instead. Our goal is to make our software available to as many projects as possible, so we'd rather adopt a licensing scheme that doesn't exclude anyone.

In addition to these commits, we also need to get an explicit OK from current and past contributors to give their consent to relicensing - which will happen in an issue thread.

This series of commits aims to update go-ipfs to follow a dual-licensing best practice based on research into open-source licensing by @ianjdarrow. He recommends a dual MIT and Apache 2.0 license -

> This has two major benefits:

> - There are concerns in the open source community about whether the MIT license leaves users vulnerable to patent infringement claims. We think the pure legal risk is small, but the way the open source community interacts with our project is really important. It makes sense to pick the license that makes the largest number of people comfortable.
- There's now no reason to adopt a separate DCO, since the Apache-2 license grant addresses the same issue.

> Why use a dual license, instead of just Apache-2? The Apache-2 license is incompatible with the GPLv2 license, which includes things like the Linux kernel. With a dual license, GPLv2 projects can just use the MIT license instead. Our goal is to make our software available to as many projects as possible, so we'd rather adopt a licensing scheme that doesn't exclude anyone.

In addition to these commits, we also need to get an explicit OK from current and past contributors to give their consent to relicensing - which will happen in an issue thread.
@ghost ghost assigned momack2 May 6, 2019
@ghost ghost added the status/in-progress In progress label May 6, 2019
@momack2 momack2 requested a review from Stebalien May 6, 2019 19:07
moving to copyright file
transitional comments
@Stebalien Stebalien merged commit bfd4ec5 into master May 6, 2019
@ghost ghost removed the status/in-progress In progress label May 6, 2019
@momack2 momack2 deleted the update-license branch May 6, 2019 19:17
@momack2
Copy link
Contributor Author

momack2 commented May 14, 2019

Notes from Legal for further reference:

  • not having the © so-and-so line here is fine, since in MIT and Apache2 licenses the copyrights are retained by the contributors themselves
  • if any humans refuse to make the transition from mit to Mit+apache2 after a reasonable percentage of people have acked, we can just call out those particular contributions in the license itself (or rewrite the code to not be dependent on the original contribution)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants