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/ef46b1d0a3dd865d27a33c290430d892d3373d4bc5e27b5f06c7bcda%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/0fc4c0e95ee0c489553373e378125a0d163bc511da2555caa68bfa87%401455903168%40%3Clegal-discuss.apache.org%3E
> 
> [2]
> https://lists.apache.org/thread.html/d00f72c4aa0b56927dac87b116e2e92fa32b7dcf447016726683cc4f@1455210877@%3Cgeneral.incubator.apache.org%3E
> 
> [3]
> https://lists.apache.org/thread.html/e743b1b1cfda2c4775c3fe509f3adc8f69d64fd2b6eb253ade311fe7%401451947855%40%3Cgeneral.incubator.apache.org%3E
> 
> [4] https://github.com/apache/trafodion/blob/master/core/sql/parser/ulexer.h
> 
> [5] https://github.com/numpy/numpy/blob/master/numpy/core/einsumfunc.py
> 
> [6]
> https://github.com/apache/incubator-mxnet/blob/master/src/operator/numpy/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
> > > > 

Reply via email to