[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

[Bob Paulin <bo...@bobpaulin.com>]

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. 

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]: 
> 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
>>>>>

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

[Justin Mclean <ju...@classsoftware.com>]

HI,

> In addition, Justin stated that converting the code from one program language to another one should **NOT** be considered as a major modification.

INAL but my understanding is that translation from one language to another is considered a fairly trivial task and may not be novel enough for a copyright to apply and it would not considered an original work.

> So it seems more appropriate to remove the ASF header and just keep the Numpy license header and claim it at the top level LICENSE, or do we need to vote on the two options as Bob stated below, thanks!

I think the safest think to do would be to leave the original header on and remove the ASF one.Version control will show what lines have been modified if anyone is stressed in the history.

Thanks,
Justin

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

["Chen, Ciyong" <ci...@intel.com>]

Thanks a lot for your valuable input Bob, John, Justin, Leonard.

As it’s still not finalized on how to handle such dual license issue from the discussion.
In addition, Justin stated that converting the code from one program language to another one should **NOT** be considered as a major modification.
And based on the statement #3 and #4 from https://www.apache.org/legal/src-headers.html#3party
> 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.

So it seems more appropriate to remove the ASF header and just keep the Numpy license header and claim it at the top level LICENSE, or do we need to vote on the two options as Bob stated below, thanks!
>1) Numpy License Headers Only
> 2) Apache Header with Numpy License Header (keep the license header as is now)

Best Regards,
-Ciyong

From: Bob Paulin <bo...@bobpaulin.com>
Sent: Monday, June 15, 2020 11:38 PM
To: dev@mxnet.incubator.apache.org; Chen, Ciyong <ci...@intel.com>; lausen@apache.org; dev@mxnet.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


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 <bo...@bobpaulin.com>

Sent: Sunday, June 14, 2020 2:20 AM

To: lausen@apache.org<ma...@apache.org>; dev@mxnet.apache.org<ma...@mxnet.apache.org>; general@incubator.apache.org<ma...@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]



<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.



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]:



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

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

["Chen, Ciyong" <ci...@intel.com>]

Thanks a lot for your valuable input Bob, John, Justin, Leonard.

As it’s still not finalized on how to handle such dual license issue from the discussion.
In addition, Justin stated that converting the code from one program language to another one should **NOT** be considered as a major modification.
And based on the statement #3 and #4 from https://www.apache.org/legal/src-headers.html#3party
> 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.

So it seems more appropriate to remove the ASF header and just keep the Numpy license header and claim it at the top level LICENSE, or do we need to vote on the two options as Bob stated below, thanks!
>1) Numpy License Headers Only
> 2) Apache Header with Numpy License Header (keep the license header as is now)

Best Regards,
-Ciyong

From: Bob Paulin <bo...@bobpaulin.com>
Sent: Monday, June 15, 2020 11:38 PM
To: dev@mxnet.incubator.apache.org; Chen, Ciyong <ci...@intel.com>; lausen@apache.org; dev@mxnet.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


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 <bo...@bobpaulin.com>

Sent: Sunday, June 14, 2020 2:20 AM

To: lausen@apache.org<ma...@apache.org>; dev@mxnet.apache.org<ma...@mxnet.apache.org>; general@incubator.apache.org<ma...@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]



<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.



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]:



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

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

[Bob Paulin <bo...@bobpaulin.com>]

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 <bo...@bobpaulin.com>
> Sent: Sunday, June 14, 2020 2:20 AM
> To: lausen@apache.org; dev@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]
>
> <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.
>
> 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]:
>
> 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
>
>

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

[Bob Paulin <bo...@bobpaulin.com>]

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 <bo...@bobpaulin.com>
> Sent: Sunday, June 14, 2020 2:20 AM
> To: lausen@apache.org; dev@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]
>
> <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.
>
> 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]:
>
> 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
>
>

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

[Bob Paulin <bo...@bobpaulin.com>]

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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@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

[Justin Mclean <ju...@classsoftware.com>]

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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@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

["Chen, Ciyong" <ci...@intel.com>]

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 <bo...@bobpaulin.com>
Sent: Sunday, June 14, 2020 2:20 AM
To: lausen@apache.org; dev@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]

<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.

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]:

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

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

["Chen, Ciyong" <ci...@intel.com>]

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 <bo...@bobpaulin.com>
Sent: Sunday, June 14, 2020 2:20 AM
To: lausen@apache.org; dev@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]

<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.

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]:

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

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

[Leonard Lausen <la...@apache.org>]

Hi Justin,

thank you for clarifying the major modification threshold. To clarify on the
scope of modification in MXNet: re-implementing the functionality in C++ is just
one aspect. MXNet generally provides more features compared to the original
implementation, such as automatic gradient calculation and a GPU kernels. If we
need additional clarification on the differences to the original implementation,
we can ask Haozheng to elaborate.

Best regards
Leonard

On Tue, 2020-06-16 at 00:52 +0000, Justin Mclean wrote:
> Hi,
> 
> I also add that converting from one language to another is not considered a
> major modification.
> 
> Thanks,
> Justin

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

[Justin Mclean <jm...@apache.org>]

Hi,

I also add that converting from one language to another is not considered a major modification.

Thanks,
Justin

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

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> the consensus passed, so we should proceed according to the consensus.


It’s unclear to me what you think of as consensus here, can you care to specify what the project is going to do?

Justin



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@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

["Chen, Ciyong" <ci...@intel.com>]

Thanks Leonard for the confirmation, I will update the related files based on the consensus. 

Regards,
-Ciyong

-----Original Message-----
From: Leonard Lausen <la...@apache.org> 
Sent: Wednesday, June 24, 2020 2:24 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

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 <la...@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 <bo...@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
> > > 
> > > 

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

["Chen, Ciyong" <ci...@intel.com>]

Thanks Leonard for the confirmation, I will update the related files based on the consensus. 

Regards,
-Ciyong

-----Original Message-----
From: Leonard Lausen <la...@apache.org> 
Sent: Wednesday, June 24, 2020 2:24 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

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 <la...@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 <bo...@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
> > > 
> > > 

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

[Leonard Lausen <la...@apache.org>]

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 <la...@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 <bo...@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
> > > 
> > > 

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

[Leonard Lausen <la...@apache.org>]

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 <la...@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 <bo...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@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

["Chen, Ciyong" <ci...@intel.com>]

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 <la...@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 <bo...@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
> > 
> > 

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

["Chen, Ciyong" <ci...@intel.com>]

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 <la...@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 <bo...@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
> > 
> > 

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

[Leonard Lausen <la...@apache.org>]

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 <bo...@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/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]: 
> > 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
> > 
> > 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@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

[Leonard Lausen <la...@apache.org>]

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 <bo...@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/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]: 
> > 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
> > 
> > 

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

["John D. Ament" <jo...@apache.org>]

On Sat, Jun 13, 2020 at 2:19 PM Bob Paulin <bo...@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/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]: 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
>
>

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

["John D. Ament" <jo...@apache.org>]

On Sat, Jun 13, 2020 at 2:19 PM Bob Paulin <bo...@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/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]: 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
>
>