[DISCUSS] Deprecating and Forbidding Terraform and Other Services by HashiCorp in MXNet

[Sheng Zha]

Dear community,

Yesterday, HashiCorp added to their terms of evaluation the clause that forbids 
usage of the enterprise version of any HashiCorp software in the People's 
Republic of China [1]. While this does not affect the usage of the community 
version, it does signal the potential legal risk to many of our community 
members in China. In light of this recent development, I'm initiating 
discussion on deprecating the usage of HashiCorp software and services and 
forbidding their usage in MXNet infrastructure until situation changes.

I believe that the community cannot be traded for the technological 
convenience. Currently, we have part of our CI and GitHub labeling robot 
bootstrapping logic that relies on Terraform, a service provided by HashiCorp 
[2]. Since all its usage that I found are for bootstrapping on AWS, replacing 
them with CloudFormation is feasible and likely straightforward.

Your input is appreciated.

Regards,
Sheng

[1] https://www.hashicorp.com/terms-of-evaluation
[2] 
https://github.com/apache/incubator-mxnet-ci/search?q=terraform&unscoped_q=terraform

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

[Carin Meier]

Zach,

If you are willing and able to do that on behalf of Amazon, that would be
great.

-Carin

On Fri, May 29, 2020 at 8:35 PM Zach Kimberg 
wrote:

> If we replace the official CPU build, won't there still be new dependencies
> so it is not even guaranteed to work depending on whether the user has the
> dependencies (e.g. libgfortran) installed? I think there is also a
> performance degradation if we remove mkl.
>
> But, we could still have a third-party build. I can try to redo the builds
> and release it on behalf of Amazon. Those builds can contain the full
> dependencies and supported environments (CPU, GPU, OSX) and are not
> restricted to Apache's license policies. Users will only have to update
> their dependency group IDs and they will get the same functionality as they
> have now.
>
> As Apache, we will only officially support JVM by building from source.
> Then, we just mention where to find the Amazon convenience builds while
> clarifying that they are not official Apache builds.
>
> On Fri, May 29, 2020 at 10:44 AM Carin Meier  wrote:
>
> > Thanks. I understand now. If all the current jars are not compliant, then
> > they should be removed.
> > I also don't like the idea of "replacing" a jar on maven with another
> jar.
> > It sounds like we can consider publishing cpu jars only going forward
> for a
> > new release.
> >
> > - Carin
> >
> > On Fri, May 29, 2020 at 1:32 PM Lausen, Leonard
>  > >
> > wrote:
> >
> > > On Fri, 2020-05-29 at 12:15 -0400, Carin Meier wrote:
> > > >
> > > > Going forward - we with future releases, we can have all users build
> > > their
> > > > own packages, just for the existing ones that are compliant on maven.
> > > >
> > > > On Fri, May 29, 2020 at 12:14 PM Carin Meier 
> > > wrote:
> > > >
> > > > > Leonard,
> > > > >
> > > > > Is this #2 Option still on the table?
> > > > >
> > > > >  2) Ask the Infra team to delete all MXNet GPU releases on
> > > > > > repository.apache.org and provide replacement releases without
> > > > > libgfortran.so
> > > > > > and other potentially Category-X files (I found libmkl_ml.so in
> one
> > > of
> > > > > the
> > > > > > JARs..)
> > > > >
> > > > > It seems like it would be a better solution than deleting ALL of
> > them,
> > > if
> > > > > the CPU ones are still valid and adhere to licensing.
> > > > > At least, we would break fewer users.
> > > > >
> > > > > - Carin
> > >
> > > Yes, this is a valid option. Just to clarify, the existing CPU releases
> > > don't
> > > adhere to the ASF policy. But MXNet project could create new, compliant
> > CPU
> > > releases and upload them to repository.apache.org. Finding a way to do
> > > this for
> > > the existing 1.x releases would also establish a path forward to
> continue
> > > creating such JARs for upcoming releases.
> > >
> >
>

Re: Requesting Slack Access

[Chaitanya Bapat]

Which email are you referring to?
As far as the email requesting access, I already replied to that and can
verify that you have been added as a member to the slack channel.

Thanks
Chai

On Fri, 29 May 2020 at 21:02, Bishal Saha  wrote:

> I did sent an email but didn’t get any response.
> Can anyone help me!
>


-- 
*Chaitanya Prakash Bapat*
*+1 (973) 953-6299*

[image: https://www.linkedin.com//in/chaibapat25]
[image: https://www.facebook.com/chaibapat]
[image:
https://twitter.com/ChaiBapchya] [image:
https://www.linkedin.com//in/chaibapat25]