Go-ipfs: Re-license go-ipfs to MIT + Apache 2

Created on 6 May 2019  路  46Comments  路  Source: ipfs/go-ipfs

@ianjdarrow has done some research into open-source licensing and determined that dual-licensing as MIT and Apache 2 is a best practice. Quoting from his writing elsewhere:

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.

What we need to do:

I have updated the licenses in https://github.com/ipfs/go-ipfs/pull/6301, the next step is to get an explicit OK from our current and past contributors to consent to the relicensing. To keep track of things, below is a contributor sign-off list. Contributors can either check the box next to their github handle, or comment on this issue thread with the following text:

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Contributor sign-off:

  • [x] @whyrusleeping (2666)
  • [ ] @jbenet (1869)
  • [x] @Stebalien (1001)
  • [ ] @mappum (530)
  • [x] @magik6k (523)
  • [x] @Kubuxu (451)
  • [x] @chriscool (249)
  • [x] @kevina (196)
  • [x] @cryptix (139)
  • [x] @RichardLitt (130)
  • [ ] @lgierth (126)
  • [ ] @rht (92)
  • [x] @hsanjuan (88)
  • [x] @overbool (82)
  • [x] @tv42 (68)
  • [x] @keks (51)
  • [x] @vyzo (40)
  • [x] @noffle (40)
  • [x] @wking (38)
  • [x] @kjzz (31)
  • [x] @schomatis (31)
  • [x] @MichaelMure (29)
  • [x] @verokarhu (26)
  • [x] @djdv (24)
  • [x] @frrist (23)
  • [x] @ianopolous (20)
  • [x] @dirkmc (19)
  • [ ] @mildred (17)
  • [ ] @chenminjian (16)
  • [x] @Luzifer (15)
  • [x] @torarnv (15)
  • [ ] @llSourcell (14)
  • [x] @travisperson (14)
  • [ ] @thomas-gardner (13)
  • [ ] @dborzov (13)
  • [x] @Zanadar (12)
  • [x] @kpcyrd (12)
  • [x] @pfista (11)
  • [x] @dylanPowers (10)
  • [x] @eingenito (9)
  • [x] @kulla (9)
  • [x] @hannahhoward (9)
  • [x] @cboddy (9)
  • [x] @michaelavila (9)
  • [x] @dignifiedquire (9)
  • [x] @daviddias (8)
  • [x] @marten-seemann (8)
  • [x] @mateon1 (8)
  • [x] @rob-deutsch (8)
  • [ ] @zramsay (8)
  • [ ] @kkoroviev (7)
  • [ ] @yuvallanger (7)
  • [ ] @Bren2010 (7)
  • [x] @leerspace (7)
  • [ ] @anacrolix (6)
  • [ ] @mlovci (6)
  • [ ] @cleichner (6)
  • [x] @momack2 (6)
  • [ ] @AuHau (5)
  • [ ] @da2x (5)
  • [ ] @hacdias (5)
  • [ ] @hosh (5)
  • [ ] @JesseWeinstein (5)
  • [ ] @Quantomicus (5)
  • [ ] @thisconnect (5)
  • [ ] @fsdiogo (4)
  • [ ] @AtnNn (4)
  • [ ] @geoah (4)
  • [ ] @Voker57 (4)
  • [ ] @kevinwallace (4)
  • [ ] @krl (4)
  • [x] @lidel (4)
  • [X] @raulk (4)
  • [ ] @Mr0grog (4)
  • [ ] @anarcat (4)
  • [ ] @matrushka (4)
  • [ ] @csasarak (4)
  • [ ] @techfreek (3)
  • [x] @eminence (3)
  • [ ] @toqueteos (3)
  • [ ] @cbuesser (3)
  • [x] @PlayerWithoutName (3)
  • [ ] @keremgocen (3)
  • [ ] @torresashjian (3)
  • [ ] @olizilla (3)
  • [ ] @karalabe (3)
  • [ ] @epheph (3)
  • [ ] @grokcoder (3)
  • [ ] @dgrisham (3)
  • [ ] @gatesvp (3)
  • [ ] @reinerRubin (3)
  • [ ] @vitzli (3)
  • [ ] @ivan386 (3)
  • [ ] @hexdigest (3)
  • [ ] @seidtgeist (3)
  • [x] @lanzafame (2)
  • [ ] @alecbrick (2)
  • [x] @andrew (2)
  • [ ] @andyleap (2)
  • [ ] @clownpriest (2)
  • [ ] @caioalonso (2)
  • [ ] @multikatt (2)
  • [ ] @eocarragain (2)
  • [ ] @funkyfuture (2)
  • [ ] @heems (2)
  • [ ] @MattSkala (2)
  • [x] @mib-kd743naq (2)
  • [ ] @mishmosh (2)
  • [ ] @patcon (2)
  • [ ] @prusnak (2)
  • [ ] @sqs (2)
  • [ ] @rwcarlsen (2)
  • [ ] @grncdr (2)
  • [ ] @timthelion (2)
  • [ ] @te0d (2)
  • [ ] @tonistiigi (2)
  • [ ] @vasild (2)
  • [x] @achingbrain (2)
  • [ ] @camelmasa (2)
  • [ ] @palkeo (2)
  • [ ] @b5 (2)
  • [ ] @sroerick (2)
  • [ ] @Aaron1011 (1)
  • [ ] @hcs64 (1)
  • [ ] @adrian-bl (1)
  • [x] @alanshaw (1)
  • [ ] @alfiedotwtf (1)
  • [ ] @AliMirlou (1)
  • [ ] @thelinuxkid (1)
  • [ ] @miolini (1)
  • [ ] @wemeetagain (1)
  • [ ] @ChrisChinchilla (1)
  • [ ] @insanity54 (1)
  • [ ] @sahib (1)
  • [ ] @ChristianKniep (1)
  • [ ] @NukeManDan (1)
  • [ ] @dtkav (1)
  • [ ] @zonque (1)
  • [ ] @davbre (1)
  • [ ] @wagdav (1)
  • [ ] @dominictarr (1)
  • [ ] @edisonlee55 (1)
  • [ ] @EliasGabrielsson (1)
  • [ ] @ehmry (1)
  • [ ] @eginez (1)
  • [ ] @ebuchman (1)
  • [ ] @makevoid (1)
  • [ ] @frogg (1)
  • [ ] @Neurone (1)
  • [ ] @HaraldNordgren (1)
  • [ ] @harlantwood (1)
  • [ ] @jackloughran (1)
  • [ ] @jes (1)
  • [ ] @jamiew (1)
  • [ ] @jefft0 (1)
  • [ ] @jonchoi (1)
  • [ ] @jdanford (1)
  • [ ] @JustinDrake (1)
  • [ ] @kevinsimper (1)
  • [ ] @Koshroy (1)
  • [ ] @flyskywhy (1)
  • [ ] @asymmetric (1)
  • [ ] @lgarron (1)
  • [ ] @mjanczyk (1)
  • [ ] @alimony (1)
  • [ ] @MasashiSalvador57f (1)
  • [ ] @machawk1 (1)
  • [ ] @dokterbob (1)
  • [ ] @maxkerp (1)
  • [x] @Mikaela (1)
  • [ ] @muneeb-ali (1)
  • [ ] @manandbytes (1)
  • [ ] @musoke (1)
  • [ ] @rikonor (1)
  • [ ] @pnelson (1)
  • [ ] @daftaupe (1)
  • [ ] @ReadmeCritic (1)
  • [ ] @ridewindx (1)
  • [ ] @rcarver (1)
  • [ ] @rmorey (1)
  • [ ] @Sag0Sag0 (1)
  • [ ] @slang800 (1)
  • [ ] @sbruce (1)
  • [ ] @sherodtaylor (1)
  • [ ] @sivachandran (1)
  • [ ] @spartucus (1)
  • [ ] @steverecio (1)
  • [ ] @icidasset (1)
  • [ ] @soenkehahn (1)
  • [ ] @TUSF (1)
  • [ ] @kalmi (1)
  • [ ] @timgws (1)
  • [ ] @tswindell (1)
  • [ ] @7yl4r (1)
  • [ ] @vikramsk (1)
  • [ ] @vitorbaptista (1)
  • [ ] @WilliButz (1)
  • [ ] @adamliesko (1)
  • [ ] @devedge (1)
  • [ ] @drathir (1)
  • [ ] @epitron (1)
  • [ ] @forstmeier (1)
  • [ ] @fyrchik (1)
  • [ ] @hoenirvili (1)
  • [ ] @klauspost (1)
  • [ ] @kvm2116 (1)
  • [ ] @myself659 (1)
  • [ ] @requilence (1)
  • [ ] @tarekbadrshalaan (1)
  • [ ] @theswitch (1)
  • [ ] @wzhd (1)
  • [ ] @victorb (1)

All 46 comments

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

(Even if I only added two words and an URL to one file in https://github.com/ipfs/go-ipfs/commit/4470b83644ac72e79171a3aee6c5e5cf1bbb3643, so I don't think my approval is very important.)

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

This is fine by me.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Although future contributions would be covered by the usual docs, right? So I don't think my commitment for future contributions matters as far as this PR goes.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Thanks, @momack2.

Can you explain why MIT is not sufficient anymore?

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

PS: I've updated my handle from @diasdavid to @daviddias, so my approval is valid for both handles (which I still own)

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Thanks, @daviddias. That was some very useful context.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I noticed a few recent commits still using the old sign-off messages (fa479f7a8a0abbc35b7dcffbed2d8853e42b364f, 7340eb5e95d0bb9df5d9b04d6497576f02e21fab, ...), and some commits with no sign-off lines at all (f2d01f5201cd3a20130e20bcdba25b6b53300c63, 227da14e58307bc681bd91b49d61071280c4b937). What should be used for signing off commits from now on?

The current sign-off is:

License: MIT
Signed-off-by: {name} <{email}>

Should this be changed to License: MIT/Apache-2.0? Should sign-offs still be mandatory?


BTW, gitcop's warnings about the sign-off point to a dead link, the file the bot links is contribution-guidelines.md in the community repo, but the file is now called CONTRIBUTING.md

Should sign-offs still be mandatory?

Signoffs are no longer mandatory and contributions to a project automatically fall under that project's license per GitHub's terms of service (https://help.github.com/en/articles/github-terms-of-service#6-contributions-under-repository-license).

We've also killed off GitCop.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Is this doc https://github.com/ipfs/go-ipfs/blob/master/docs/developer-certificate-of-origin still necessary with the new re-licensing? In another words, can I delete it?

I think we should keep that. We've decided that we no longer need explicit sign-offs and _technically_ GitHub has an automatic DCO for all contributions in the ToS but it can't hurt to keep that.

Why go this way instead of GPL v2?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

magik6k picture magik6k  路  3Comments

Mikaela picture Mikaela  路  3Comments

lidel picture lidel  路  3Comments

whyrusleeping picture whyrusleeping  路  4Comments

funkyfuture picture funkyfuture  路  3Comments