mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@apache.org>
Subject Re: ICLAs vs Contributors
Date Wed, 06 Sep 2017 22:37:15 GMT
Hi Przemyslaw,

We need each of you to sign an ICLA (
https://www.apache.org/licenses/icla.pdf ). That will cover your
contributions, including future contributions.

If you'd like to only sign something for only past contributions (ie: not
looking to make future contributions), then having you sign an SGA would be
an alternative to an ICLA (
https://www.apache.org/licenses/software-grant.txt ).

Whether or not you should sign a CCLA is up to NVIDIA. Apache does not
require that corporations sign the CCLA, but some corporations choose to
sign a CCLA (for example if they feel that their employees are unable to
sign an ICLA without the corporation also signing something).

You can keep contributing (sending pull requests) before signing. Signing
this helps to strengthen MXNet's provenance (aka proof that the code is
legally authentic). There's already proof that the code is legally
authentic (some examples: you opening pull requests, the Apache license
requiring you to identify if the contribution is not under Apache license,
GitHub terms of service), this strengthens it :)

Many thanks for doing this,

Hen



On Wed, Sep 6, 2017 at 10:25 AM, Chris Olivier <cjolivier01@gmail.com>
wrote:

> I think individual (personal email addresses), which is how everyone else
> is doing it, as far as I know
>
> On Wed, Sep 6, 2017 at 3:20 AM, ptrendx@gmail.com <ptrendx@gmail.com>
> wrote:
>
> > Hi,
> >
> > Me (ptrendx on GitHub), Dick (DickJC123) and Marek (mkolod) are NVIDIA
> > employees working on MXNet. Should we sign individual CLAs or should
> NVIDIA
> > sign corporate CLA with ASF? If so, could you point us to the document
> that
> > needs to be signed? Can we contribute in the meantime?
> >
> > Thank you
> > Przemyslaw Tredak
> >
> > On 2017-09-01 12:28, Henri Yandell <bayard@apache.org> wrote:
> > > I've listed the top 100 contributors (as of the other day) on GitHub
> > here:
> > >
> > >     https://cwiki.apache.org/confluence/display/MXNET/ICLA+Progress
> > >
> > > With a check if they have signed an ICLA.
> > >
> > > John/Justin - can you confirm that we don't have to get an ICLA signed
> > from
> > > someone whose significant contributions have only been since MXNet came
> > to
> > > Apache? (Assuming it's not such a large piece of work that would flag
> for
> > > software-grant/ICLA - a new component etc).
> > >
> > > --
> > >
> > > I'd like us (MXNet) to work our way down the list getting (up to
> > > yanqingmen) ICLAs signed. After that we will review the nature of the
> > next
> > > batch of contributors commits and determine how much more ICLA signing
> we
> > > need.
> > >
> > > Thanks,
> > >
> > > Hen
> > >
> > >
> > > On Tue, Aug 29, 2017 at 10:06 PM, Henri Yandell <bayard@apache.org>
> > wrote:
> > >
> > > > (cc to John and Justin as they'd asked about this)
> > > >
> > > > Looking at the current MXNet GitHub contributors list (411
> > contributors):
> > > >
> > > > We have 36 signed CLAs at this point.
> > > >
> > > > Of the top 36 contributors, the following 15 top contributors aren't
> > > > covered by a CLA:
> > > >
> > > > 8:sneakerkg
> > > > 9:kevinthesun  (post Incubation)
> > > > 17:hjk41
> > > > 18:mavenlin
> > > > 19:tornadomeet
> > > > 20:winstywang
> > > > 21:jermainewang
> > > > 22:qiaohaijun
> > > > 23:vchuravy
> > > > 25:Roshrini  (post Incubation)
> > > > 26:howard0su
> > > > 28:sbodenstein
> > > > 31:ptrendx  (post Incubation)
> > > > 35:zackchase   (post Incubation)
> > > > 36:yanqingmen
> > > >
> > > > Note that some of these are post entering the Incubator.
> > > >
> > > > Some of the 411 contributors we should ask for CLA/SGs from. Those
> > above
> > > > are most likely the first to get agreements signed from, and we need
> to
> > > > determine how far down the list to go.
> > > >
> > > > The git logs are trickier to use as they don't use the github login;
> so
> > > > doing an analysis of the diffs themselves is trickier.
> > > >
> > > > Hen
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message