Re: Ownership of discuss.mxnet.io

[Sheng Zha]

To address the data loss concern, I'm setting up an archive for all future 
posts on discuss.mxnet.io to the new archive list [1]. It will take me a while 
before I get time to work on the rest.

-sz

[1] https://lists.apache.org/list.html?discuss-arch...@mxnet.apache.org

On 2020/06/12 22:39:10, Marco de Abreu  wrote: 
> Thanks for elaborating!
> 
> You are right, there's no requirement to host on ASF infrastructure. I was
> just thinking about what happens when that funding is cut or when there's
> an issue. What's the strategy to ensure no data loss in case of priority
> shift or defunding from Amazon? Opposed to the CI which is fully codified
> and under version control, we as PMC have no means to recover from a
> disaster in case of Discourse.
> 
> The mxnet.io domain is not under control of the ASF. If we say that a user
> facing platform is managed and endorsed by the PPMC, we should make it
> available under the ASF domain system to further represent the official
> affiliation. Also, it removes a weak link in the chain - e.g. the case when
> the mxnet.io domain ran out and broke quite a bit of stuff. Since the ASF
> offers subdomains for projects, I don't see any reason why not to use them.
> 
> Could you open a ticket with INFRA to check what authentication options
> they are offering? I couldn't find any info on the website.
> 
> -Marco
> 
> On Sat, Jun 13, 2020 at 12:24 AM Sheng Zha  wrote:
> 
> > > Could you elaborate about the hosting of the forum? Is there the
> > > possibility to move it to some ASF-managed webhost (I'm not sure about
> > the
> > > complexity of hosting Discourse)?
> >
> > The website is currently a subscribed hosted service provided by
> > discourse, donated by Amazon. It is possible to host it ourselves but it
> > would incur additional operational cost. In addition, I'm not aware of a
> > requirement to have it on ASF infrastructure, given that it's only for
> > answering user questions and we don't conduct official Apache MXNet
> > businesses there.
> >
> > > Also, I'd suggest to make an Apache managed subdomain the main domain
> > (e.g.
> > > https://discuss.mxnet.apache.org/ ). The
> > > existing domain could be a redirect.
> >
> > I don't see a benefit of doing that, nor am I aware of a requirement for
> > it.
> >
> > > Additionally, can we hook it up to the Apache IDP to allow committers and
> > > pmc members to be automatically authorized?
> >
> > This sounds like a good idea though I'm not sure how to proceed. If
> > someone knows how to proceed I'm happy to help grant necessary access to it.
> >
> > -sz
> >
> >
> > On 2020/06/12 22:07:47, Marco de Abreu  wrote:
> > > Hi Sheng,
> > >
> > > thanks for the quick response.
> > >
> > > Could you elaborate about the hosting of the forum? Is there the
> > > possibility to move it to some ASF-managed webhost (I'm not sure about
> > the
> > > complexity of hosting Discourse)?
> > >
> > > Also, I'd suggest to make an Apache managed subdomain the main domain
> > (e.g.
> > > https://discuss.mxnet.apache.org/ ). The
> > > existing domain could be a redirect.
> > >
> > > Additionally, can we hook it up to the Apache IDP to allow committers and
> > > pmc members to be automatically authorized?
> > >
> > > Best regards
> > > Marco
> > >
> > > On Fri, Jun 12, 2020 at 11:24 PM Sheng Zha  wrote:
> > >
> > > > Hi Marco,
> > > >
> > > > I'm an admin of that website along with a couple of other PPMC members.
> > > > This forum has been around for some time and has been helpful in
> > connecting
> > > > users of mxnet to the developer community. I think it's in the best
> > > > interest of this community to consider this under PPMC control for
> > better
> > > > discoverability under the mxnet domain name. I'm happy to grant you
> > admin
> > > > access if you or any other PPMC members need it. If you feel otherwise,
> > > > feel free to propose how you suggest we proceed.
> > > >
> > > > -sz
> > > >
> > > > On 2020/06/12 21:07:28, Marco de Abreu  wrote:
> > > > > Hi everyone,
> > > > >
> > > > > Due to a PR [1] I had a closer look at discuss.mxnet.io which is a
> > > > forum to
> > > > > discuss about MXNet. It's a very helpful platform and provides great
> > > > > assistance for the community.
> > > > >
> > > > > When I looked into the terms of services [2] though, I noticed that
> > the
> > > > ASF
> > > > > and MXNet ppmc are mentioned as owners.
> > > > >
> > > > > From my understanding, that forum and the domain are not managed by
> > the
> > > > ASF
> > > > > or the mxnet ppmc. Thus, that statement does not seem correct and is
> > > > rather
> > > > > a trademark infringement. My understanding is that the platform is
> > > > operated
> > > > > by a third party as a community service towards MXNet. Thus, I think
> > it's
> > > > > important to properly express who's responsible for that platform.
> > > > >
> > > > > If somebody has any knowledge about the owner of that forum, 

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

[Justin Mclean]

Hi,

I also add that converting from one language to another is not considered a 
major modification.

Thanks,
Justin

Re: [apache/incubator-mxnet] [RFC] MXNet website improvements (#17982)

[Yang Shi]

Looks like a bug, moved it to another issue. Will fix this

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-mxnet/issues/17982#issuecomment-644373593

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

[Bob Paulin]

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 
> Sent: Sunday, June 14, 2020 2:20 AM
> To: lau...@apache.org; d...@mxnet.apache.org; gene...@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 

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

[John D. Ament]

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 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]: 
> 

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; gene...@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]: