From dev-return-7688-archive-asf-public=cust-asf.ponee.io@mxnet.incubator.apache.org Mon Jun 15 15:37:59 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 703AF180656 for ; Mon, 15 Jun 2020 17:37:59 +0200 (CEST) Received: (qmail 71946 invoked by uid 500); 15 Jun 2020 15:37:58 -0000 Mailing-List: contact dev-help@mxnet.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mxnet.incubator.apache.org Delivered-To: mailing list dev@mxnet.incubator.apache.org Received: (qmail 71907 invoked by uid 99); 15 Jun 2020 15:37:58 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Jun 2020 15:37:58 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 5E435C15AD for ; Mon, 15 Jun 2020 15:37:57 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.2, KAM_LOTSOFHASH=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=bobpaulin-com.20150623.gappssmtp.com Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 8nT2plU5lb6o for ; Mon, 15 Jun 2020 15:37:54 +0000 (UTC) Received-SPF: Permerror (mailfrom) identity=mailfrom; client-ip=209.85.210.50; helo=mail-ot1-f50.google.com; envelope-from=bob@bobpaulin.com; receiver= Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 535D5BB903 for ; Mon, 15 Jun 2020 15:37:54 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id t6so13411005otk.9 for ; Mon, 15 Jun 2020 08:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bobpaulin-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=lxkvGtKiJNgYGrllvcWastqgXLtDlC31Z7UyAhuMMVQ=; b=f4HrwtF8JUwTSuTAtGU9yZtm9Vu34bb7It3iYOEadtaicNm0nx51dhrlIq5Vz/NZNv HlLB3xJ6ODGht+sQqSFgLKI/3cngn9/FW81TV93TedlLUWgIqopNzf7OPWy3ymkdsbxd syyX609t2f9iQ2ZOrrRaU/SDDsSsjDNfWRCKDobQ0B70epr3vmPtaq0gx4nivm15CZHp mcAfmFdCIpmuRHkaHyWVUTTx4XXh+aiL/T0G+NxSh4BvpbS4smpABAvzBg0dNa4grtYj Zf3/4Semr4Bm7hXNfpDSa0F3Dv1GgMdw5ulLf4hl28Cph4tgwRK72EyfPFNdSwpX5Qya s7LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=lxkvGtKiJNgYGrllvcWastqgXLtDlC31Z7UyAhuMMVQ=; b=EB89np6W6RQe8inXCVXhAEPvcckZJt7W+qiNZtCJp0QZAvo+z6LFPTdmUnICUMgAji HB/qkyN1zGd8Sgt0yp54y2sHvMNkuFrAyRNQZm3FIyMVdOH7ZnJY0UmF1FUf8LcCiiQj B9BMFZ2kfkbdJQMbJx6Ll96cnbbwV0OAdWDy5Vlxi8xSJ4KgB0fNao4OoNnoTRbFhihl dhVn2BvfXNuwoQmm3Cli+t1M1imBO5foC2yqPzGpReE2grCiQZ5lMz3O8d/UxBDMS9eL teVdNZsP4H5wfrOFOqL1qZkF+nlnkpoK4aaQieXgtGrrjJE24vexc2gS2qw45J/MvGrt lsmQ== X-Gm-Message-State: AOAM533FYOfYt1Unx6JcOz5c0txmjJBsQ4baCcUdBNb64RXI0iGi+XcT D492TxUPsXMxfBwq+jgujNY7eQ== X-Google-Smtp-Source: ABdhPJxKceE0C/9fD2y6i5SynxNVjliXBUNFuBbZSe3nQCWcTdO3Iq/sbZInb+tL+Xk60tJwNS7thw== X-Received: by 2002:a05:6830:1df5:: with SMTP id b21mr22560146otj.338.1592235467925; Mon, 15 Jun 2020 08:37:47 -0700 (PDT) Received: from [172.27.7.143] ([199.71.217.52]) by smtp.googlemail.com with ESMTPSA id s69sm3375391otb.4.2020.06.15.08.37.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 08:37:46 -0700 (PDT) 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 To: dev@mxnet.incubator.apache.org, "Chen, Ciyong" , "lausen@apache.org" , "dev@mxnet.apache.org" , "general@incubator.apache.org" References: <8b6c55149e17eb000854ddf750024580a298918d.camel@apache.org> <8d374f93d310145b86127ac2c0f6fcda465dd4fd.camel@apache.org> From: Bob Paulin Autocrypt: addr=bob@bobpaulin.com; prefer-encrypt=mutual; keydata= mQINBFRIf9cBEAC09Ua3WgcSfBVbcCNL0XEiGk6UF1giN/PDrTF7aBFUPUIw/NWA0FLAdMc0 00/2OJPH8FDPC3P47tPLNsEMWONInajBlLJzrDx8Ir9KNvKwtP0xjCQk7HSYaOUMUEb3hxAI c1kWD+M11b+u3111bhb5rE5FW3r3JjTGV3UDP+f499lVAKmUdZvAumJTf6nLg8uc/bD5Sgcb 0ElXZwpeFDbtRvJKpWntKMhVs0wj5XmBs67LfRWWwQ8SuZRLKPVca+C1dvLBW84LOaFEYSpI 2EXWIYBmDAhbRDYyM/1lyExD269FLYHNp/trOG5DPSO3lOl1T8p/kHxXc94Q9kuuy0am/lK0 OqmCBI/Kn+MkKvpOmk9MfXlj4/em7O/0RDwTjQfPE9pozYkVwH5ne2fyRiJC211PHmjXmBGi 0KKFH6KBeWGGTHCNMSnp8faYN0XuSh0B2A/r74BLmas/+A1HVDwn1qg2n8cwS2KaSo9CVDED GIdPXofDXmdHxgrSl8qawlSxevd8lTGR+rDRsLbOQrmGB4ABOu1CNqnGCoqM34g0tMK95U+G uq1obYghs9PS1byix5iL4JSkKvt0cJef+9+IDc0mz4Hqa3JX1tyeihpyEGBIKvUH3lj9BUu9 5fHvxOhJI/XU81hCmry2KqsfbVjwT3Er1PyO6EMr+dkfnj/VVQARAQABtC9Cb2IgUGF1bGlu IChQZXJzb25hbCBFbWFpbCkgPGJvYkBib2JwYXVsaW4uY29tPokCOAQTAQgAIgIbDwIeAQIX gAUCWILj2wYLCQgHAwIGFQgCCQoLBBYCAwEACgkQP5AsJ27ZviH5cw/+L3k/qljoLBjPtYZ5 O9ulZvAPa0BjxOPFzC1ZSeyyy9pTMnsxya9OxX4f5ux1Mlrz4e/d0N3Jlxc6zHaJ5uMYWKfO +tzbBi+6CMgiTSezFuSt5d1CeHpDL54w3g29HWtreIowhWx8pIucCKpy5LElu+w0YN3d1eMQ wqjB9A1XkuDEuVtp8uVHrLdIOFBI+C23YllSC2s4vxlDfmy46g36l2B0VAhtas0gFdgbCe2Y /Wq59DZ0dqrOL5NDtjDS83kVakwUljOIcD4SH/wmms7ANNhjY5NQMVMbBIPMZNgyjZuZpG4q hDcXmcHtYhZ+5HNntzi3SWMMf7/1S2qjTScZAVy7dWxEl40kQHNnyOHogDR0HnzsBA2THfLS 4FZ4GURKt6fLyoSKSe70UfbcYPXHu7B+/xv4Cu+XC6QIivhRe5aXTA3iwQ0VFNEBjqdMRXq5 n+wgSnpAWrAM/9acPyZnygLtwYyH3DqXAzUBeXPyQqZgeP7Gdj5/w3geuXso5pabxRa90QRo J2kcgsoK2ByWLCqSmZEdpkyB729ltJlu6GDj297xGKL6BWD5E1QzMhBOOVPHl1LbUzZM++wk EG13W2aYz7vHdWSniC+gtvLVXc6Wpits54MXYBLcVLxBQ8BOndZtkfi9apHPTMxJb7u0kvZG XLsLk5vRg1SRHbG2/Lg= Message-ID: Date: Mon, 15 Jun 2020 10:37:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nRLZ9t1g9NzdusDEKrY1O2F58Cv77k3hp" --nRLZ9t1g9NzdusDEKrY1O2F58Cv77k3hp Content-Type: multipart/mixed; boundary="xaAFRRUNBxynZH2hh3zC7vEvp0nRp6KJy" --xaAFRRUNBxynZH2hh3zC7vEvp0nRp6KJy Content-Type: multipart/alternative; boundary="------------C12ABAA7DBC2CDD5D7311CA7" Content-Language: en-US This is a multi-part message in MIME format. --------------C12ABAA7DBC2CDD5D7311CA7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I should be more clear.=C2=A0 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.=C2=A0 This was not my intent.=C2=A0 John states it more cl= early 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=E2=80=99s direction/sug= gestion: > > > * If there=E2=80=99s no any different opinion or objection, keep e= ither origin Numpy license or ASF license but not dual, which depends on = how MXNet=E2=80=99s source file evolves when the origin Numpy files chang= es? And the PPMC has all the authority to change the file like removing t= he additional license if needed. > > Please correct me if I mis-understand anything, and help to determine t= he best appropriate way to handle such case. Thanks! > > Best Regards, > -Ciyong > > From: Bob Paulin > Sent: Sunday, June 14, 2020 2:20 AM > To: lausen@apache.org; dev@mxnet.apache.org; general@incubator.apache.o= rg > Subject: [DISCUSS] When to add Apache Headers to Third Party Code [WAS]= Re: [MENTORS] PPMC case-by-case decision for major modifications of thir= d-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] > > > > - file copyright NumPy Developers [6] this file look to incorrectly ha= ve an ASF header on it > > .... > > 6. ./src/operator/numpy/np_einsum_path_op-inl.h > > > > We want to make the choice that will be most sustainable for the projec= t and most correct for the situation. > > Based on the emails I linked in the prior email it does seem like the c= ases where dual headers are appropriate is when there are Major Modificat= ions. In the case of > > np_einsum_path_op-inl.h > > The file is derived from the implementation in Numpy [2]. If the imple= mentation in Numpy changes will this file change? If so then the communi= ty will be tasked with continuing to re-port the changes over that is alw= ays based on Numpy so it may be more appropriate to just keep the Numpy l= icense. > > Will MXNet likely evolve this file in a way that it's no longer resembl= es the Numpy implementation (Major Modification)? If so it may be better= to keep the Apache Header as going forward the file will represent the w= ork of the MXNet community not that of Numpy. > > Hopefully the above helps clarify my perspective on how to determine ca= se by case. I don't see the dual license state as the simpler case in al= l situations. I don't believe you would have to get the original committ= er to relicense the file to you in order to remove the additional license= =2E I believe the PPMC has all the authority it needs to change the file= =2E 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 t= he conversations in support of dual licenses. Has this ever required esc= alation to an actual Lawyer in Legal? Or have these determinations been = low enough risk that we are comfortable with our PMC making best effort d= ecisions based on the ASF guidelines? > > > > - Bob > > > > [1] https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c= 6b9d3b8fa62b645763dc606045f%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 complexi= ty, > > that's why we ask for your recommendation. > > > > If it's easiest to just keep the original license header, we can do tha= t. Do we > > need the contributor to re-license their contribution, or is the contri= bution > > already available under both licenses as both license headers were incl= uded 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, q= uoting > > 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 (as= suming > > 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 shoul= d > > 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/ef46b1d0a3dd865d27a33c290430d892d3= 373d4bc5e27b5f06c7bcda%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 thir= d > > party code into the project since it increases the amount of maintenanc= e > > 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 shoul= d > > be removed. However that is just my opinion. If the PMC feels strongl= y > > 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/0fc4c0e95ee0c489553373e378125a0d16= 3bc511da2555caa68bfa87%401455903168%40%3Clegal-discuss.apache.org%3E > > > > [2] > > https://lists.apache.org/thread.html/d00f72c4aa0b56927dac87b116e2e92fa3= 2b7dcf447016726683cc4f@1455210877@%3Cgeneral.incubator.apache.org%3E > > > > [3] > > https://lists.apache.org/thread.html/e743b1b1cfda2c4775c3fe509f3adc8f69= d64fd2b6eb253ade311fe7%401451947855%40%3Cgeneral.incubator.apache.org%3E > > > > [4] https://github.com/apache/trafodion/blob/master/core/sql/parser/ule= xer.h > > > > [5] https://github.com/numpy/numpy/blob/master/numpy/core/einsumfunc.py= > > > > [6] > > https://github.com/apache/incubator-mxnet/blob/master/src/operator/nump= y/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-640= 043814 > > > > 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 Modification= s > > 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-641= 311199 > > --------------C12ABAA7DBC2CDD5D7311CA7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

I should be more clear.=C2=A0 The 2 options in the case below is

1) Numpy License Headers Only

2) Apache Header with= Numpy License Header

Re-reading my origina= l reply does sound like I'm saying the Numpy license should be removed in the case for the Apache License Headers from the file.=C2=A0 This was not my intent.=C2=A0 John states it more cle= arly 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=E2=80=99s direction/sugge=
stion:


  *   If there=E2=80=99s no any different opinion or objection,  keep eit=
her origin Numpy license or ASF license but not dual, which depends on ho=
w MXNet=E2=80=99s 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>
Sent: Sunday, June 14, 2020 2:20 AM
To: lausen@apache.org; dev@mxnet.apache.org; general@i=
ncubator.apache.org
Subject: [DISCUSS] When to add Apache Headers to Third Party Code [WAS] R=
e: [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

=2E...

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 cas=
es where dual headers are appropriate is when there are Major Modificatio=
ns.  In the case of

np_einsum_path_op-inl.h

The file is derived from the implementation in Numpy [2].  If the impleme=
ntation 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 alway=
s based on Numpy so it may be more appropriate to just keep the Numpy lic=
ense.

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 t=
o keep the Apache Header as going forward the file will represent the wor=
k 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 Mento=
rs/Incubator agree with.  I know Hen has been involved in some of the con=
versations in support of dual licenses.  Has this ever required escalatio=
n to an actual Lawyer in Legal?  Or have these determinations been low en=
ough risk that we are comfortable with our PMC making best effort decisio=
ns based on the ASF guidelines?



- Bob



[1] https://lists.apache.org/thread.html/rb=
83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incu=
bator.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 contribu=
tion

already available under both licenses as both license headers were includ=
ed by

the contributor and the ASF header can simply be deleted?



Reading through the threads you referenced, there does not seem to be a s=
trong

consensus in the ASF about how to handle this situation. For example, quo=
ting

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 (assu=
ming

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=
=2Ehtml/ef46b1d0a3dd865d27a33c290430d892d3373d4bc5e27b5f06c7bcda%40145195=
1295%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.htm=
l/0fc4c0e95ee0c489553373e378125a0d163bc511da2555caa68bfa87%401455903168%4=
0%3Clegal-discuss.apache.org%3E



[2]

https://lists.apache.org/thread.htm=
l/d00f72c4aa0b56927dac87b116e2e92fa32b7dcf447016726683cc4f@1455210877@%3C=
general.incubator.apache.org%3E



[3]

https://lists.apache.org/thread=
=2Ehtml/e743b1b1cfda2c4775c3fe509f3adc8f69d64fd2b6eb253ade311fe7%40145194=
7855%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://githu=
b.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 t=
o

quote

Haozheng who added two of the files in question:



The two files originate from >

https://github.com/numpy/numpy/blo=
b/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/LICE=
NSE.txt

https://github.com/apach=
e/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#3pa=
rty 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/apach=
e/incubator-mxnet/issues/17329#issuecomment-641311199
--------------C12ABAA7DBC2CDD5D7311CA7-- --xaAFRRUNBxynZH2hh3zC7vEvp0nRp6KJy-- --nRLZ9t1g9NzdusDEKrY1O2F58Cv77k3hp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEMzA3ISWWE8VrKGBIP5AsJ27ZviEFAl7nlbwACgkQP5AsJ27Z viHlQhAAmiMpJxYyl91VHo/6YNS4MZ0qyf4yJRGpXr+d20sTJBYH/uM8mq0XO/2a nB1NPEI2Cg5e8oj8TgOkrJPiowJsd6uZ5H6mSpVRtBZ9t1BnKbfHcvjakjh5sngv ax1rSh21vsraKnOhEMMg+nPD3VUY69fqRd28zTF9FYtSk7bz7az5djHBFExvxlJI graDJPEcB738RTYyluEj+/T9NHi5z26L15uP+81DRpo+6ZcmSP0boRqkMmqN+yLg fhN2QYxDxhg9loFffzvS9qkHvy3WCHSed0p6/hLBWVsWVEH4IKwiqCUN2yTj/OJU XdRhwZZfVTP5eTy3DdL58BPOhf5PFI3OXO1oZYzloSdSE117ZzIrKuqZC/nedc8R c1jDXKO499eOZjlLl6EXO5cxcnH/cK5KcGBVOz28STwddJqaGRi9QQVKh/JqI1lH MOcEr/FbtgUhghr6COJHWig8oyVg1kot+fRgOWxATxz4eGqHgKC4BnAoH0alDaIt LvR0BZmZ8Y6mVh6kqsXrsWtJcXXcUQyyHL3LhBlPyKR/daE/AVD9agQXKePSR6AI 6XjmTg4ksXtt5VKo4djsvZNGrEeD1L2aLcXoIZ4o/XGuxmhKAugvOATYqAr9UHW0 7j2GtpFEbnlWXm9TK6EKsmGbnz4tFbI7KD60GCT06oheGSDfvrw= =b9yP -----END PGP SIGNATURE----- --nRLZ9t1g9NzdusDEKrY1O2F58Cv77k3hp--