Thanks Leonard for the confirmation, I will update the related files based on the consensus.
Regards, -Ciyong -----Original Message----- From: Leonard Lausen <lau...@apache.org> Sent: Wednesday, June 24, 2020 2:24 AM To: dev@mxnet.incubator.apache.org; gene...@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 +0000, 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 <lau...@apache.org> > Sent: Tuesday, June 16, 2020 7:06 AM > To: dev@mxnet.incubator.apache.org; gene...@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 <b...@bobpaulin.com> 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] > > > > > > <snip> > > > > > > - 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 > > > </snip> > > > > > > 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/rb83ff64bdac464df2f0cf2fe8fb4 > > > c6 b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E > > > > > > [2] > > > https://github.com/numpy/numpy/blob/master/numpy/core/einsumfunc.p > > > y 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/ef46b1d0a3dd865d27a33c290430d > > > 89 > > > 2d3373d4bc5e27b5f06c7bcda%401451951295%40%3Cgeneral.incubator.apac > > > he > > > .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] > > > https://lists.apache.org/thread.html/0fc4c0e95ee0c489553373e378125 > > > a0 > > > d163bc511da2555caa68bfa87%401455903168%40%3Clegal-discuss.apache.o > > > rg > > > %3E > > > > > > [2] > > > https://lists.apache.org/thread.html/d00f72c4aa0b56927dac87b116e2e > > > 92 > > > fa32b7dcf447016726683cc4f@1455210877@%3Cgeneral.incubator.apache.o > > > rg > > > %3E > > > > > > [3] > > > https://lists.apache.org/thread.html/e743b1b1cfda2c4775c3fe509f3ad > > > c8 > > > f69d64fd2b6eb253ade311fe7%401451947855%40%3Cgeneral.incubator.apac > > > he > > > .org%3E > > > > > > [4] > > > https://github.com/apache/trafodion/blob/master/core/sql/parser/ul > > > ex > > > er.h > > > > > > [5] > > > https://github.com/numpy/numpy/blob/master/numpy/core/einsumfunc.p > > > y > > > > > > [6] > > > https://github.com/apache/incubator-mxnet/blob/master/src/operator > > > /n > > > umpy/np_einsum_op.cc > > > > > > > > > On 6/10/2020 5:29 PM, Leonard Lausen wrote: > > > > > > Hi Bob, > > > > > > yes, your understanding is correct. To further give an example I'd > > > like to quote Haozheng who added two of the files in question: > > > > > > > > > The two files originate from > > > > > > > https://github.com/numpy/numpy/blob/master/numpy/core/einsumfunc.py . > > > > > > I translated them from python to cpp. The original files are > > > subject to the the following license: > > > https://github.com/numpy/numpy/blob/master/LICENSE.txt > > > > > > https://github.com/apache/incubator-mxnet/issues/17329#issuecommen > > > t- > > > 640043814 > > > > > > Thank you > > > Leonard > > > > > > On Wed, 2020-06-10 at 07:42 -0500, Bob Paulin wrote: > > > > > > Hi, > > > > > > Let me restate to make sure I understand what's being asked. > > > > > > 1) There is third party code in the project that has Major > > > Modifications to the original third party source. > > > > > > 2) The original third party code does not currently have two > > > license headers > > > > > > (ex Third Party Code has MIT license only. Apache License header > > > was added when it was checked into MXNet repo with modifications) > > > > > > 3) You are asking if the files can remain in the MXNet repository > > > with both license headers. > > > > > > - Bob > > > > > > On 6/9/2020 5:07 PM, Leonard Lausen wrote: > > > > > > Hi Mentors, > > > https://www.apache.org/legal/src-headers.html#3party states the 5 > > > rules for handling third-party code included in the project [1]. > > > In particular PPMC shall handle major modifications on a > > > case-by-case basis. > > > > > > But the other rules state > > > > > > > > > 1. Do not modify or remove any copyright notices or licenses > > > within > > > third- > > > > > > party works. > > > > > > and > > > > > > > > > 2. Do not add the standard Apache License header to the top of > > > third- party > > > > > > source files. > > > > > > The major modifications in question [2] are currently licensed > > > under Apache License but the files originate from a third-party > > > and there are thus two license headers in the files. This is in > > > conflict with rule 2. > > > > > > Could you clarify if rule 2 is not a rule but only a guideline > > > that can be overruled in PPMC's case-by-case decision? What's your > > > recommendation? > > > Ie. > > > can > > > we keep the 2 headers in place? > > > > > > Best regards > > > Leonard > > > > > > > > > [1]: > > > > > > > > > 0. The term "third-party work" refers to a work not submitted > > > directly to the ASF by the copyright owner or owner's agent. This > > > includes parts of a work submitted directly to the ASF for which > > > the submitter is not the copyright owner or owner's agent. > > > 1. Do not modify or remove any copyright notices or licenses > > > within > > > third- > > > party works. > > > 2. Do ensure that every third-party work includes its associated > > > license, even if that requires adding a copy of the license from > > > the third-party download site into the distribution. > > > 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. > > > 5. Major modifications/additions to third-party should be dealt > > > with on a case-by-case basis by the PMC. > > > > > > [2]: > > > https://github.com/apache/incubator-mxnet/issues/17329#issuecommen > > > t- > > > 641311199 > > > > > >
