Re: Severe legal issues with releases on repository.apache.org
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 > 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=LLVM-Lands-FLANG-F18-Finally > > Maybe there are other alternatives. > > > > Best regards > > Leonard > >
Re: Severe legal issues with releases on repository.apache.org
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 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=LLVM-Lands-FLANG-F18-Finally > Maybe there are other alternatives. > > Best regards > Leonard >
Re: Severe legal issues with releases on repository.apache.org
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=LLVM-Lands-FLANG-F18-Finally Maybe there are other alternatives. Best regards Leonard
Re: Severe legal issues with releases on repository.apache.org
On Tue, May 12, 2020 at 12:08 PM Lausen, Leonard wrote: > On Mon, 2020-05-11 at 13:56 -0400, Carin Meier wrote: > > Does removing the jars from both of these solutions also remove them from > > maven central? > > Does Maven Central automatically mirror jars from repository.apache.org? > Or were > these jars uploaded there manually? > The jars are automatically mirrored. This implies that we remove them from Maven Central as well. > > 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. > > Do you have any recommendation for the replacement plan? Would users be > fine > with releases not including libgfortran.so? Thus the releases will only > work on > machines that come with libgfortran.so preinstalled. Or can we just ask > them to > build from source? I don't think anyone has volunteered yet to handle > fixing the > old JVM releases, so the current requirement may be to ask JVM users to > build > from source. > > 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.
Re: Severe legal issues with releases on repository.apache.org
On Mon, 2020-05-11 at 13:56 -0400, Carin Meier wrote: > Does removing the jars from both of these solutions also remove them from > maven central? Does Maven Central automatically mirror jars from repository.apache.org? Or were these jars uploaded there manually? > > 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. Do you have any recommendation for the replacement plan? Would users be fine with releases not including libgfortran.so? Thus the releases will only work on machines that come with libgfortran.so preinstalled. Or can we just ask them to build from source? I don't think anyone has volunteered yet to handle fixing the old JVM releases, so the current requirement may be to ask JVM users to build from source. Best regards Leonard
RE: Severe legal issues with releases on repository.apache.org
Leonard, We are seeking help from NVIDIA product and legal team. I will keep you guys update once there is any progress. Thanks, -Triston -Original Message- From: Lausen, Leonard Sent: Monday, May 11, 2020 10:44 AM To: dev@mxnet.incubator.apache.org Cc: ptre...@apache.org; Triston Cao Subject: Re: Severe legal issues with releases on repository.apache.org External email: Use caution opening links or attachments On Sun, May 10, 2020 at 8:06 AM Markus Weimer wrote: > On Sat, May 9, 2020 at 10:50 PM Tianqi Chen 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 --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ---
RE: Severe legal issues with releases on repository.apache.org
Thank you, Leonard. Hi, Markus & Tianqi, It will be very helpful that you can summarize the issues. I would be happy to coordinate from NVIDIA teams to see if we can address them appropriately. Thanks, -Triston -Original Message- From: Lausen, Leonard Sent: Monday, May 11, 2020 10:44 AM To: dev@mxnet.incubator.apache.org Cc: ptre...@apache.org; Triston Cao Subject: Re: Severe legal issues with releases on repository.apache.org External email: Use caution opening links or attachments On Sun, May 10, 2020 at 8:06 AM Markus Weimer wrote: > On Sat, May 9, 2020 at 10:50 PM Tianqi Chen 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 --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ---
Re: Severe legal issues with releases on repository.apache.org
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 wrote: > On Sun, May 10, 2020 at 8:06 AM Markus Weimer wrote: > > On Sat, May 9, 2020 at 10:50 PM Tianqi Chen > 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 >
Re: Severe legal issues with releases on repository.apache.org
On Sun, May 10, 2020 at 8:06 AM Markus Weimer wrote: > On Sat, May 9, 2020 at 10:50 PM Tianqi Chen 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
Re: Severe legal issues with releases on repository.apache.org
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 TQ On Sun, May 10, 2020 at 8:06 AM Markus Weimer wrote: > On Sat, May 9, 2020 at 10:50 PM Tianqi Chen > 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? > > Markus >
Re: Severe legal issues with releases on repository.apache.org
On Sat, May 9, 2020 at 10:50 PM Tianqi Chen 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? Markus
Re: Severe legal issues with releases on repository.apache.org
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) TQ On Sat, May 9, 2020 at 7:39 PM Lausen, Leonard wrote: > They actually statically link some libraries such as libcudnn. But even > removing > that won't necessarily help. Compiling with nvcc and including cuda headers > during compilation incorporates parts of the Cuda SDK into libmxnet.so, and > makes it per the formulation of Cuda EULA subject to certain > ASF-incompatible > limitations. > > For more background on licensing of binaries, you can check the FAQ of GCC > [1]: > > > [...] if these libraries were simply distributed only under the terms of > the > > GPL, all the object code that GCC produces would have to be distributed > under > > the same terms. [...] Therefore, these libraries have always had license > > exceptions that allow people to distribute the object code GCC produces > under > > any license. > > Maybe NVidia is willing to grant a similar exception, so that libmxnet.so > can > remain Apache Licensed even containing code compiled with nvcc, but > currently > there's no such exception. > > Best regards > Leonard > > [1]: https://www.gnu.org/licenses/gcc-exception-3.1-faq.html > > > On Fri, 2020-05-08 at 22:48 -0700, Chris Olivier wrote: > > do the gpu builds actually include the nvidia cuda libraries such as > > libcudart.so or just link to them and expect them to be on the machine? > > > > > > On Fri, May 8, 2020 at 1:50 PM Lausen, Leonard > > > wrote: > > > > > Hi all, > > > > > > repository.apache.org is an official Apache Software Foundation > release > > > channel > > > and the MXNet project has been publishing convenience binaries via that > > > channel > > > since quite a while. Unfortunately it appears that no-one has > initiated a > > > license review of these convenience binaries, and unfortunately they > are > > > incompatible with the ASF requirements. They should have never been > > > uploaded. > > > > > > I recently reached out to Legal to inquire about this issue [1] and > Legal > > > team > > > recommends to remedy the situation ASAP. > > > > > > Two issues, out of the potentially larger set of all issues. > > > > > > 1) There are GPU builds (mxnet-full_2.11-linux-x86_64-gpu) > incorporating > > > the > > > CUDA SDK and possibly cuDNN, placing the resulting libmxnet.so under > the > > > CUDA > > > EULA and cuDNN SLA. This EULA and SLA contain many restrictions, making > > > them > > > Category-X licenses [1]. No Apache project must under any circumstance > > > redistribute such binaries. > > > > > > 2) All builds redistribute libgfortran.so, which is part of the GNU > Fortran > > > compiler, part of GCC and subject to the GPL. The GPL is also a > Category-X > > > license and the same restrictions apply. > > > > > > I see the following two potential remedies: > > > > > > 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 no-one steps up to do 2) or no-one suggests a better option, I > > > recommend we > > > go for option 1). Let's start discussing the options. Once discussion > has > > > settled, I'll initiate a lazy consensus or vote session. > > > > > > Note that these license rules apply to MXNet as part of the ASF. > > > Third-parties > > > (individuals or companies) may redistribute binary builds of MXNet > > > incorporating > > > Category-X licenses, IF they are appropriately labeled and no ASF > > > trademarks or > > > branding is infringed. > > > > > > As for the GPU builds, NVidia or Amazon may be willing to provide > > > third-party > > > GPU builds. I opened another ticket with Jira to see if such > third-parties > > > could > > > provide them and what considerations would need to be taken into > account. > > > [3] > > > This is similar to the Pypi releases, are third-party releases and not > > > performed > > > by the MXNet project (though also for them some legal questions remain > > > open; in > > > particular our Website does not disclaim that these are third-party > > > releases). > > > > > > Best regards > > > Leonard > > > > > > [1]: https://issues.apache.org/jira/browse/LEGAL-516 > > > [2]: https://www.apache.org/legal/resolved.html#category-x > > > [3]: https://issues.apache.org/jira/browse/LEGAL-515 > > > >
Re: Severe legal issues with releases on repository.apache.org
They actually statically link some libraries such as libcudnn. But even removing that won't necessarily help. Compiling with nvcc and including cuda headers during compilation incorporates parts of the Cuda SDK into libmxnet.so, and makes it per the formulation of Cuda EULA subject to certain ASF-incompatible limitations. For more background on licensing of binaries, you can check the FAQ of GCC [1]: > [...] if these libraries were simply distributed only under the terms of the > GPL, all the object code that GCC produces would have to be distributed under > the same terms. [...] Therefore, these libraries have always had license > exceptions that allow people to distribute the object code GCC produces under > any license. Maybe NVidia is willing to grant a similar exception, so that libmxnet.so can remain Apache Licensed even containing code compiled with nvcc, but currently there's no such exception. Best regards Leonard [1]: https://www.gnu.org/licenses/gcc-exception-3.1-faq.html On Fri, 2020-05-08 at 22:48 -0700, Chris Olivier wrote: > do the gpu builds actually include the nvidia cuda libraries such as > libcudart.so or just link to them and expect them to be on the machine? > > > On Fri, May 8, 2020 at 1:50 PM Lausen, Leonard > wrote: > > > Hi all, > > > > repository.apache.org is an official Apache Software Foundation release > > channel > > and the MXNet project has been publishing convenience binaries via that > > channel > > since quite a while. Unfortunately it appears that no-one has initiated a > > license review of these convenience binaries, and unfortunately they are > > incompatible with the ASF requirements. They should have never been > > uploaded. > > > > I recently reached out to Legal to inquire about this issue [1] and Legal > > team > > recommends to remedy the situation ASAP. > > > > Two issues, out of the potentially larger set of all issues. > > > > 1) There are GPU builds (mxnet-full_2.11-linux-x86_64-gpu) incorporating > > the > > CUDA SDK and possibly cuDNN, placing the resulting libmxnet.so under the > > CUDA > > EULA and cuDNN SLA. This EULA and SLA contain many restrictions, making > > them > > Category-X licenses [1]. No Apache project must under any circumstance > > redistribute such binaries. > > > > 2) All builds redistribute libgfortran.so, which is part of the GNU Fortran > > compiler, part of GCC and subject to the GPL. The GPL is also a Category-X > > license and the same restrictions apply. > > > > I see the following two potential remedies: > > > > 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 no-one steps up to do 2) or no-one suggests a better option, I > > recommend we > > go for option 1). Let's start discussing the options. Once discussion has > > settled, I'll initiate a lazy consensus or vote session. > > > > Note that these license rules apply to MXNet as part of the ASF. > > Third-parties > > (individuals or companies) may redistribute binary builds of MXNet > > incorporating > > Category-X licenses, IF they are appropriately labeled and no ASF > > trademarks or > > branding is infringed. > > > > As for the GPU builds, NVidia or Amazon may be willing to provide > > third-party > > GPU builds. I opened another ticket with Jira to see if such third-parties > > could > > provide them and what considerations would need to be taken into account. > > [3] > > This is similar to the Pypi releases, are third-party releases and not > > performed > > by the MXNet project (though also for them some legal questions remain > > open; in > > particular our Website does not disclaim that these are third-party > > releases). > > > > Best regards > > Leonard > > > > [1]: https://issues.apache.org/jira/browse/LEGAL-516 > > [2]: https://www.apache.org/legal/resolved.html#category-x > > [3]: https://issues.apache.org/jira/browse/LEGAL-515 > >
Re: Severe legal issues with releases on repository.apache.org
do the gpu builds actually include the nvidia cuda libraries such as libcudart.so or just link to them and expect them to be on the machine? On Fri, May 8, 2020 at 1:50 PM Lausen, Leonard wrote: > Hi all, > > repository.apache.org is an official Apache Software Foundation release > channel > and the MXNet project has been publishing convenience binaries via that > channel > since quite a while. Unfortunately it appears that no-one has initiated a > license review of these convenience binaries, and unfortunately they are > incompatible with the ASF requirements. They should have never been > uploaded. > > I recently reached out to Legal to inquire about this issue [1] and Legal > team > recommends to remedy the situation ASAP. > > Two issues, out of the potentially larger set of all issues. > > 1) There are GPU builds (mxnet-full_2.11-linux-x86_64-gpu) incorporating > the > CUDA SDK and possibly cuDNN, placing the resulting libmxnet.so under the > CUDA > EULA and cuDNN SLA. This EULA and SLA contain many restrictions, making > them > Category-X licenses [1]. No Apache project must under any circumstance > redistribute such binaries. > > 2) All builds redistribute libgfortran.so, which is part of the GNU Fortran > compiler, part of GCC and subject to the GPL. The GPL is also a Category-X > license and the same restrictions apply. > > I see the following two potential remedies: > > 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 no-one steps up to do 2) or no-one suggests a better option, I > recommend we > go for option 1). Let's start discussing the options. Once discussion has > settled, I'll initiate a lazy consensus or vote session. > > Note that these license rules apply to MXNet as part of the ASF. > Third-parties > (individuals or companies) may redistribute binary builds of MXNet > incorporating > Category-X licenses, IF they are appropriately labeled and no ASF > trademarks or > branding is infringed. > > As for the GPU builds, NVidia or Amazon may be willing to provide > third-party > GPU builds. I opened another ticket with Jira to see if such third-parties > could > provide them and what considerations would need to be taken into account. > [3] > This is similar to the Pypi releases, are third-party releases and not > performed > by the MXNet project (though also for them some legal questions remain > open; in > particular our Website does not disclaim that these are third-party > releases). > > Best regards > Leonard > > [1]: https://issues.apache.org/jira/browse/LEGAL-516 > [2]: https://www.apache.org/legal/resolved.html#category-x > [3]: https://issues.apache.org/jira/browse/LEGAL-515 >
Severe legal issues with releases on repository.apache.org
Hi all, repository.apache.org is an official Apache Software Foundation release channel and the MXNet project has been publishing convenience binaries via that channel since quite a while. Unfortunately it appears that no-one has initiated a license review of these convenience binaries, and unfortunately they are incompatible with the ASF requirements. They should have never been uploaded. I recently reached out to Legal to inquire about this issue [1] and Legal team recommends to remedy the situation ASAP. Two issues, out of the potentially larger set of all issues. 1) There are GPU builds (mxnet-full_2.11-linux-x86_64-gpu) incorporating the CUDA SDK and possibly cuDNN, placing the resulting libmxnet.so under the CUDA EULA and cuDNN SLA. This EULA and SLA contain many restrictions, making them Category-X licenses [1]. No Apache project must under any circumstance redistribute such binaries. 2) All builds redistribute libgfortran.so, which is part of the GNU Fortran compiler, part of GCC and subject to the GPL. The GPL is also a Category-X license and the same restrictions apply. I see the following two potential remedies: 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 no-one steps up to do 2) or no-one suggests a better option, I recommend we go for option 1). Let's start discussing the options. Once discussion has settled, I'll initiate a lazy consensus or vote session. Note that these license rules apply to MXNet as part of the ASF. Third-parties (individuals or companies) may redistribute binary builds of MXNet incorporating Category-X licenses, IF they are appropriately labeled and no ASF trademarks or branding is infringed. As for the GPU builds, NVidia or Amazon may be willing to provide third-party GPU builds. I opened another ticket with Jira to see if such third-parties could provide them and what considerations would need to be taken into account. [3] This is similar to the Pypi releases, are third-party releases and not performed by the MXNet project (though also for them some legal questions remain open; in particular our Website does not disclaim that these are third-party releases). Best regards Leonard [1]: https://issues.apache.org/jira/browse/LEGAL-516 [2]: https://www.apache.org/legal/resolved.html#category-x [3]: https://issues.apache.org/jira/browse/LEGAL-515
