Does removing the jars from both of these solutions also remove them from maven central? > > > 1) Ask the Infra team to delete all MXNet releases on > repository.apache.org > 2) Ask the Infra team to delete all MXNet GPU releases on > repository.apache.org > and provide replacement releases without libgfortran.so and other > potentially > Category-X files (I found libmkl_ml.so in one of the JARs..)
If so, either of these options has potential to cause major disruption for users that depend on using them in production. If either of these actions are deemed necessary, we should strive to provide communication to end users and a solution for a process of how to replace them. - Carin On Mon, May 11, 2020 at 1:44 PM Lausen, Leonard <lau...@amazon.com.invalid> wrote: > On Sun, May 10, 2020 at 8:06 AM Markus Weimer <wei...@apache.org> wrote: > > On Sat, May 9, 2020 at 10:50 PM Tianqi Chen <tqc...@cs.washington.edu> > wrote: > > > > > > Seems the conclusion so far is only release source through apache and > > > release the binary builds as third party(as a different community, a > > > company or individual) > > > > Yes, that is the precedent established in multiple projects. I think > > it might still be worthwhile to pursue an exception from nvidia, > > though. Do we have any nvidia employees on the list that can inquire > > about that? > > Triston helped to establish contact with the Nvidia Legal team and we're > currently waiting for a response on their interpretation of the EULA as > well as > the possibility of an exception. It would be great to have an "internal > lobby" > for granting an GCC Runtime Library Exception style exception for nvcc in > general, or at least ASF in particular. > > On Sun, 2020-05-10 at 08:52 -0700, Tianqi Chen wrote: > > I agree, In the meanwhile. @Leonard I think we should ask > trademark@apache > > whether they would approve the use of > > > > repo names: mxnet-cu80 mxnet-cu10 etc, given that > > - they are distributed by individual contributors(as individuals and not > as > > ASF PPMC members), > > - marked as thirdparty binary > > - Build from the original ASF source with no modifications, while with an > > "optional build config" that enables CUDA acceleration support, which > > abides the rules in > https://www.apache.org/foundation/marks/downstream.html > > Currently https://issues.apache.org/jira/browse/LEGAL-515 asks similar > questions > to the Legal Team, but there is no conclusion yet. One open question in > LEGAL- > 515 is if the CD system managed in the project's source code at > https://github.com/apache/incubator-mxnet/tree/master/cd can be seen as > releasing third-party binaries given that it doesn't run on Apache > infrastructure. In the "worst case" the CD in the ASF repo must be > restricted to > build ASF-compliant binaries and third-parties need to manage their own CD > outside the Apache repo. > > Once we have clarity on that, let's continue clarifying with the > trademarks@ > team. > > Best regards > Leonard >
