mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lausen, Leonard" <lau...@amazon.com.INVALID>
Subject Re: Severe legal issues with releases on repository.apache.org
Date Tue, 12 May 2020 22:38:05 GMT
You're right that the compiler itself is not the problem. The resulting
dependency on libgfortran.so runtime library and the JAR including the .so file
is the problem. We can remove the .so file from the JAR and require that it's
present on the user's system. That would be similar to how we already require
presence of LGPL libc.so and libgcc.so on the user's system. (LGPL is also
Category-X)

The reason that the third-party Pypi builds don't make the same assumption for
libgfortran.so is that according to the packaging standard 
https://www.python.org/dev/peps/pep-0599/#the-manylinux2014-policy we mustn't
assume that libgfortran.so is present. By reusing the code responsible for the
Python static build, the JAR builds ended up with libgfortran.so included.

So the key question is: How common is the presence of libgfortran.so among the
users of the repository.apache.org convenience binaries. Is it reasonable to
require it? This should have been listed as Option 3) in the previous email.

Best regards
Leonard

PS: Another potential issue is the ABI. Ideally, if the ABI is stable, we can
compile OpenBLAS on CentOS 7 with libgfortran.so.3, declare a dependency on
libgfortran.so and have the resulting binary also work with libgfortran.so.4 and
libgfortran.so.5. I haven't tested that though.

On Tue, 2020-05-12 at 14:57 -0700, Tianqi Chen wrote:
> Are we really sure fortran compiler is the issue ? For example, gcc was GPL
> but has an exception for compiled-linked binaries using libc, so that the
> result binary won't be affected by GPL.
> 
> TQ
> 
> On Tue, May 12, 2020 at 2:47 PM Lausen, Leonard <lausen@amazon.com.invalid>
> wrote:
> 
> > On Tue, 2020-05-12 at 13:05 -0700, Zach Kimberg wrote:
> > > I would also like to ask how we use libgfortran? Since it is category X,
> > we
> > > should not be depending on it for any of the core functionality in MXNet.
> > > It can only have an "optional feature" (
> > > https://www.apache.org/legal/resolved.html#optional) at most.
> > Furthermore,
> > > libgfortran seems to be under the full GPL (
> > > https://github.com/gcc-mirror/gcc/blob/master/libgfortran/libgfortran.h)
> > > instead of the LGPL, so I don't know if we are even allowed to even have
> > it
> > > as an optional dependency.
> > 
> > OpenBLAS's LAPACK implementation relies on a Fortran compiler.
> > https://github.com/xianyi/OpenBLAS#dependencies The binaries on
> > repository.apache.org are of the MXNet OpenBLAS variant.
> > gfortran is typically the default choice for Fortran compiler.
> > 
> > Two options if we like to distribute official ASF convenience binaries:
> > 
> > 1) We can build OpenBLAS without LAPACK, though the operators relying on
> > 
> > https://github.com/apache/incubator-mxnet/blob/master/src/operator/c_lapack_api.h
> > are unavailable in such build.
> > 
> > 2) Investigate recent LLVM based Fortran compilers, though as far as I
> > understand they are not yet production ready:
> > 
> > https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Lands-FLANG-F18-Finally
> > Maybe there are other alternatives.
> > 
> > Best regards
> > Leonard
> > 
Mime
View raw message