mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonard Lausen <lau...@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
Date Tue, 23 Jun 2020 18:23:42 GMT
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 <lausen@apache.org>
> Sent: Tuesday, June 16, 2020 7:06 AM
> To: dev@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 <bob@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
> > > 
> > > 


Mime
View raw message