Open momack2 opened 5 years ago
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)
Btw, great post explaining the Permissive License Stack
@RichardLitt ^^
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?
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.
@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:
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:
Contributor sign-off: