Proposal to update license to MIT/Apache-2

[ianjdarrow]

There have been a number of discussions about licensing across different IPFS projects. I'd like to propose that IPFS join Rust and a number of other prominent projects in adopting a dual MIT-Apache-2 license for all contributions.

There are two primary benefits to adopting this dual license:

• The MIT license alone creates some ambiguity over whether contributors grant a corresponding license to any necessary underlying patents. Most projects (including IPFS) resolve this by requiring a developer certificate of origin or similar. This is an unnecessary administrative burden to contribution. The Apache-2 license includes an explicit patent license grant and removes the need for a DCO.
• The Apache-2 license is thought to be incompatible with GPL-licensed projects. Retaining the option of the MIT license allows those projects to use IPFS, as well. I believe there are no licenses that would be "left out" if IPFS adopted the dual license, so it encourages the broadest possible adoption.

If folks agree that this is the right direction, implementing the change is straightforward, though it may be time-consuming. Each IPFS project repo should:

• Create a tracking issue (Rust example) in which all contributors consent to the license change for past contributions.
• At the same time, make the following changes to the project's root directory:
  • Add a file called LICENSE-MIT with the MIT license.
  • Add a file called LICENSE-APACHE with the Apache-2 license.
  • Add a file called LICENSE with the statement: "This project is transitioning from an MIT-only license to a dual MIT/Apache-2.0 license. Unless otherwise noted, all code contributed prior to (date) and not contributed by a user listed in (signoff issue) is licensed under MIT-only. All new contributions (and past contributions since (date)) are licensed under a dual MIT/Apache-2.0 license."
• Make a reasonable effort to chase down past contributors and get them to sign off. If the project gets everyone, the LICENSE file should be updated accordingly.

[momack2]

We have 235 ipfs/ repositories and ~4k contributors over the lifecycle of the IPFS project. I suggest we either prioritize the most touched repos (anything in the past ~month or so), or we use the Github API to create the tracking issue and rename the current "LICENSE" file to "LICENSE-MIT" and add the additional two files.

Based on the Github API docs this looks doable, but @mikeal has messed around with these in the past and might know more:

• https://developer.github.com/v3/repos/contents/#create-a-file
• https://developer.github.com/v3/issues/

[Stebalien]

Yeah, we can script this even with just the hub command.

[daviddias]

Thank you for pushing on this matter, @ianjdarrow. I love the solution we arrived at.

@ianjdarrow are you down to own the work of scripting and issuing the PRs + Creating the Tracking issue? Note, quite possibly, you can just use the PR itself to be the tracking place and once everyone signs it up, we merge it. How does that sound?

[daviddias]

//cc @ipfs/wg-captains

[ianjdarrow]

@daviddias I'd recommend sequencing it slightly differently – if we wait to merge the PR until everyone signs off, we will be tracking a moving target (new contributors might submit PRs before the new license is merged). Instead I'd propose the following:

1. For each project, merge a PR for the "transitional license" described above. This will have the effect of making all future contributions adopt the new license.
2. Same time, create a tracking issue – probably at the top-level ipfs repo, so we don't have people who have contributed to lots of projects checking 100 boxes!
3. Later, when/if an individual project has 100% coverage, merge a new PR that swaps the transitional LICENSE for a plain one.

Let me know if you agree. Happy to own the scripting piece. I'll also give some thought to how to track/tag contributors so we can keep up with completion percentages by project!

[ianjdarrow]

Mass PR work is progressing here. One secondary output should be an open source mass-license-update tool.

Some good news: looks like we "only" have 712 unique contributors across the IPFS org (lots of folks contribute to many repos!). Still a lot of folks to wrangle, but easier than 4k!

[jbenet]

+1 to @ianjdarrow’s plan.

712 unique — 4k

There are indeed more than 4K unique contributors across the org. Usually we include contributors via issues & PRs (ideas, design discussions, bug reports, etc) in our contributor counts. The 712 count is only about contributors of code (copyright needing), hence the lower number. Yay, easier for this purpose, but not the whole community :)

Also, note the other relevant orgs to adjust too: libp2p, ipld, multiformats, ipfs-shipyard, etc.

[ianjdarrow]

Agreed re: total contributors @jbenet!

👍 to your note. Just pushed a change that adds an org-name command line argument. End goal is that we (or anyone!) can do python3 license-change.py <org-name> and do a fully automated MIT+Apache-2 conversion, complete with PRs to all repos and auto-tracked sign-offs by all contributors.

[vmx]

May someone (@ianjdarrow perhaps? :) create a template repository with just the licenses and perhaps a README that can be used for new projects? I wouldn't want to start something new and then need to relicense it. This way we can also check if it shows up nicely it GitHub (talking about the "View license" button at the top row here).

[mikeal]

Before we do this, we need a public URL to point to that clearly lays out our Copyright policy to put in all of these PRs. We should not send hundreds of public PRs to repos that hundreds of people have contributed to without some explanation of why we’re changing the license.

