mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Ciyong" <ciyong.c...@intel.com>
Subject RE: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: [MENTORS] PPMC case-by-case decision for major modifications of third-party work guidance
Date Tue, 16 Jun 2020 07:47:43 GMT
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 <bob@bobpaulin.com>
Sent: Monday, June 15, 2020 11:38 PM
To: dev@mxnet.incubator.apache.org; Chen, Ciyong <ciyong.chen@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 <bob@bobpaulin.com><mailto:bob@bobpaulin.com>

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

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




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message