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: 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 <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/rb83ff64bdac464df2f0cf2fe8fb4c6 > > > b9d3b8fa62b645763dc606045f%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/ef46b1d0a3dd865d27a33c290430d89 > > > 2d3373d4bc5e27b5f06c7bcda%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] > > > https://lists.apache.org/thread.html/0fc4c0e95ee0c489553373e378125a0 > > > d163bc511da2555caa68bfa87%401455903168%40%3Clegal-discuss.apache.org > > > %3E > > > > > > [2] > > > https://lists.apache.org/thread.html/d00f72c4aa0b56927dac87b116e2e92 > > > fa32b7dcf447016726683cc4f@1455210877@%3Cgeneral.incubator.apache.org > > > %3E > > > > > > [3] > > > https://lists.apache.org/thread.html/e743b1b1cfda2c4775c3fe509f3adc8 > > > f69d64fd2b6eb253ade311fe7%401451947855%40%3Cgeneral.incubator.apache > > > .org%3E > > > > > > [4] > > > https://github.com/apache/trafodion/blob/master/core/sql/parser/ulex > > > er.h > > > > > > [5] > > > https://github.com/numpy/numpy/blob/master/numpy/core/einsumfunc.py > > > > > > [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#issuecomment- > > > 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#issuecomment- > > > 641311199 > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