I’m a big fan of our new IP policy and our copyright choices, I just don’t have the bandwidth to have hundreds of individual conversions with people in different pull requests about our reasoning :)

[ianjdarrow]

@daviddias previously expressed that this is best framed as (and actually is) an IPFS community decision, not a PL decision. The rationale in the original issue was meant to be self-contained and I'd recommend pointing folks there as a first step. We are separately going to launch the PL IP strategy in the next week or two, so could point folks to that, but I think it's best to have a standalone justification.

@vmx happy to do that and will spin up a template repo!

[hsanjuan]

python3 license-change.py <org-name> where's this? I'm happy to run it in Cluster

[ianjdarrow]

Working on it! The number of requests was surprisingly large, so I knocked out a a quick and (currently very rough) Go port because Python concurrency is hard. The new repo is here. You should be able to install and use it (but the automated PR piece is not done).

Progress:

If anyone is good at git internals (@mikeal ?) and can point out issues or improvements in the following flow, I'd be grateful.

1. Get names of all repos in org (√)
2. Traverse repos to get names of all contributors (√)
3. Create tracking issue in team-mgmt repo with contributors, checkboxes and summary of change (~√)
4. Generate LICENSE with link to top-level issue (~√)
5. For each repo…
   • add the blobs for LICENSE, LICENSE-MIT, and LICENSE-Apache… √
   • create a new tree with the new license blobs and without the old one… √
   • get the hash of the latest master commit (the “parent”) √
   • create a commit with the new tree √
   • make a new branch (not implemented)
   • submit a PR from the new branch with the new commit! (not implemented)
6. Save all the PRs so we can script merging them! (not implemented)

[Kubuxu]

Do you think it is possible to combine this with handing over copyright to something like IPFS foundation or is an entity like that too far into the future? Currently, we use Protocol Labs as the owner of the copyright.

[Stebalien]

@Kubuxu that would require a copyright assignment which we don't currently have (and is kind of painful to use, in practice). It's also not particularly useful given that we're using a permissive license.

However, it may make sense to eventually hand over trademarks on IPFS, etc.

[mburns]

@chriscool has some strong git-fu that might be helpful regarding https://github.com/ipfs/team-mgmt/issues/849#issuecomment-461640414

[vmx]

There isn't a template repo yet, so I tried an best effort approach for myself. I hope this commit complies to all legal requirements. I copied the licenses from license_bot. For the License section in the README I've copied the one from go-filecoin.

The only change I made is that in the README and the COPYRIGHT file I don't name the project, but just say "This project". I hope that's OK, this would make things easier to mass apply.

[hsanjuan]

I did it like this https://github.com/ipfs/go-ds-crdt/commit/d51c9f1306f317b77e7c314113b8643a0a471b82 , taking from go-libp2p-gorpc which was dual-licensed with legal advise some time ago. I'm not sure if choose your preferred license is correct, technically, both apply (?).

[ianjdarrow]

Boring legal technicalities, but users do have the ability to choose which license applies for downstream projects. The practical effect is not very much – both licenses generally grant users the same rights, but there are fringe conflicts between Apache-2 and GPL that some folks care about (more here).

Both @vmx and @hsanjuan 's language works just fine.

[momack2]

Hey @ianjdarrow - are you still blocked on this? Any specific asks for us to help with?

[vmx]

I keep creating new projects. It would be great to get template repos for the various languages so that I don't need to put thought into where to get the right license texts from, what to put as copyright, how to formulate the README, what to put in the license field in package.json.

[mikeal]

@vmx protip: add init-license=(Apache-2.0 AND MIT) to your .npmrc ;)

[daviddias]

@ianjdarrow what's the status on this endeavor?

[hannahhoward]

@daviddias I know go-bitswap is not updated, and it's partly cause I do not understand what process I need to follow to update the license, and on top of that, I am no longer working on go-bitswap mostly.

[vmx]

I'd like to bump this issue again. We are creating new repos all the time (e.g. https://github.com/ipfs/js-ipfs-utils) which are still licensed under MIT only. I'd really appreciate if there would be clear guidelines/templates for new projects as well as for migrating existing repos (including instructions on how one needs to get permissions from all contributors). The longer we are moving forward without this, the harder it gets.

[mikeal]

i can automate this with a recurring github action once all the policies are clear. i don’t think anyone should need to do this manually.

[momack2]

We unblocked this for go-ipfs and shipped it in https://github.com/ipfs/go-ipfs/pull/6301 🙌

For starting a new repo, just start from dual MIT/APACHE 2 from the beginning. Template: https://github.com/ipfs/go-ipfs/pull/6301/files (but without the "COPYRIGHT" file)

For relicensing an existing MIT repo you have two steps:

1. Sign-off issue: https://github.com/ipfs/go-ipfs/issues/6302
   • Ian had a nice script for generating the list of contributors which was useful in this case ;)
2. License update: https://github.com/ipfs/go-ipfs/pull/6301