[ANNOUNCE] Release Apache MXNet (incubating) version 1.7.0

[Chen, Ciyong]

Dear all,



The Apache MXNet (incubating) community is happy to announce Apache MXNet 
(incubating) version 1.7.0!



Apache MXNet (incubating) is a deep learning framework designed for both 
efficiency and flexibility. It allows you to mix symbolic and imperative 
programming to maximize efficiency and productivity.



A full list of the changes in this release can be found in the release notes:

https://cwiki.apache.org/confluence/display/MXNET/1.7.0+Release+Notes



A link to the download page can be found here:

http://mxnet.incubator.apache.org/get_started/download



To build from source and experiment with various compile-time configuration 
options, use this link to get the instructions:

http://mxnet.incubator.apache.org/get_started



The release tag:

https://github.com/apache/incubator-mxnet/tree/1.7.0



MXNet Resources

- Our discussion forum (https://github.com/apache/incubator-mxnet/discussions)

- MXNet dev mailing list 
(https://lists.apache.org/list.html?d...@mxnet.apache.org)

- StackOverflow mxnet tag (https://stackoverflow.com/questions/tagged/mxnet)

- MXNet website (https://mxnet.incubator.apache.org)

- Follow MXNet Development on Github 
(https://github.com/apache/incubator-mxnet/issues)

- MXNet Confluence Wiki for Developers 
(https://cwiki.apache.org/confluence/display/MXNET)

- Apache Slack #mxnet Channel (https://the-asf.slack.com/archives/C7FN4FCP9)



Social Media

- Apache MXNet on Twitter (https://twitter.com/apachemxnet)

- Contributor and user blogs about MXNet (https://medium.com/apache-mxnet)

- Discuss MXNet on r/mxnet 
(https://www.reddit.com/r/mxnet)

- Apache MXNet YouTube channel (https://www.youtube.com/apachemxnet)

- Apache MXNet on LinkedIn (https://www.linkedin.com/company/apache-mxnet)



For more information on Apache MXNet (incubating), please see:

https://mxnet.incubator.apache.org/





Best regards,

Apache MXNet (incubating) Team

___

DISCLAIMER:

Apache MXNet (incubating) is an effort undergoing incubation at The Apache 
Software Foundation (ASF), sponsored by the name of Apache Incubator PMC. 
Incubation is required of all newly accepted projects until a further review 
indicates that the infrastructure, communications, and decision making process 
have stabilized in a manner consistent with other successful ASF projects. 
While incubation status is not necessarily a reflection of the completeness or 
stability of the code, it does indicate that the project has yet to be fully 
endorsed by the ASF.

https://cwiki.apache.org/confluence/x/BINjB

[RESULTS] [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Chen, Ciyong]

Dear Community,

The voting for releasing Apache MXNet (incubating) 1.7.0.rc1 has passed with 5 
+1 votes (3 binding) and no 0 or -1 votes.
+1 votes:
* Michael Wall / binding
* Jason Dai / binding
* Tianqi Chen / binding
* Sheng Zha

* Xingjian Shi

Vote thread can be found at:
https://lists.apache.org/thread.html/r3ef29e05e4313096dbe0fdf03dbf342f326e6f7f22a2bc0fa41971a0%40%3Cgeneral.incubator.apache.org%3E

Thanks everyone for taking the time to review and vote for the release!
We will continue the rest of release process and send out the announcement 
email in the coming days.

Thanks,
Ciyong Chen

RE: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Chen, Ciyong]

Hi Jason,
Thank you for your time to check and vote on this.

Hi IPMC and community,
We've got two binding votes, and now we're looking forward to one more binding 
votes for this release, please help on this, many thanks!!

Regards,
-Ciyong

-Original Message-
From: Jason Dai  
Sent: Wednesday, August 19, 2020 10:16 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

 +1 (binding)


I checked:

- Incubating in name

- Signatures and hashes

- Disclaimer, LICENSE and NOTICE


Thanks,

-Jason

On Tue, Aug 18, 2020 at 6:25 PM Michael Wall  wrote:

> Thanks for the follow up Ciyong.  You are right, -vv did not enable 
> verbose. If I had used -VV (with capital V's) I would have gotten 
> output.
>
> Good luck on the vote.
>
> Mike
>
> On Tue, Aug 18, 2020 at 2:43 AM Chen, Ciyong 
> wrote:
> >
> > Hi Michael,
> >
> > Thank you for your time to review and vote.
> >
> > Regarding your questions:
> > > - Does anything with mshadow need to change now that it has passed
> clearance.
> > From source code release perspective, I don't think there's anything 
> > we
> need to change as mshadow is already in the code base with the correct 
> license header. CC @Sheng to see if any comments.
> >
> > > - I tried running tests a couple of ways after the build I build 
> > > but
> they just hung for 15 min before I control-c'd them.  Maybe I didn't 
> wait long enough, but there was no indication anything was running.
> > The test suite contains lots of test cases which will be very time
> consuming, " ctest -vv" doesn't enable the verbose output thus looks 
> like it hung as no output on the terminal.
> > By using "ctest --verbose" which turns on the verbose and will give 
> > more
> details for all the test cases.
> > Currently, the entire test suite will run through many different
> configurations of hardware and docker image via CI pipeline.
> >
> > Thanks,
> > -Ciyong
> >
> > -Original Message-
> > From: Michael Wall 
> > Sent: Tuesday, August 18, 2020 9:54 AM
> > To: general@incubator.apache.org
> > Subject: Re: [VOTE] Release Apache MXNet (incubating) version 
> > 1.7.0.rc1
> >
> > +1 from me
> >
> > Checked
> > - signatures
> > - incubating in name
> > - License, Notice and Disclaimer
> > - Compiled from source with CPP bindings using
> https://mxnet.apache.org/versions/1.6/get_started/build_from_source#in
> stall-mxnet-for-python
> ,
> > https://mxnet.apache.org/versions/1.6/get_started/cpp_setup and
> https://github.com/apache/incubator-mxnet/blob/1.7.0.rc1/config/linux.
> cmake
> >
> > Couple of questions
> > - Does anything with mshadow need to change now that it has passed
> clearance.
> > - I tried running tests a couple of ways after the build I build but
> they just hung for 15 min before I control-c'd them.  Maybe I didn't 
> wait long enough, but there was no indication anything was running.
> >
> > Here is the run
> >
> > ```
> > [0/1] Running tests...
> > Test project
> /home/mikewall/Desktop/mxnet-1.7.0/apache-mxnet-src-1.7.0.rc1-incubati
> ng/build
> > Start 1: AllTestsInmxnetUnitTests
> > ^Cninja: build stopped: interrupted by user.
> > ```
> >
> > And here is my history fwiw
> >
> > ```
> > sudo apt-get install -y build-essential git ninja-build ccache
> libopenblas-dev libopencv-dev cp config/linux.cmake config.cmake rm 
> -rf build cmake -S. -Bbuild -DUSE_CPP_PACKAGE=1 
> -DCMAKE_BUILD_TYPE=Release -GNinja cmake --build build cmake --build 
> build --target test cd build && ctest -vv ```
> >
> > On Mon, Aug 17, 2020 at 2:27 PM Sheng Zha  wrote:
> > >
> > > Hi Justin,
> > >
> > > Since the blocking issue has been resolved, would you mind 
> > > changing
> your vote? Thanks.
> > >
> > > Regards,
> > > Sheng
> > >
> > > On 2020/07/26 01:27:39, Justin Mclean 
> wrote:
> > > > Hi,
> > > >
> > > > -1 (binding) as this release contains code that hasn’t gone 
> > > > though
> IP clearance (mshadow).
> > > >
> > > > I checked:
> > > > - incubating in name
> > > > - disclaimer exists
> > > > - LICENSE and NOTICE have improved but I did not do an 
> > > > exhaustive check
> > > > -  No unexpected binary file
> > > > - ASF files have ASF headers
> > > > - unable to compile from source
> > > >
> &g

RE: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Chen, Ciyong]

Hi Michael,

Thank you for your time to review and vote.

Regarding your questions:
> - Does anything with mshadow need to change now that it has passed clearance.
From source code release perspective, I don't think there's anything we need to 
change as mshadow is already in the code base with the correct license header. 
CC @Sheng to see if any comments.

> - I tried running tests a couple of ways after the build I build but they 
> just hung for 15 min before I control-c'd them.  Maybe I didn't wait long 
> enough, but there was no indication anything was running.
The test suite contains lots of test cases which will be very time consuming, " 
ctest -vv" doesn't enable the verbose output thus looks like it hung as no 
output on the terminal. 
By using "ctest --verbose" which turns on the verbose and will give more 
details for all the test cases. 
Currently, the entire test suite will run through many different configurations 
of hardware and docker image via CI pipeline.

Thanks,
-Ciyong

-Original Message-
From: Michael Wall  
Sent: Tuesday, August 18, 2020 9:54 AM
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

+1 from me

Checked
- signatures
- incubating in name
- License, Notice and Disclaimer
- Compiled from source with CPP bindings using 
https://mxnet.apache.org/versions/1.6/get_started/build_from_source#install-mxnet-for-python,
https://mxnet.apache.org/versions/1.6/get_started/cpp_setup and 
https://github.com/apache/incubator-mxnet/blob/1.7.0.rc1/config/linux.cmake

Couple of questions
- Does anything with mshadow need to change now that it has passed clearance.
- I tried running tests a couple of ways after the build I build but they just 
hung for 15 min before I control-c'd them.  Maybe I didn't wait long enough, 
but there was no indication anything was running.

Here is the run

```
[0/1] Running tests...
Test project 
/home/mikewall/Desktop/mxnet-1.7.0/apache-mxnet-src-1.7.0.rc1-incubating/build
Start 1: AllTestsInmxnetUnitTests
^Cninja: build stopped: interrupted by user.
```

And here is my history fwiw

```
sudo apt-get install -y build-essential git ninja-build ccache libopenblas-dev 
libopencv-dev cp config/linux.cmake config.cmake rm -rf build cmake -S. -Bbuild 
-DUSE_CPP_PACKAGE=1 -DCMAKE_BUILD_TYPE=Release -GNinja cmake --build build 
cmake --build build --target test cd build && ctest -vv ```

On Mon, Aug 17, 2020 at 2:27 PM Sheng Zha  wrote:
>
> Hi Justin,
>
> Since the blocking issue has been resolved, would you mind changing your 
> vote? Thanks.
>
> Regards,
> Sheng
>
> On 2020/07/26 01:27:39, Justin Mclean  wrote:
> > Hi,
> >
> > -1 (binding) as this release contains code that hasn’t gone though IP 
> > clearance (mshadow).
> >
> > I checked:
> > - incubating in name
> > - disclaimer exists
> > - LICENSE and NOTICE have improved but I did not do an exhaustive 
> > check
> > -  No unexpected binary file
> > - ASF files have ASF headers
> > - unable to compile from source
> >
> > It also seems that this code may have been released before the 
> > PPMC/IPMC vote is over see [1][2][3][4] There are also branding and 
> > trademark issue with this site [5] This is in addition to the issues 
> > previously noted with releases, branding and trademarks.[6]
> >
> > Thanks,
> > Justin
> >
> >
> > 1. https://sourceforge.net/projects/apache-mxnet.mirror/
> > 2. 
> > https://repo.gradle.org/gradle/simple/repo/ai/djl/mxnet/mxnet-native
> > -mkl/1.7.0-b/ 3. https://mvnrepository.com/artifact/ai.djl.mxnet
> > 4. 
> > https://aur.archlinux.org/packages/?O=0=nd=mxnet=v=d=
> > 50_Search=Go
> > 5. https://djl.ai
> > 6. https://jira.apache.org/jira/browse/INCUBATOR-253
> > 
> > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: RE: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Chen, Ciyong]

Hello community and IPMC,

We're pending on the binding votes to move forward, appreciated if anyone could 
help on this release. Thanks!

Regards,
Ciyong

-Original Message-
From: Sheng Zha  
Sent: Friday, August 14, 2020 1:07 PM
To: general@incubator.apache.org
Subject: Re: RE: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

+1 carried from vote on dev@ [1].

-sz

[1] 
https://lists.apache.org/thread.html/r28fbcad28a0a29c1b40edf4d3898d09946801b663cf103ad59a9bce2%40%3Cdev.mxnet.apache.org%3E

On 2020/08/11 05:21:39, "Chen, Ciyong"  wrote: 
> Thank you Sheng and all for removing the blocker for the release.
> 
> Dear Community,
> 
> As the vote is resumed, please take your time to verify and vote on the 
> upcoming release for Apache MXNet(incubating).
> I copied the content from the original vote mail for your reference.
> 
> This is a call for a releasing Apache MXNet (incubating) 1.7.0, release 
> candidate 1.
> 
> Apache MXNet (incubating) community has voted and approved the release.
> 
> Vote thread:
> https://lists.apache.org/thread.html/r525a961a10f69bdfb255c64f0be0589b
> b70efdd880c1be87c81c0c06%40%3Cdev.mxnet.apache.org%3E
> 
> Result thread:
> https://lists.apache.org/thread.html/rbd53614ca01f714d00097a02d9068952
> 11336a14ce0e083865cf5144%40%3Cdev.mxnet.apache.org%3E
> 
> The source tarball, including signatures, digests, etc. can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.7.0.rc1
> 
> The tag to be voted upon is 1.7.0.rc1:
> https://github.com/apache/incubator-mxnet/releases/tag/1.7.0.rc1
> 
> The release hash is 64f737cdd59fe88d2c5b479f25d011c5156b6a8a:
> https://github.com/apache/incubator-mxnet/commit/64f737cdd59fe88d2c5b4
> 79f25d011c5156b6a8a
> 
> KEYS file available:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
> 
> For information about the contents of this release, see:
> https://cwiki.apache.org/confluence/display/MXNET/1.7.0+Release+Notes
> 
> The vote will be open for 72 hours.
> [ ] +1 release this package as # [ ] +0 no opinion [ ] -1 do not 
> release this package because...
> 
> Best regards,
> Ciyong Chen
> 
> -Original Message-
> From: Sheng Zha 
> Sent: Tuesday, August 11, 2020 3:36 AM
> To: general@incubator.apache.org
> Subject: Re: [VOTE] Release Apache MXNet (incubating) version 
> 1.7.0.rc1
> 
> Hi,
> 
> Since the IP clearance for MShadow has passed [1] and third-party release 
> issues are either resolved or tracked in INCUBATOR-253, let's resume this 
> vote.
> 
> Here's my +1 carried from vote on dev@ [2].
> 
> [1]
> https://lists.apache.org/thread.html/rd6ad9de26c0f523db4264e2fe46b0db5
> e5ad6c5f614b7152352161ab%40%3Cgeneral.incubator.apache.org%3E
> [2]
> https://lists.apache.org/thread.html/r28fbcad28a0a29c1b40edf4d3898d099
> 46801b663cf103ad59a9bce2%40%3Cdev.mxnet.apache.org%3E
> 
> On Tue, Aug 4, 2020 at 8:55 PM David Nalley  wrote:
> 
> > On Tue, Aug 4, 2020 at 11:01 PM Justin Mclean 
> > 
> > wrote:
> >
> > > Hi,
> > >
> > > >  1.  Change all MXNet to Apache MXNet (incubating) from 
> > > > documentation
> > > where it necessary
> > > >  2.  Change maven package description ” MXNet Engine Adapter for DJL”
> > > to  "Deep Java Library (DJL) Engine Adapter for Apache MXNet" for 
> > > clarification
> > >
> > > Thanks for doing that. ASF generally prefers “powdered by” so I 
> > > would double check with trademarks (trademarks@a.o) if this is acceptable 
> > > use.
> > > [1]
> > >
> >
> > The brand management committee has no issue with "Deep Java Library
> > (DJL) Engine Adapter for Apache MXnet" as it's nominative use[1] and 
> > has been documented as such.
> >
> >
> > [1] https://www.apache.org/foundation/marks/pmcs#other
> >
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Chen, Ciyong]

Thank you Sheng and all for removing the blocker for the release.

Dear Community,

As the vote is resumed, please take your time to verify and vote on the 
upcoming release for Apache MXNet(incubating).
I copied the content from the original vote mail for your reference.

This is a call for a releasing Apache MXNet (incubating) 1.7.0, release 
candidate 1.

Apache MXNet (incubating) community has voted and approved the release.

Vote thread:
https://lists.apache.org/thread.html/r525a961a10f69bdfb255c64f0be0589bb70efdd880c1be87c81c0c06%40%3Cdev.mxnet.apache.org%3E

Result thread:
https://lists.apache.org/thread.html/rbd53614ca01f714d00097a02d906895211336a14ce0e083865cf5144%40%3Cdev.mxnet.apache.org%3E

The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.7.0.rc1

The tag to be voted upon is 1.7.0.rc1:
https://github.com/apache/incubator-mxnet/releases/tag/1.7.0.rc1

The release hash is 64f737cdd59fe88d2c5b479f25d011c5156b6a8a:
https://github.com/apache/incubator-mxnet/commit/64f737cdd59fe88d2c5b479f25d011c5156b6a8a

KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS

For information about the contents of this release, see:
https://cwiki.apache.org/confluence/display/MXNET/1.7.0+Release+Notes

The vote will be open for 72 hours.
[ ] +1 release this package as # [ ] +0 no opinion [ ] -1 do not 
release this package because...

Best regards,
Ciyong Chen

-Original Message-
From: Sheng Zha  
Sent: Tuesday, August 11, 2020 3:36 AM
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

Hi,

Since the IP clearance for MShadow has passed [1] and third-party release 
issues are either resolved or tracked in INCUBATOR-253, let's resume this vote.

Here's my +1 carried from vote on dev@ [2].

[1]
https://lists.apache.org/thread.html/rd6ad9de26c0f523db4264e2fe46b0db5e5ad6c5f614b7152352161ab%40%3Cgeneral.incubator.apache.org%3E
[2]
https://lists.apache.org/thread.html/r28fbcad28a0a29c1b40edf4d3898d09946801b663cf103ad59a9bce2%40%3Cdev.mxnet.apache.org%3E

On Tue, Aug 4, 2020 at 8:55 PM David Nalley  wrote:

> On Tue, Aug 4, 2020 at 11:01 PM Justin Mclean 
> 
> wrote:
>
> > Hi,
> >
> > >  1.  Change all MXNet to Apache MXNet (incubating) from 
> > > documentation
> > where it necessary
> > >  2.  Change maven package description ” MXNet Engine Adapter for DJL”
> > to  "Deep Java Library (DJL) Engine Adapter for Apache MXNet" for 
> > clarification
> >
> > Thanks for doing that. ASF generally prefers “powdered by” so I 
> > would double check with trademarks (trademarks@a.o) if this is acceptable 
> > use.
> > [1]
> >
>
> The brand management committee has no issue with "Deep Java Library 
> (DJL) Engine Adapter for Apache MXnet" as it's nominative use[1] and 
> has been documented as such.
>
>
> [1] https://www.apache.org/foundation/marks/pmcs#other
>

RE: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Chen, Ciyong]

Hi Justin,

Thanks for your valuable inputs, then I will hold on the current rc1 release 
and continue the rest of release process (vote on general) when the issues are 
addressed.

Thanks,
Ciyong

-Original Message-
From: Justin Mclean  
Sent: Monday, July 27, 2020 8:18 AM
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

Hi,

> It seems that most of the concerns are branding/trademark/legal issues from 
> those third-party projects which relies on MXNet and the AWS marketplace (or 
> MXNet's downstream projects), which could be tracked separately and improved 
> continually to 100% meet the requirement of incubating Apache project, so 
> probably not affect this source release and can be addressed later.

It’s not seperate as you release candidates being distributed to users. I still 
want to know why release candidates are being released in this way, in 
particular by companies where there are MXnet PPMC members. What steps will the 
PPMC will take to stop this from happening in the future?

> For mshadow, I'm wondering if completing the IP clearance process is the only 
> mandatory requirement for this source code release, then we might need to 
> hold on the current release process until it's finished

It will need to be completed before this can be released.

Thanks,
Justin


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Chen, Ciyong]

Hi Justin,

Thanks for your time to review and vote on this release.

It seems that most of the concerns are branding/trademark/legal issues from 
those third-party projects which relies on MXNet and the AWS marketplace (or 
MXNet's downstream projects), which could be tracked separately and improved 
continually to 100% meet the requirement of incubating Apache project, so 
probably not affect this source release and can be addressed later.

For mshadow, I'm wondering if completing the IP clearance process is the only 
mandatory requirement for this source code release, then we might need to hold 
on the current release process until it's finished, or we can address all these 
concerns step by step as the MXNet project evolving and move forward with the 
current release?
Thanks!

Regards,
Ciyong

-Original Message-
From: Justin Mclean  
Sent: Sunday, July 26, 2020 1:35 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

Hi,

> For mshadow, it is a third-party component that MXNet has been relying 
> on since the initial contribution to MXNet. It has been included in 
> previous releases since its category-A license allows us to do so. For 
> this release, we are still releasing it as a third-party module, as 
> evidenced by the content of our LICENSE file [1].

The code has been donated via a software grant  [1] and the IP clearance 
process not followed. [2] 

You'll note it states here [3] "No releases are possible until the provenance 
of all the code to be release has been clearly established and the relevant 
paperwork filed with Apache.” and "The Incubator PMC must approve the 
clearance."

> For 2-5, DJL is a third-party project that depends on MXNet, not a 
> component of MXNet. We PPMC don't own or manage those artifacts.

Why are they distributing release candidates? This seems highly unusual. Are 
any members of the PPMC members are involved in this? I believe some of them 
are employed by this company.

> Finally, it would be great if you could help clarify what compilation 
> problem you had.

I’m on OSX and don’t have gcc set up correctly, clang fails to compile as it 
encounters an unknown option. So it’s probably just my setup, however I’m not 
even sure of OSX is a supported platform.

The PPMC needs to be more active in sorting out its branding and trademark 
issues. [6] [7] 

Here’s another branding/trademark issue [8] and anther [9] and another [10]. If 
I search for "MXNet" here [11] I get 30 hits and some issues. I believe your 
project has PPMC members from the companies listed here?

It needs to be 100% clear in all cases where this occurs that MXNet is an 
incubating Apache project and those releases are not Apache ones and in some 
case not under the Apache license. These 3rd party releases can’t be called 
MXNet [4] if there is any category X code inside them or they have licensing 
conditions that are not compatible with the Apache license. They they can only 
be called NXNet if they are based on released code, with nothing else added. [5]

Thanks,
Justin

1. 
https://lists.apache.org/thread.html/rd9ff74896d1faca59b74ad45748bcfd417bec73de5ce43e57bd9dc98%40%3Cprivate.mxnet.apache.org%3E
2. https://incubator.apache.org/ip-clearance/
3. https://incubator.apache.org/guides/ip_clearance.html
4. https://www.apache.org/foundation/marks/faq/#products
5. http://www.apache.org/legal/release-policy.html#compiled-packages
6. https://www.apache.org/foundation/marks/responsibility
7. https://www.apache.org/foundation/marks/responsibility#independent
8. https://aws.amazon.com/marketplace/pp/NVIDIA-MXNet-by-NVIDIA/B07KLFW54D
9. 
https://aws.amazon.com/marketplace/pp/prodview-yex2xx5kgdhea?qid=1595741035764=0-1_=srh_res_product_title
10. 
https://aws.amazon.com/marketplace/pp/B07YW8HVLD?qid=1595741035764=0-4_=srh_res_product_title
11. 
https://aws.amazon.com/marketplace/search/results?x=0=0=%22MXNet
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache MXNet (incubating) version 1.7.0.rc1

[Chen, Ciyong]

Dear community,

This is a call for a releasing Apache MXNet (incubating) 1.7.0, release
candidate 1.

Apache MXNet (incubating) community has voted and approved the release.

Vote thread:
https://lists.apache.org/thread.html/r525a961a10f69bdfb255c64f0be0589bb70efdd880c1be87c81c0c06%40%3Cdev.mxnet.apache.org%3E

Result thread:
https://lists.apache.org/thread.html/rbd53614ca01f714d00097a02d906895211336a14ce0e083865cf5144%40%3Cdev.mxnet.apache.org%3E

The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.7.0.rc1

The tag to be voted upon is 1.7.0.rc1:
https://github.com/apache/incubator-mxnet/releases/tag/1.7.0.rc1

The release hash is 64f737cdd59fe88d2c5b479f25d011c5156b6a8a:
https://github.com/apache/incubator-mxnet/commit/64f737cdd59fe88d2c5b479f25d011c5156b6a8a

KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS

For information about the contents of this release, see:
https://cwiki.apache.org/confluence/display/MXNET/1.7.0+Release+Notes

The vote will be open for 72 hours.
[ ] +1 release this package as #
[ ] +0 no opinion
[ ] -1 do not release this package because...

Best regards,
Ciyong Chen

RE: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: [MENTORS] PPMC case-by-case decision for major modifications of third-party work guidance

[Chen, Ciyong]

Thanks Leonard for the confirmation, I will update the related files based on 
the consensus. 

Regards,
-Ciyong

-Original Message-
From: Leonard Lausen  
Sent: Wednesday, June 24, 2020 2:24 AM
To: d...@mxnet.incubator.apache.org; general@incubator.apache.org
Subject: Re: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: 
[MENTORS] PPMC case-by-case decision for major modifications of third-party 
work guidance

Hi Ciyong,

the consensus passed, so we should proceed according to the consensus.

Thank you
Leonard

On Tue, 2020-06-23 at 09:04 +, Chen, Ciyong wrote:
> Hi all,
> 
> I'm wondering if there's any further concerns for this "72 hours lazy 
> consensus"?
> Shall we continue with the option of "I believe PPMC would prefer to 
> put the ASF header on top of the file (ie. 2 headers)"
> 
> Thanks,
> -Ciyong
> 
> -Original Message-
> From: Leonard Lausen 
> Sent: Tuesday, June 16, 2020 7:06 AM
> To: d...@mxnet.incubator.apache.org; general@incubator.apache.org
> Subject: Re: [DISCUSS] When to add Apache Headers to Third Party Code 
> [WAS]
> Re: [MENTORS] PPMC case-by-case decision for major modifications of 
> third- party work guidance
> 
> Thank you everyone for your valuable advice.
> 
> > so if you did want to avoid including the license in your releases 
> > you would either need to rely on the file as an external dependency 
> > or completely reimplement the functionality not deriving it from 
> > this file.
> 
> Including the BSD-3 style license in releases wouldn't be a problem, 
> as it's compatible with Apache License 2. As there are substantial 
> changes, I believe PPMC would prefer to put the ASF header on top of 
> the file (ie. 2 headers) [72 hours lazy consensus if there are no 
> concerns]. We still need to declare all the numpy einsum derived files 
> in the LICENSE and fix the inconsistency that ASF header was removed 
> in src/operator/numpy/np_einsum_op-inl.h but remains in 
> src/operator/numpy/np_einsum_path_op-inl.h
> 
> Related: As PPMC strives to provide partial API compatibility with 
> NumPy in MXNet 2 based on the NumPy Array Function Protocol [1], could 
> you clarify if these MXNet operators should be considered derived from 
> NumPy (thus warranting the BSD-3 style license headers) solely based 
> on integrating with the NumPy API and providing compatible operators? 
> Or only (as in the einsum case above), if the actual implementation 
> was derived from NumPy's implementation. I believe it's the latter, but 
> please clarify if that's wrong.
> 
> Should ASF update the "Do not add the standard Apache License header 
> to the top of third-party source files." at [2]? This sentence was the 
> motivation to open this discussion thread, and according to the 
> current consensus here is "incomplete". How about adding an "unless 
> the third-party source file contains major modifications by ASF" to clarify?
> 
> Thank you
> Leonard
> 
> [1]: https://numpy.org/neps/nep-0018-array-function-protocol.html
> [2]: https://www.apache.org/legal/src-headers.html#3party
> 
> On Mon, 2020-06-15 at 09:36 -0400, John D. Ament wrote:
> > On Sat, Jun 13, 2020 at 2:19 PM Bob Paulin  wrote:
> > 
> > > Hi,
> > > 
> > > I agree there does not appear to be consensus on when it's 
> > > appropriate to add Apache License Headers to Third Party code 
> > > across projects.  Here is Justin's email that request the Apache 
> > > Headers removed [1]
> > > 
> > > 
> > > 
> > > - file copyright  NumPy Developers [6] this file look to 
> > > incorrectly have an ASF header on it 
> > > 6. ./src/operator/numpy/np_einsum_path_op-inl.h
> > > 
> > > 
> > > We want to make the choice that will be most sustainable for the 
> > > project and most correct for the situation.
> > > 
> > > Based on the emails I linked in the prior email it does seem like 
> > > the cases where dual headers are appropriate is when there are 
> > > Major Modifications.  In the case of
> > > 
> > > np_einsum_path_op-inl.h
> > > 
> > > The file is derived from the implementation in Numpy [2].  If the 
> > > implementation in Numpy changes will this file change?  If so then 
> > > the community will be tasked with continuing to re-port the 
> > > changes over that is always based on Numpy so it may be more 
> > > appropriate to just keep the Numpy license.
> > > 
> > > Will MXNet likely evolve this file in a way that it's no longer 
> > > resembles the Numpy implementation (Maj

RE: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: [MENTORS] PPMC case-by-case decision for major modifications of third-party work guidance

[Chen, Ciyong]

Hi all,

I'm wondering if there's any further concerns for this "72 hours lazy 
consensus"?
Shall we continue with the option of "I believe PPMC would prefer to put the 
ASF header on top of the file (ie. 2 headers)"

Thanks,
-Ciyong

-Original Message-
From: Leonard Lausen  
Sent: Tuesday, June 16, 2020 7:06 AM
To: d...@mxnet.incubator.apache.org; general@incubator.apache.org
Subject: Re: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: 
[MENTORS] PPMC case-by-case decision for major modifications of third-party 
work guidance

Thank you everyone for your valuable advice.

> so if you did want to avoid including the license in your releases you 
> would either need to rely on the file as an external dependency or 
> completely reimplement the functionality not deriving it from this 
> file.

Including the BSD-3 style license in releases wouldn't be a problem, as it's 
compatible with Apache License 2. As there are substantial changes, I believe 
PPMC would prefer to put the ASF header on top of the file (ie. 2 headers) [72 
hours lazy consensus if there are no concerns]. We still need to declare all 
the numpy einsum derived files in the LICENSE and fix the inconsistency that 
ASF header was removed in src/operator/numpy/np_einsum_op-inl.h but remains in 
src/operator/numpy/np_einsum_path_op-inl.h

Related: As PPMC strives to provide partial API compatibility with NumPy in 
MXNet 2 based on the NumPy Array Function Protocol [1], could you clarify if 
these MXNet operators should be considered derived from NumPy (thus warranting 
the BSD-3 style license headers) solely based on integrating with the NumPy API 
and providing compatible operators? Or only (as in the einsum case above), if 
the actual implementation was derived from NumPy's implementation. I believe 
it's the latter, but please clarify if that's wrong.

Should ASF update the "Do not add the standard Apache License header to the top 
of third-party source files." at [2]? This sentence was the motivation to open 
this discussion thread, and according to the current consensus here is 
"incomplete". How about adding an "unless the third-party source file contains 
major modifications by ASF" to clarify?

Thank you
Leonard

[1]: https://numpy.org/neps/nep-0018-array-function-protocol.html
[2]: https://www.apache.org/legal/src-headers.html#3party

On Mon, 2020-06-15 at 09:36 -0400, John D. Ament wrote:
> On Sat, Jun 13, 2020 at 2:19 PM Bob Paulin  wrote:
> 
> > Hi,
> > 
> > I agree there does not appear to be consensus on when it's 
> > appropriate to add Apache License Headers to Third Party code across 
> > projects.  Here is Justin's email that request the Apache Headers 
> > removed [1]
> > 
> > 
> > 
> > - file copyright  NumPy Developers [6] this file look to incorrectly 
> > have an ASF header on it 
> > 6. ./src/operator/numpy/np_einsum_path_op-inl.h
> > 
> > 
> > We want to make the choice that will be most sustainable for the 
> > project and most correct for the situation.
> > 
> > Based on the emails I linked in the prior email it does seem like 
> > the cases where dual headers are appropriate is when there are Major 
> > Modifications.  In the case of
> > 
> > np_einsum_path_op-inl.h
> > 
> > The file is derived from the implementation in Numpy [2].  If the 
> > implementation in Numpy changes will this file change?  If so then 
> > the community will be tasked with continuing to re-port the changes 
> > over that is always based on Numpy so it may be more appropriate to 
> > just keep the Numpy license.
> > 
> > Will MXNet likely evolve this file in a way that it's no longer 
> > resembles the Numpy implementation (Major Modification)?  If so it 
> > may be better to keep the Apache Header as going forward the file 
> > will represent the work of the MXNet community not that of Numpy.
> > 
> 
> Keeping the (what appears to be) BSD-3 style license is perfectly fine 
> and is in fact what the NumPy license says to do.  We would only 
> change the license from the NumPy license to ALv2 if an SGA or ICLA is 
> received from all contributors historically on this file.  No matter 
> how drastic of modifications the MxNet community makes to it, it would 
> always be NumPy licensed; so if you did want to avoid including the 
> license in your releases you would either need to rely on the file as 
> an external dependency or completely reimplement the functionality not 
> deriving it from this file.  Whether or not the MxNet community 
> imports upstream changes or not is up to them, but either way you have a 
> derived work here.
> 
> John
> 
> 
> > Hopefully the above helps clarify my perspective on how to determine 
> > case by case.  I don't see the dual license state as the simpler 
> > case in all situations.  I don't believe you would have to get the 
> > original committer to relicense the file to you in order to remove 
> > the additional license.  I believe the PPMC has all the authority it 
> > needs 

RE: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: [MENTORS] PPMC case-by-case decision for major modifications of third-party work guidance

[Chen, Ciyong]

Thanks a lot for your valuable input Bob, John, Justin, Leonard.

As it’s still not finalized on how to handle such dual license issue from the 
discussion.
In addition, Justin stated that converting the code from one program language 
to another one should **NOT** be considered as a major modification.
And based on the statement #3 and #4 from 
https://www.apache.org/legal/src-headers.html#3party
> 3.Do not add the standard Apache License header to the top of third-party 
> source files.
> 4.Minor modifications/additions to third-party source files should typically 
> be licensed under the same terms as the rest of the rest of the third-party 
> source for convenience.

So it seems more appropriate to remove the ASF header and just keep the Numpy 
license header and claim it at the top level LICENSE, or do we need to vote on 
the two options as Bob stated below, thanks!
>1) Numpy License Headers Only
> 2) Apache Header with Numpy License Header (keep the license header as is now)

Best Regards,
-Ciyong

From: Bob Paulin 
Sent: Monday, June 15, 2020 11:38 PM
To: d...@mxnet.incubator.apache.org; Chen, Ciyong ; 
lau...@apache.org; d...@mxnet.apache.org; general@incubator.apache.org
Subject: Re: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: 
[MENTORS] PPMC case-by-case decision for major modifications of third-party 
work guidance


Hi,

I should be more clear.  The 2 options in the case below is

1) Numpy License Headers Only

2) Apache Header with Numpy License Header

Re-reading my original reply does sound like I'm saying the Numpy license 
should be removed in the case for the Apache License Headers from the file.  
This was not my intent.  John states it more clearly in his reply that removal 
of the Numpy License requires additional steps.



- Bob
On 6/15/2020 3:05 AM, Chen, Ciyong wrote:

Hi Bob, Leonard,



Thanks for the elaboration/guideline on the dual license issue.

May I have the conclusion as below based on Bob’s direction/suggestion:





  *   If there’s no any different opinion or objection,  keep either origin 
Numpy license or ASF license but not dual, which depends on how MXNet’s source 
file evolves when the origin Numpy files changes? And the PPMC has all the 
authority to change the file like removing the additional license if needed.



Please correct me if I mis-understand anything, and help to determine the best 
appropriate way to handle such case. Thanks!



Best Regards,

-Ciyong



From: Bob Paulin <mailto:b...@bobpaulin.com>

Sent: Sunday, June 14, 2020 2:20 AM

To: lau...@apache.org<mailto:lau...@apache.org>; 
d...@mxnet.apache.org<mailto:d...@mxnet.apache.org>; 
general@incubator.apache.org<mailto:general@incubator.apache.org>

Subject: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: 
[MENTORS] PPMC case-by-case decision for major modifications of third-party 
work guidance





Hi,



I agree there does not appear to be consensus on when it's appropriate to add 
Apache License Headers to Third Party code across projects.  Here is Justin's 
email that request the Apache Headers removed [1]







- file copyright  NumPy Developers [6] this file look to incorrectly have an 
ASF header on it







6. ./src/operator/numpy/np_einsum_path_op-inl.h







We want to make the choice that will be most sustainable for the project and 
most correct for the situation.



Based on the emails I linked in the prior email it does seem like the cases 
where dual headers are appropriate is when there are Major Modifications.  In 
the case of



np_einsum_path_op-inl.h



The file is derived from the implementation in Numpy [2].  If the 
implementation in Numpy changes will this file change?  If so then the 
community will be tasked with continuing to re-port the changes over that is 
always based on Numpy so it may be more appropriate to just keep the Numpy 
license.



Will MXNet likely evolve this file in a way that it's no longer resembles the 
Numpy implementation (Major Modification)?  If so it may be better to keep the 
Apache Header as going forward the file will represent the work of the MXNet 
community not that of Numpy.



Hopefully the above helps clarify my perspective on how to determine case by 
case.  I don't see the dual license state as the simpler case in all 
situations.  I don't believe you would have to get the original committer to 
relicense the file to you in order to remove the additional license.  I believe 
the PPMC has all the authority it needs to change the file.  I'd be interested 
to hear if this is a position that the rest of the Mentors/Incubator agree 
with.  I know Hen has been involved in some of the conversations in support of 
dual licenses.  Has this ever required escalation to an actual Lawyer in Legal? 
 Or have these determinations been low enough risk that we are comfortable with 
our PMC making best effort decisions based on the ASF guidelines?

RE: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: [MENTORS] PPMC case-by-case decision for major modifications of third-party work guidance

[Chen, Ciyong]

Hi Bob, Leonard,

Thanks for the elaboration/guideline on the dual license issue.
May I have the conclusion as below based on Bob’s direction/suggestion:


  *   If there’s no any different opinion or objection,  keep either origin 
Numpy license or ASF license but not dual, which depends on how MXNet’s source 
file evolves when the origin Numpy files changes? And the PPMC has all the 
authority to change the file like removing the additional license if needed.

Please correct me if I mis-understand anything, and help to determine the best 
appropriate way to handle such case. Thanks!

Best Regards,
-Ciyong

From: Bob Paulin 
Sent: Sunday, June 14, 2020 2:20 AM
To: lau...@apache.org; d...@mxnet.apache.org; general@incubator.apache.org
Subject: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: 
[MENTORS] PPMC case-by-case decision for major modifications of third-party 
work guidance


Hi,

I agree there does not appear to be consensus on when it's appropriate to add 
Apache License Headers to Third Party code across projects.  Here is Justin's 
email that request the Apache Headers removed [1]



- file copyright  NumPy Developers [6] this file look to incorrectly have an 
ASF header on it



6. ./src/operator/numpy/np_einsum_path_op-inl.h



We want to make the choice that will be most sustainable for the project and 
most correct for the situation.

Based on the emails I linked in the prior email it does seem like the cases 
where dual headers are appropriate is when there are Major Modifications.  In 
the case of

np_einsum_path_op-inl.h

The file is derived from the implementation in Numpy [2].  If the 
implementation in Numpy changes will this file change?  If so then the 
community will be tasked with continuing to re-port the changes over that is 
always based on Numpy so it may be more appropriate to just keep the Numpy 
license.

Will MXNet likely evolve this file in a way that it's no longer resembles the 
Numpy implementation (Major Modification)?  If so it may be better to keep the 
Apache Header as going forward the file will represent the work of the MXNet 
community not that of Numpy.

Hopefully the above helps clarify my perspective on how to determine case by 
case.  I don't see the dual license state as the simpler case in all 
situations.  I don't believe you would have to get the original committer to 
relicense the file to you in order to remove the additional license.  I believe 
the PPMC has all the authority it needs to change the file.  I'd be interested 
to hear if this is a position that the rest of the Mentors/Incubator agree 
with.  I know Hen has been involved in some of the conversations in support of 
dual licenses.  Has this ever required escalation to an actual Lawyer in Legal? 
 Or have these determinations been low enough risk that we are comfortable with 
our PMC making best effort decisions based on the ASF guidelines?



- Bob



[1] 
https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E

[2] https://github.com/numpy/numpy/blob/master/numpy/core/einsumfunc.py
On 6/12/2020 7:20 PM, Leonard Lausen wrote:

Thank you Bob for the elaboration. PPMC would like to minimize complexity,

that's why we ask for your recommendation.



If it's easiest to just keep the original license header, we can do that. Do we

need the contributor to re-license their contribution, or is the contribution

already available under both licenses as both license headers were included by

the contributor and the ASF header can simply be deleted?



Reading through the threads you referenced, there does not seem to be a strong

consensus in the ASF about how to handle this situation. For example, quoting

Roman Shaposhnik [2] in support of just putting 2 License Headers for

simplicity:



Hm. This is tricky, now that I re-read the language of the ASF license

header I'm not sure anymore. I *think* the language there should allow

you to slap said header on a compatible license code.



Besides, the alternative is much messier: every time somebody touches

that file he/she needs to decide whether it is time for an ASF header

or not.



I *think* (but I'd love for old-timers to chime in and correct me) that #3-5

were written from though-shall-not-fork-communities perspective.

Can we follow this approach (keep 2 License headers) for simplicity (assuming

removal of ASF header will require extra steps)?



With respect to einsumfunc.py [5] vs np_einsum_op.cc [6] if this is in

fact a port where the behavior was copied/derived directly from numpy I

could see that as supporting Justin's case that the Apache header should

be removed.  However that is just my opinion.

Which email of Justin are you referring to?



Best regards

Leonard





[1]: http://www.apache.org/legal/src-headers.html#purpose

[2]: