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 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
[CANCEL] [VOTE] Release Apache NLPCraft (Incubating) 0.6.1
I'm cancelling this vote due to licensing concerns found in [1]. 1. https://lists.apache.org/thread.html/r5a2954287e2db23a26c4a22880fea5beceb352af1a6fb2e8323d0cbc%40%3Cgeneral.incubator.apache.org%3E -- Aaron Radzinski On Fri, Jun 12, 2020 at 11:29 AM Aaron Radzinski wrote: > Hello all, > This is a call for a vote to release Apache NLPCraft (incubating) version > 0.6.1. Apache NLPCraft is a library for adding a natural language interface > to any application. > > The Apache NLPCraft community has voted on and approved a proposal to > release Apache NLPCraft (Incubating) version 0.6.1. We would like to > request the Incubator PMC members review and vote on this incubator release. > > Release information: > 1. PPMC vote result thread: > https://mail-archives.apache.org/mod_mbox/nlpcraft-dev/202006.mbox/%3ccacwejt91kdfkqntbb9msekqo4sky5_vsqwyobft57eeibap...@mail.gmail.com%3e > 2. Release location: > https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/0.6.1/ > 3. Git tag: https://github.com/apache/incubator-nlpcraft/tree/v0.6.1 > 4. JIRA issues fixed in release: > https://issues.apache.org/jira/projects/NLPCRAFT/versions/12347775 > 5. KEYS file: > https://dist.apache.org/repos/dist/release/incubator/nlpcraft/KEYS > > The vote will be open for at least 72 hours or until a necessary number of > votes are reached. > > Please vote accordingly: > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove with the reason > > Thank you, > -- > Aaron Radzinski > >
Re: [VOTE] Release Apache Annotator (incubating) version 0.1.0 (-rc.4)
On 2020/06/14 01:31:11, Justin Mclean wrote: > Hi, > > +1 (binding) Thank you, Justin! > - Unable to compile on OSX but assume that’s not a supported platform. It > would be good to mention this in the README. The build should work on macOS with the requirements listed in the README. Node.js and Yarn are the two required tools. (A working "make" command is needed, unless you run the build steps by hand.) We'll try to make this more explicit for the next release, and check whether other things are needed that we've taken for granted. > > You included “.git” directory in the source release was this intentional? It > includes this file [1] which I’m not sure what the license is. Including a ".git" directory was intentional. It is an experiment to see whether this simplifies creating and checking the release contents. The release is a shallow clone of the source repository and the testing instructions provide commands to compare the contents with the remote repository to ensure that only the files from the release tag are included in the tarball. The file you flagged is a sample file installed by "git init". We will update our "make dist" command in the future to avoid creating this. Thanks for finding that. > > You might also want to make this [2] be more in line with [3]. Great catch. Thank you! Regards, Randall - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
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 > 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
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
For clarity the "additional license" in this case is the Apache License Header that a contributor added above the numpy license. I agree that the original license should remain if the file is considered derived in anyway. The podling was asking if they had authority to make the change to remove the Apache License or if they needed to reach out to the original contributor to re-license the code. I believe they have that authority with or without the contributor's permission. - Bob On 6/15/2020 7:39 AM, Justin Mclean wrote: > HI, > >> * 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? > IMO only if there are significant changes to the file, if in doubt I’d keep > the original license. > >> And the PPMC has all the authority to change the file like removing the >> additional license if needed. > I would say they don’t unless the 3rd party agrees or the overwhelming > majority of the code is no longer under the original license. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > signature.asc Description: OpenPGP digital signature
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
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
HI, > * 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? IMO only if there are significant changes to the file, if in doubt I’d keep the original license. > And the PPMC has all the authority to change the file like removing the > additional license if needed. I would say they don’t unless the 3rd party agrees or the overwhelming majority of the code is no longer under the original license. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
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 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]:
