[RESULTS][VOTE] Release Apache MXNet (incubating) version 2.0.0.alpha.rc3

2021-03-23 Thread Leonard Lausen
Dear Community,

the voting for releasing Apache MXNet (incubating) 2.0.0.alpha.rc3 has
passed with 3 +1 votes (3 binding) and no 0 or -1 votes.

+1 votes:
* Furkan Kamaci
* David Meikle
* Juan Pan

Vote thread can be found at:
https://lists.apache.org/thread.html/r077feb5676477580f2309986baf75329a5d6e349e8f91c91399df488%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,
Leonard Lausen

-
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 2.0.0.alpha.rc3

2021-03-09 Thread Leonard Lausen
Dear community,

Please help us get out this alpha release by voting, so that it can be tested 
by the wider community outside the dev@ list.

Thanks!
Leonard

On 2021/02/24 20:39:35, Leonard Lausen  wrote: 
> Dear community,
> 
> This is a call for a releasing Apache MXNet (incubating) 2.0.0.alpha, release
> candidate 3. Note that this is an Alpha release, which represents our first
> project milestone on the road to MXNet 2 and is intended for bleeding-edge
> developers working outside the project. [1]
> 
> Apache MXNet (incubating) community has voted and approved the release.
> 
> Vote thread:
> https://lists.apache.org/thread.html/ra75a0530c12e23af681bbdbda2f1e6d1eb64db21334
> cda6aab0960ef%40%3Cdev.mxnet.apache.org%3E
> 
> Result thread:
> https://lists.apache.org/thread.html/r390ecf96b8ad19cc8934adaa0371325e77f3dc3d94578c2ea5e73c34%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/2.0.0.alpha.rc3/
> 
> The tag to be voted upon is v2.0.0.alpha.rc3:
> https://github.com/apache/incubator-mxnet/releases/tag/v2.0.0.alpha.rc3
> 
> The release hash is d82d19f700baa77ae577906f595b8562749852e8:
> https://github.com/apache/incubator-mxnet/commit/d82d19f700baa77ae577906f595b8562749852e8
> 
> KEYS file available:
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
> 
> For information about the contents of this release, see:
> https://github.com/apache/incubator-mxnet/issues/18931
> 
> The vote will be open for 7 days.
> 
> [ ] +1 release this package as 2.0.0.alpha
> [ ] +0 no opinion
> [ ] -1 do not release this package because...
> 
> Best regards,
> Leonard Lausen
> 
> 
> 
> -
> 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.8.0.rc3

2021-03-02 Thread Leonard Lausen
Thank you Paul for voting on the release. 

On 2021/03/02 03:53:26, Paul King  wrote: 

> * LICENSE file mentions 3rdparty/tvm/3rdparty/rang as "Unlicense". It would
> be good to clarify that.

You can refer to line 207-211 in our LICENSE file, which state that the the
license of each subcomponent is available at the path of the subcomponent as
long as nothing else is noted in our LICENSE file. So in the case of
3rdparty/tvm/3rdparty/rang, we request our users to take a look at
3rdparty/tvm/3rdparty/rang folder and open 3rdparty/tvm/3rdparty/rang/LICENSE
to find the license text of the Unlicense.

Best regards
Leonard

-
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 2.0.0.rc3

2021-02-24 Thread Leonard Lausen
Dear community,

This is a call for a releasing Apache MXNet (incubating) 2.0.0.alpha, release
candidate 3. Note that this is an Alpha release, which represents our first
project milestone on the road to MXNet 2 and is intended for bleeding-edge
developers working outside the project. [1]

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

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

Result thread:
https://lists.apache.org/thread.html/r390ecf96b8ad19cc8934adaa0371325e77f3dc3d94578c2ea5e73c34%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/2.0.0.alpha.rc3/

The tag to be voted upon is v2.0.0.alpha.rc3:
https://github.com/apache/incubator-mxnet/releases/tag/v2.0.0.alpha.rc3

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

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

