Thanks. I understand now. If all the current jars are not compliant, then they should be removed. I also don't like the idea of "replacing" a jar on maven with another jar. It sounds like we can consider publishing cpu jars only going forward for a new release.
- Carin On Fri, May 29, 2020 at 1:32 PM Lausen, Leonard <lau...@amazon.com.invalid> wrote: > On Fri, 2020-05-29 at 12:15 -0400, Carin Meier wrote: > > > > Going forward - we with future releases, we can have all users build > their > > own packages, just for the existing ones that are compliant on maven. > > > > On Fri, May 29, 2020 at 12:14 PM Carin Meier <carinme...@gmail.com> > wrote: > > > > > Leonard, > > > > > > Is this #2 Option still on the table? > > > > > > 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..) > > > > > > It seems like it would be a better solution than deleting ALL of them, > if > > > the CPU ones are still valid and adhere to licensing. > > > At least, we would break fewer users. > > > > > > - Carin > > Yes, this is a valid option. Just to clarify, the existing CPU releases > don't > adhere to the ASF policy. But MXNet project could create new, compliant CPU > releases and upload them to repository.apache.org. Finding a way to do > this for > the existing 1.x releases would also establish a path forward to continue > creating such JARs for upcoming releases. >