For information about the contents of this release, see:
https://github.com/apache/incubator-mxnet/issues/18931

The vote will be open for 7 days.

[ ] +1 release this package as 2.0.0.alpha
[ ] +0 no opinion
[ ] -1 do not release this package because...

Best regards,
Leonard Lausen



-
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 2.0.0.rc2

2021-02-11 Thread Leonard Lausen
The Apache Voting Process policy specifies that non-binding votes are only 
advisory, which would imply they are not included in the count. So my question 
is addressed. 

Thanks
Leonard

On February 11, 2021 10:47:23 AM GMT+01:00, Leonard Lausen  
wrote:
>Hi Justin,
>
>according to release policy, 'For a release vote to pass, a minimum of three 
>positive votes and more positive than negative votes MUST be cast. Releases 
>may not be vetoed. Votes cast by PMC members are binding.'
>
>There are 3 positive votes including one PPMC vote. Could you provide a 
>reference to the applicable policy? Or does the formulation of the release 
>policy need correction?
>
>Best regards
>Leonard 
>
>On February 11, 2021 3:30:34 AM GMT+01:00, Justin Mclean 
> wrote:
>>
>>Hi,
>>
>>-1 (binding) I have not checked dates release but teh vote thread shows only 
>>one PPMC (and no mentors) vote. Committer votes are not binding on release 
>>votes. I would suggest you continue with the vote on your dev listuntill you 
>>have enough PPMC votes and then bright it back here again.
>>
>>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 2.0.0.rc2

2021-02-11 Thread Leonard Lausen
Hi Justin,

according to release policy, 'For a release vote to pass, a minimum of three 
positive votes and more positive than negative votes MUST be cast. Releases may 
not be vetoed. Votes cast by PMC members are binding.'

There are 3 positive votes including one PPMC vote. Could you provide a 
reference to the applicable policy? Or does the formulation of the release 
policy need correction?

Best regards
Leonard 

On February 11, 2021 3:30:34 AM GMT+01:00, Justin Mclean 
 wrote:
>
>Hi,
>
>-1 (binding) I have not checked dates release but teh vote thread shows only 
>one PPMC (and no mentors) vote. Committer votes are not binding on release 
>votes. I would suggest you continue with the vote on your dev listuntill you 
>have enough PPMC votes and then bright it back here again.
>
>Thanks,
>Justin
>-
>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 2.0.0.rc2

2021-02-10 Thread Leonard Lausen
Dear community,

This is a call for a releasing Apache MXNet (incubating) 2.0.0.alpha, release
candidate 2. Note that this is an Alpha release, which represents our first
project milestone on the road to MXNet 2 and is intended for bleeding-edge
developers working outside the project. [1]

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

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

Result thread:
https://lists.apache.org/thread.html/rbd0ea394c8cc25fa61c4c68f96eb6723df385bb3d188f6110b657fc1%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/2.0.0.alpha.rc2/

The tag to be voted upon is v2.0.0.alpha.rc2:
https://github.com/apache/incubator-mxnet/releases/tag/v2.0.0.alpha.rc2

The release hash is 25c25dabcb8263f13c4dca80b2c8638c17d68e2e:
https://github.com/apache/incubator-mxnet/commit/25c25dabcb8263f13c4dca80b2c8638c17d68e2e

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

For information about the contents of this release, see:
https://github.com/apache/incubator-mxnet/issues/18931

The vote will be open for 72 hours.

[ ] +1 release this package as 2.0.0.alpha
[ ] +0 no opinion
[ ] -1 do not release this package because...

Best regards,
Leonard Lausen


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



[jira] [Comment Edited] (INCUBATOR-253) Issues with MXNet releases and their distribution

2020-07-02 Thread Leonard Lausen (Jira)


[ 
https://issues.apache.org/jira/browse/INCUBATOR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149872#comment-17149872
 ] 

Leonard Lausen edited comment on INCUBATOR-253 at 7/2/20, 5:38 PM:
---

Please see the MXNet report to the incubator for an update on the 14 items: 
https://cwiki.apache.org/confluence/display/INCUBATOR/July2020#mxnet

EDIT as per Justin's recommendation


was (Author: lausen):
I'm including below an excerpt from the MXNet report to the Incubator:

 

{code:java}

 Issues with releases and distributions

# Background
In May 2020 The MXNet PPMC has proactively initiated a ASF policy compliance
review [1] and a license review [2] with the Apache Legal team.

The license review uncovered that

- Building unmodified MXNet release source code with the optional NVidia GPU
 support enabled results in a binary subject to restrictions of NVidia EULA.
- PPMC members and committers uploaded convenience releases to
 repository.apache.org which contain Category-X components. Both GPL and
 NVidia EULA components were found.
 
The policy review uncovered that:

- Prior ASF guidance to the PPMC (December 2018 legal review [3]) was incomplete
 and did not include a reference to the "unwritten" rule that convenience
 binary distributions created by third-parties using ASF Trademarks must not
 include Category-X components. Based on this discovery, the Draft Downstream
 Distribution Branding Policy was updated in June 2020 to include the
 "unwritten" requirement. Based on the updated guidance, PPMC discovered
 various third-party trademark infringements.
 
The policy review did not yet conclude on the questions if

- The PPMC may create nightly development builds (audience restricted to dev
 list subscribers as per Release policy [4]) for the purpose of testing and
 developing MXNet;

# List of issues and their status

Justin classified the issues into 14 items.

1) Source and convenance binary releases containing Category X licensed code.

See summary from license review in Background section. Source code releases do
not contain Category X code; Takedown of binary releases on
repository.apache.org is pending on Apache Infra. (Trademark infringements of
3rd-parties such as on pypi are discussed separately)

2. Website giving access to downloads of non released/unapproved code.

Website contained links to nightly development builds which have been removed 
[5];
Going forward the PPMC intends to begin periodical voting on Alpha and Beta
Releases which will then be linked from the website.

3. Website giving access to releases containing Category X licensed code.

Website contained links to third-party distributions incorporating Category-X
components (see summary from license review above). Disclaimers were added to
the website clarifying the third-party status of the releases and their
licenses. [5]

4. Web site doesn't given enough warning to users of the issues with non
(P)PMC releases or making it clear that these are not ASF releases.

Website contained links to third-party distributions incorporating Category-X
components (see summary from license review above). Disclaimers were added to
the website clarifying the third-party status of the releases and their
licenses. [5]

5. Maven releases containing Category X licensed code.

See summary from license review in Background section. Source code releases do
not contain Category X code; Takedown of binary releases on
repository.apache.org is pending on Apache Infra. [6] (Trademark infringements 
of
3rd-parties are discussed separately)

6. PyPI releases containing Category X licensed code.

There are no PiPy releases by the PPMC. Please refer to the trademark
infringement section of the report.

7. Docker releases containing Category X licensed code.

There are no Docker releases by the PPMC. Please refer to the trademark
infringement section of the report.

8. Docker releases containing unreleased/unapproved code.

There are no Docker releases by the PPMC. The existence of third-party releases
containing unreleased code was approved in [3] and is also in line with the
current Downstream Distribution Branding Draft Policy. ("using any particular
revision from the development branch is OK" [3])

9. Trademark and branding issues with PiPy and Docker releases.

There are no PiPy releases by the PPMC. Please refer to the trademark
infringement section of the report.

10. Trademark and brand issues with naming of releases.

There are no binary releases by the PPMC besides the repository.apache.org
releases discussed above, which are being removed.
Please refer to the trademark infringement section of
the report.

11. Developer releases available to users and public searchable
https://repo.mxnet.io / https://dist.mxnet.io

Links to the nightly development builds were removed from the MXNet website and
a robot

[jira] [Comment Edited] (INCUBATOR-253) Issues with MXNet releases and their distribution

2020-07-01 Thread Leonard Lausen (Jira)


[ 
https://issues.apache.org/jira/browse/INCUBATOR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149872#comment-17149872
 ] 

Leonard Lausen edited comment on INCUBATOR-253 at 7/2/20, 5:08 AM:
---

I'm including below an excerpt from the MXNet report to the Incubator:

 

{code:java}

 Issues with releases and distributions

# Background
In May 2020 The MXNet PPMC has proactively initiated a ASF policy compliance
review [1] and a license review [2] with the Apache Legal team.

The license review uncovered that

- Building unmodified MXNet release source code with the optional NVidia GPU
 support enabled results in a binary subject to restrictions of NVidia EULA.
- PPMC members and committers uploaded convenience releases to
 repository.apache.org which contain Category-X components. Both GPL and
 NVidia EULA components were found.
 
The policy review uncovered that:

- Prior ASF guidance to the PPMC (December 2018 legal review [3]) was incomplete
 and did not include a reference to the "unwritten" rule that convenience
 binary distributions created by third-parties using ASF Trademarks must not
 include Category-X components. Based on this discovery, the Draft Downstream
 Distribution Branding Policy was updated in June 2020 to include the
 "unwritten" requirement. Based on the updated guidance, PPMC discovered
 various third-party trademark infringements.
 
The policy review did not yet conclude on the questions if

- The PPMC may create nightly development builds (audience restricted to dev
 list subscribers as per Release policy [4]) for the purpose of testing and
 developing MXNet;

# List of issues and their status

Justin classified the issues into 14 items.

1) Source and convenance binary releases containing Category X licensed code.

See summary from license review in Background section. Source code releases do
not contain Category X code; Takedown of binary releases on
repository.apache.org is pending on Apache Infra. (Trademark infringements of
3rd-parties such as on pypi are discussed separately)

2. Website giving access to downloads of non released/unapproved code.

Website contained links to nightly development builds which have been removed 
[5];
Going forward the PPMC intends to begin periodical voting on Alpha and Beta
Releases which will then be linked from the website.

3. Website giving access to releases containing Category X licensed code.

Website contained links to third-party distributions incorporating Category-X
components (see summary from license review above). Disclaimers were added to
the website clarifying the third-party status of the releases and their
licenses. [5]

4. Web site doesn't given enough warning to users of the issues with non
(P)PMC releases or making it clear that these are not ASF releases.

Website contained links to third-party distributions incorporating Category-X
components (see summary from license review above). Disclaimers were added to
the website clarifying the third-party status of the releases and their
licenses. [5]

5. Maven releases containing Category X licensed code.

See summary from license review in Background section. Source code releases do
not contain Category X code; Takedown of binary releases on
repository.apache.org is pending on Apache Infra. [6] (Trademark infringements 
of
3rd-parties are discussed separately)

6. PyPI releases containing Category X licensed code.

There are no PiPy releases by the PPMC. Please refer to the trademark
infringement section of the report.

7. Docker releases containing Category X licensed code.

There are no Docker releases by the PPMC. Please refer to the trademark
infringement section of the report.

8. Docker releases containing unreleased/unapproved code.

There are no Docker releases by the PPMC. The existence of third-party releases
containing unreleased code was approved in [3] and is also in line with the
current Downstream Distribution Branding Draft Policy. ("using any particular
revision from the development branch is OK" [3])

9. Trademark and branding issues with PiPy and Docker releases.

There are no PiPy releases by the PPMC. Please refer to the trademark
infringement section of the report.

10. Trademark and brand issues with naming of releases.

There are no binary releases by the PPMC besides the repository.apache.org
releases discussed above, which are being removed.
Please refer to the trademark infringement section of
the report.

11. Developer releases available to users and public searchable
https://repo.mxnet.io / https://dist.mxnet.io

Links to the nightly development builds were removed from the MXNet website and
a robot.txt file was added to prevent indexing of the sites. These websites are
removed from Google search index.

12. Releases and other nightly builds on
https://repo.mxnet.io / https://dist.mxnet.io containing categ

[jira] [Commented] (INCUBATOR-253) Issues with MXNet releases and their distribution

2020-07-01 Thread Leonard Lausen (Jira)


[ 
https://issues.apache.org/jira/browse/INCUBATOR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149872#comment-17149872
 ] 

Leonard Lausen commented on INCUBATOR-253:
--

I'm including below an excerpt from the MXNet report to the Incubator:

 

 Issues with releases and distributions

# Background
In May 2020 The MXNet PPMC has proactively initiated a ASF policy compliance
review [1] and a license review [2] with the Apache Legal team.

The license review uncovered that

- Building unmodified MXNet release source code with the optional NVidia GPU
 support enabled results in a binary subject to restrictions of NVidia EULA.
- PPMC members and committers uploaded convenience releases to
 repository.apache.org which contain Category-X components. Both GPL and
 NVidia EULA components were found.
 
The policy review uncovered that:

- Prior ASF guidance to the PPMC (December 2018 legal review [3]) was incomplete
 and did not include a reference to the "unwritten" rule that convenience
 binary distributions created by third-parties using ASF Trademarks must not
 include Category-X components. Based on this discovery, the Draft Downstream
 Distribution Branding Policy was updated in June 2020 to include the
 "unwritten" requirement. Based on the updated guidance, PPMC discovered
 various third-party trademark infringements.
 
The policy review did not yet conclude on the questions if

- The PPMC may create nightly development builds (audience restricted to dev
 list subscribers as per Release policy [4]) for the purpose of testing and
 developing MXNet;

# List of issues and their status

Justin classified the issues into 14 items.

1) Source and convenance binary releases containing Category X licensed code.

See summary from license review in Background section. Source code releases do
not contain Category X code; Takedown of binary releases on
repository.apache.org is pending on Apache Infra. (Trademark infringements of
3rd-parties such as on pypi are discussed separately)

2. Website giving access to downloads of non released/unapproved code.

Website contained links to nightly development builds which have been removed 
[5];
Going forward the PPMC intends to begin periodical voting on Alpha and Beta
Releases which will then be linked from the website.

3. Website giving access to releases containing Category X licensed code.

Website contained links to third-party distributions incorporating Category-X
components (see summary from license review above). Disclaimers were added to
the website clarifying the third-party status of the releases and their
licenses. [5]

4. Web site doesn't given enough warning to users of the issues with non
(P)PMC releases or making it clear that these are not ASF releases.

Website contained links to third-party distributions incorporating Category-X
components (see summary from license review above). Disclaimers were added to
the website clarifying the third-party status of the releases and their
licenses. [5]

5. Maven releases containing Category X licensed code.

See summary from license review in Background section. Source code releases do
not contain Category X code; Takedown of binary releases on
repository.apache.org is pending on Apache Infra. [6] (Trademark infringements 
of
3rd-parties are discussed separately)

6. PyPI releases containing Category X licensed code.

There are no PiPy releases by the PPMC. Please refer to the trademark
infringement section of the report.

7. Docker releases containing Category X licensed code.

There are no Docker releases by the PPMC. Please refer to the trademark
infringement section of the report.

8. Docker releases containing unreleased/unapproved code.

There are no Docker releases by the PPMC. The existence of third-party releases
containing unreleased code was approved in [3] and is also in line with the
current Downstream Distribution Branding Draft Policy. ("using any particular
revision from the development branch is OK" [3])

9. Trademark and branding issues with PiPy and Docker releases.

There are no PiPy releases by the PPMC. Please refer to the trademark
infringement section of the report.

10. Trademark and brand issues with naming of releases.

There are no binary releases by the PPMC besides the repository.apache.org
releases discussed above, which are being removed.
Please refer to the trademark infringement section of
the report.

11. Developer releases available to users and public searchable
https://repo.mxnet.io / https://dist.mxnet.io

Links to the nightly development builds were removed from the MXNet website and
a robot.txt file was added to prevent indexing of the sites. These websites are
removed from Google search index.

12. Releases and other nightly builds on
https://repo.mxnet.io / https://dist.mxnet.io containing category X licensed 
code.

Neither of the two site contains Re

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

2020-06-23 Thread Leonard Lausen
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 (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 contribut

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

2020-06-15 Thread Leonard Lausen
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]: 
> > https://lists.apache.org/thread.html/ef46b1d0a3dd865d27a33c290430d892d3373d4bc5e27b5f06c7bcda%401451951295%40%3Cgeneral.incubator.apache.org%3E
> > 
> > 
> > On Wed, 2020-06-10 at 21:39 -0500, Bob Paulin wrote:
> > 
> > First general disclaimer: I am not a lawyer.
> > 
> > Second Disclaimer with an engineer hat on we want to avoid copying third
> > party code into the project since it increases the amount of maintenance
> > in a sense from a code standpoint and from a licensing standpoint.  If
> > at all possible it is preferable to either link or try to find a way to
> > integrate your tweaks back into the other projects before taking on the
> > burden of housing the code in MXNet.  I do hope these options were
> > considered or are being looked at for refactoring in the project since
> > it will help the long term viability of the project.
> > 
> > Now to your question.  Similar situations have been discussed both on
> > legal [1] and on incubator [2][3].  It may be useful to review some of
> > these threads to understand how other projects made this determination.
> > There are instances where other members have stated it is appropriate
> > and the dual headers have been used [4].  It seems in some of these
> > cases the PMC has reached out to the other projects to ask for
> > permission to apply the Apache license.
> > 
> > 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.  If the PMC feels strongly
> > it would make sense to escalate to legal-discuss.   These are case by
> > case decisions and the more third party code that gets copied in the
> > more drag there will be on the community to deal with these issues.  I
> > would also encourage discussion of each case to remain on list so that
> > the incubator PMC can see how the PPMC is making these determinations.
> > 
> > - Bob
> > 
> > [1]
>

Re: Issue with releases / feedback from ASF board

2020-06-07 Thread Leonard Lausen
Thank you Betrand for the suggestion.

I have created a pull request to update the website. Anyone interested,
please take a look and leave feedback in the pull request or via
response to this mail. There is no preview of the resulting page
available, but we can also iterate via multiple pull requests in case of
any remaining problems.

https://github.com/apache/incubator-mxnet/pull/18487

The PR is quite large, thus my reluctance to first open a PR deleting
stuff and then adding things back. The effort for correcting the site in
a single step is significantly lower. I hope Incubator has understanding
for that.

Thanks
Leonard

Bertrand Delacretaz  writes:
> Hi,
>
> On Thu, Jun 4, 2020 at 8:44 AM Leonard Lausen  wrote:
>> ...Does adding the following notice pior to any mentioning of a third-party
>> binary release work for clearly informing users?...
>
> I haven't followed all the details but IIUC what you are doing is
> linking to third-party packages that can help people get started with
> MXNet but are not provided by the ASF.
>
> If that's correct, I would phrase your disclaimer a bit differently.
>
>>
>> > WARNING: The following binary release is not provided by the Apache
>> > Software Foundation and third-party members of the MXNet community.
>> > They may contain closed-source components with restrictive licenses.
>> > You may want to download the official Apache MXNet (incubating) source
>> > release instead and build from source instead
>
> WARNING: the following links are provided for your convenience but
> they point to packages that are *not* provided nor endorsed by the
> Apache Software Foundation.
> As such, they might contain software components with more restrictive
> licenses than the Apache License and you'll need to decide whether
> they are appropriate for your usage. Like all Apache Releases, the
> official Apache MXNet (incubating) releases consist of source code
> only and are found at .
>
> -Bertrand

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



Re: Issue with releases / feedback from ASF board

2020-06-04 Thread Leonard Lausen
Hi Justin,

as there have been a couple of mails on the dev@ list prior to your mail
to general@ list and your mail contains a dramatic opening, I'd like to
provide some context here.

The problem in the current focus is how to ensure the
http://mxnet.apache.org/get_started page is compliant with ASF policies.
The page currently provides names of third-party binary distributions
not controlled by the PPMC which may confuse some users.

Let's take a look at the timeline first:

On May 5th 2020 I have opened LEGAL-515 and asked (among other
questions) how the MXNet PPMC can correctly reference third-party
distributions on the website. Unfortunately that question was not
answered. In fact the majority of questions in LEGAL-515 remained
unanswered throughout May (starting May 8th).

Note that prior to my question in LEGAL-515, the MXNet website has been
mentioning the names of third-party distributions already.

You just now stated:

> You were asked to do something about this a few weeks ago and as far
> as I can see have not done so. Please do so as soon as you can.

That's not entirely correct. I note that there a two different requests.
On May 24th you have contacted the PPMC, requesting the PPMC to (among
other things) improve the clarity of the Getting Started page:

> It also needs to be clear what a user is installed from this install
> page [http://mxnet.incubator.apache.org/get_started]

PPMC has been working on resolving this question in LEGAL-515 since May
5th and has also requested guidance from the trademark@ team. This was
still ongoing at the time of your email today.

Today you have contacted the PPMC with a different request about the
Getting Started page:

> It’s quite clear they should not be linked to from an Apache page
> like this as users will think these are Apache releases. Please remove
> them, after that bring it up on the incubator general list and we can
> discuss what needs to be done.

In response I have asked you, if it wouldn't be possible to first decide
how to properly disclaim links to third-parties on the website, before
removing the links and then potentially adding them back with a
disclaimer later.

This is a very simple question. It's quite late in my timezone and
updating the website will take some time. Why not udpate the website
once correctly instead of taking a route that requires multiple updates?

To resolve the situation, I suggest we start from your statement here:

> No Apache project should be distributing 3rd party releases from their
> web site without clearly informing the users of what they are getting.

Does adding the following notice pior to any mentioning of a third-party
binary release work for clearly informing users?

> WARNING: The following binary release is not provided by the Apache
> Software Foundation and third-party members of the MXNet community.
> They may contain closed-source components with restrictive licenses.
> You may want to download the official Apache MXNet (incubating) source
> release instead and build from source instead.

If so, PPMC can initiate the process of adding this statement to the
website tomorrow. If not, do you have a better suggestion?

And in either case, if the Incubator prefers the route of updating the
website multiple times and leaves a partially empty website in the
intermediate time, then let it be that way and PPMC may initiate that
process tomorrow.


>> I'm not sure what you mean. Note that Github automatically creates these
>> release pages based on the presence of git tags in the version control
>> history.
>
> Yes they do but they consists of Apache releases it looks like you
> have non Apache releases there. Other projects tag these add notes to
> make it very clear they are not Apache releases.

The context here is that I requested you to clarify on your mail from
May 24th in which you stated:

> The GitHub download page [2] is also confusing as it contains a mix of
> Apache and non-Apache releases

My understanding of your statement was that you refer to the source
archives created by Github, which are not the official ASF source
archives. MXNet project uploaded the ASF source archives in addition to
the Github source archives to ensure users can easily discover them. But
it appears this is not what you meant with "confusing" .

But given your response, I now believe you may be referring to git tags
that were made prior to MXNet joining the incubator on 2017-01-23 / on
which no vote by the PPMC took place? Adding notes to those releases can
be done easily if that is what you request.

Best regards
Leonard

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