You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@mxnet.apache.org by "Lausen, Leonard" <la...@amazon.com.INVALID> on 2020/05/08 20:49:49 UTC

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

RE: Severe legal issues with releases on repository.apache.org

Posted by Triston Cao <tr...@nvidia.com>.

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 <la...@amazon.com> 
Sent: Monday, May 11, 2020 10:44 AM
To: dev@mxnet.incubator.apache.org
Cc: ptrendx@apache.org; Triston Cao <tr...@nvidia.com>
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 <we...@apache.org> wrote:
> On Sat, May 9, 2020 at 10:50 PM Tianqi Chen <tq...@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

-----------------------------------------------------------------------------------
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

Posted by Triston Cao <tr...@nvidia.com>.

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 <la...@amazon.com> 
Sent: Monday, May 11, 2020 10:44 AM
To: dev@mxnet.incubator.apache.org
Cc: ptrendx@apache.org; Triston Cao <tr...@nvidia.com>
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 <we...@apache.org> wrote:
> On Sat, May 9, 2020 at 10:50 PM Tianqi Chen <tq...@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

-----------------------------------------------------------------------------------
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

Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.

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 <la...@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
> >

Re: Severe legal issues with releases on repository.apache.org

Posted by Tianqi Chen <tq...@cs.washington.edu>.

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 <la...@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
>

Re: Severe legal issues with releases on repository.apache.org

Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.

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

Re: Severe legal issues with releases on repository.apache.org

Posted by Zach Kimberg <za...@gmail.com>.

On Tue, May 12, 2020 at 12:08 PM Lausen, Leonard <la...@amazon.com.invalid>
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

Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.

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

Posted by Carin Meier <ca...@gmail.com>.

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 <la...@amazon.com.invalid>
wrote:

> On Sun, May 10, 2020 at 8:06 AM Markus Weimer <we...@apache.org> wrote:
> > On Sat, May 9, 2020 at 10:50 PM Tianqi Chen <tq...@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
>

Re: Severe legal issues with releases on repository.apache.org

Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.

On Sun, May 10, 2020 at 8:06 AM Markus Weimer <we...@apache.org> wrote:
> On Sat, May 9, 2020 at 10:50 PM Tianqi Chen <tq...@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

Re: Severe legal issues with releases on repository.apache.org

Posted by Tianqi Chen <tq...@cs.washington.edu>.

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 <we...@apache.org> wrote:

> On Sat, May 9, 2020 at 10:50 PM Tianqi Chen <tq...@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?
>
> Markus
>

Re: Severe legal issues with releases on repository.apache.org

Posted by Markus Weimer <we...@apache.org>.

On Sat, May 9, 2020 at 10:50 PM Tianqi Chen <tq...@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?

Markus

Re: Severe legal issues with releases on repository.apache.org

Posted by Tianqi Chen <tq...@cs.washington.edu>.

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 <la...@amazon.com.invalid>
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 <lausen@amazon.com.invalid
> >
> > 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

Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.

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 <la...@amazon.com.invalid>
> 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

Posted by Chris Olivier <cj...@gmail.com>.

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 <la...@amazon.com.invalid>
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: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by Carin Meier <ca...@gmail.com>.

Zach,

If you are willing and able to do that on behalf of Amazon, that would be
great.

-Carin

On Fri, May 29, 2020 at 8:35 PM Zach Kimberg <za...@gmail.com>
wrote:

> If we replace the official CPU build, won't there still be new dependencies
> so it is not even guaranteed to work depending on whether the user has the
> dependencies (e.g. libgfortran) installed? I think there is also a
> performance degradation if we remove mkl.
>
> But, we could still have a third-party build. I can try to redo the builds
> and release it on behalf of Amazon. Those builds can contain the full
> dependencies and supported environments (CPU, GPU, OSX) and are not
> restricted to Apache's license policies. Users will only have to update
> their dependency group IDs and they will get the same functionality as they
> have now.
>
> As Apache, we will only officially support JVM by building from source.
> Then, we just mention where to find the Amazon convenience builds while
> clarifying that they are not official Apache builds.
>
> On Fri, May 29, 2020 at 10:44 AM Carin Meier <ca...@gmail.com> wrote:
>
> > 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
> <lausen@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 <ca...@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.
> > >
> >
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by Zach Kimberg <za...@gmail.com>.

If we replace the official CPU build, won't there still be new dependencies
so it is not even guaranteed to work depending on whether the user has the
dependencies (e.g. libgfortran) installed? I think there is also a
performance degradation if we remove mkl.

But, we could still have a third-party build. I can try to redo the builds
and release it on behalf of Amazon. Those builds can contain the full
dependencies and supported environments (CPU, GPU, OSX) and are not
restricted to Apache's license policies. Users will only have to update
their dependency group IDs and they will get the same functionality as they
have now.

As Apache, we will only officially support JVM by building from source.
Then, we just mention where to find the Amazon convenience builds while
clarifying that they are not official Apache builds.

On Fri, May 29, 2020 at 10:44 AM Carin Meier <ca...@gmail.com> wrote:

> 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 <lausen@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 <ca...@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.
> >
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by Carin Meier <ca...@gmail.com>.

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 <la...@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 <ca...@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.
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.

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 <ca...@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.

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by Carin Meier <ca...@gmail.com>.

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 <ca...@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
>
> On Wed, May 27, 2020 at 2:18 PM Lausen, Leonard <la...@amazon.com.invalid>
> wrote:
>
>> Ok, so let's restart the lazy consensus on the removal of the Maven
>> artifacts.
>> As there were concerns that this is to rushed, let's make it a 168 hour
>> (7 day)
>> lazy consenus. I'm happy to cancel it again if anyone has a better idea
>> and
>> ressources to implement it.
>>
>> Just to clarify, similar to the Pypi packages, non-ASF third-parties
>> (individuals or companies) are free to publish Maven packages on some
>> non-ASF
>> infrastructure, as long as they don't infringe trademarks of the ASF.
>> Sheng is
>> doing that on Pypi.
>>
>> Best regards
>> Leonard
>>
>> On Wed, 2020-05-27 at 14:54 +0200, Marco de Abreu wrote:
>> > Thanks for your input Carin.
>> >
>> > In that case, I'll take back my -1 and feel free to proceed.
>> >
>> > -Marco
>> >
>> > Carin Meier <ca...@gmail.com> schrieb am Mi., 27. Mai 2020, 14:53:
>> >
>> > > Leonard,
>> > >
>> > > Thank you for putting the pull request together. Unfortunately, I
>> don't
>> > > have any bandwidth to assist with any JVM activities right now, so I
>> will
>> > > defer to those that are have time and are willing to put in the dev
>> effort.
>> > >
>> > > However, I will give my opinion that having a jar load and then fail
>> with
>> > > an error message is worse than not having the artifact on Maven at
>> all.
>> > > If it is going to fail, it should fail fast before it breaks things
>> later
>> > > in the chain.
>> > >
>> > > Removing the artifact from maven is awful and it will break users.
>> This is
>> > > undoubtably a situation that none of us want to be in, but I
>> understand
>> > > from a legal standpoint that we have no other option. The best I can
>> > > suggest is to open a preemptive issue on Github, so that users can
>> > > remediate the problem by building the package themselves.
>> > >
>> > > Let's work together to get though this the best we can and move
>> forward
>> > > towards graduation.
>> > >
>> > > Best,
>> > > Carin
>> > >
>> > > On Tue, May 26, 2020 at 9:46 PM Lausen, Leonard
>> <lausen@amazon.com.invalid
>> > > wrote:
>> > >
>> > > > Hi Marco,
>> > > >
>> > > > thank you for explaining your reasoning. Thus let's cancel the lazy
>> > > > consensus.
>> > > >
>> > > > I think we're all aware of the impact of this problem you mention
>> and I
>> > > > too am
>> > > > concerned about it. But, please note that this discussion has been
>> > > ongoing
>> > > > for
>> > > > 14 days and there has been no proposal for mitigating the problems.
>> > > Maybe 2
>> > > > weeks to you is "driven out of necessity on full speed". From my
>> > > > perspective 14
>> > > > days is a reasonable timeframe. The issues are severe and certainly
>> block
>> > > > any
>> > > > progress on the graduation of MXNet. So this issue shouldn't be
>> taken
>> > > > lightly.
>> > > >
>> > > > In either case, thank you for your belated addition of a new
>> proposal:
>> > > > "replace
>> > > > the published package with a stub with the same signatures (so it
>> loads
>> > > > properly), but throwing a fatal error message on load, linking to
>> our
>> > > > documentation and explaining the situation"
>> > > >
>> > > > It's certainly better than deleting the packages, and less effort
>> than
>> > > > re-doing
>> > > > all the releases in an ASF-compliant manner. Let's wait another few
>> days
>> > > > if any
>> > > > MXNet committers, perhaps one that is already familiar with the JVM
>> > > > packaging
>> > > > and ecosystem, will volunteer to implement this.
>> > > >
>> > > > Best regards
>> > > > Leonard
>> > > >
>> > > >
>> > > > On Wed, 2020-05-27 at 02:36 +0200, Marco de Abreu wrote:
>> > > > > Hi,
>> > > > >
>> > > > > I'm upholding my -1 until a clear path to communicate and handle
>> the
>> > > > change
>> > > > > has been provided paired with assessment to mitigate potentially
>> caused
>> > > > > damage.
>> > > > >
>> > > > > I understand that we're required to remove the releases since they
>> > > should
>> > > > > not have been there in the first place. But what you're
>> suggesting here
>> > > > is
>> > > > > to make a full stop on the highway without even turning on your
>> hazard
>> > > > > lights before. Thus, I'd recommend to take a few deep breaths (a
>> few
>> > > days
>> > > > > more or less don't hurt as long as we're working on that issue)
>> and
>> > > think
>> > > > > about a proper way to reduce the user impact. At the current
>> point,
>> > > this
>> > > > > feel like it's completely driven out of necessity on full speed
>> without
>> > > > > thinking about our users.
>> > > > >
>> > > > > Reality is that our users will be hit with a bunch of "could not
>> find
>> > > > > dependency 'mxnet'" and that's a really bad user experience.
>> > > > >
>> > > > > Instead, we should figure out how other projects are handling
>> retired
>> > > or
>> > > > > revoked packages on the various distributed platforms. One
>> example how
>> > > to
>> > > > > approach the situation could be to replace the published package
>> with a
>> > > > > stub with the same signatures (so it loads properly), but
>> throwing a
>> > > > fatal
>> > > > > error message on load, linking to our documentation and
>> explaining the
>> > > > > situation. Another way could be to talk to the publishing
>> platforms and
>> > > > > check if there's a way to replace a package with a notice so when
>> a
>> > > > > dependency management resolves it, it won't just say "not found"
>> but
>> > > > > provide meaningful information. Simply expecting that users will
>> visit
>> > > > the
>> > > > > website and figure it out is not sufficient and to me that user
>> > > > experience
>> > > > > journey has to be addressed before we purge the releases.
>> > > > >
>> > > > > Best regards,
>> > > > > Marco
>> > > > >
>> > > > > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard
>> > > > <la...@amazon.com.invalid>
>> > > > > wrote:
>> > > > >
>> > > > > > @Carin I created
>> > > https://github.com/apache/incubator-mxnet/pull/18410
>> > > > to
>> > > > > > update
>> > > > > > the documentation.
>> > > > > >
>> > > > > > @Marco The replacement is to build from source. But I'm afraid
>> that
>> > > > there's
>> > > > > > nothing to -1 here, as the existing convenience binaries are in
>> > > > violation
>> > > > > > of ASF
>> > > > > > policy and the ASF board has requested their removal. These
>> binaries
>> > > > only
>> > > > > > exists
>> > > > > > because the PPMC has previously failed to follow the ASF release
>> > > > policies
>> > > > > > for
>> > > > > > convenience binaries (the policies were only followed and
>> discussed
>> > > for
>> > > > > > source
>> > > > > > releases).
>> > > > > >
>> > > > > > If you have a different proposal to the ones discussed during
>> the
>> > > last
>> > > > 14
>> > > > > > days,
>> > > > > > please present it. If you would like to volunteer re-doing all
>> the
>> > > old
>> > > > > > convenience releases in an ASF compliant manner, that would
>> also be
>> > > > great.
>> > > > > > Please clarify this if your "-1" is intended to start a
>> procedural
>> > > vote
>> > > > > > according to [1] in which the majority of votes determines the
>> > > > outcome. In
>> > > > > > that
>> > > > > > case I suggest to change the email title to begin with [VOTE].
>> > > > Otherwise
>> > > > > > I'll
>> > > > > > assume the lazy consensus still remains.
>> > > > > >
>> > > > > > [1]: https://www.apache.org/foundation/voting.html
>> > > > > >
>> > > > > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
>> > > > > >
>> > > > > > > Do we offer any replacement for those deletions or will be
>> break
>> > > > stuff
>> > > > > > > then?
>> > > > > > >
>> > > > > > > If we break anything, I'd -1 until we found a way moving
>> forward to
>> > > > > > ensure
>> > > > > > > uninterrupted service.
>> > > > > > >
>> > > > > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <
>> carinmeier@gmail.com>
>> > > > > > wrote:
>> > > > > > > > Does anyone have any bandwidth to update installation
>> > > > documentation on
>> > > > > > the
>> > > > > > > > website, so it doesn't refer them to install it from maven?
>> > > > > > > >
>> > > > > > > > Here are the links to the gpu instructions for Scala, Java,
>> and
>> > > > > > Clojure.
>> > > > > > > > The cpu ones will also need to be updated if also removed.
>> > > > > > > >
>> > > > > > > >
>> > >
>> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
>> ;
>> > > > ;
>> > > > > > ;
>> > >
>> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
>> ;
>> > > > ;
>> > > > > > ;
>> > >
>> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
>> ;
>> > > > ;
>> > > > > > ;
>> > > > > > > > Thanks,
>> > > > > > > > Carin
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
>> > > > > > <lausen@amazon.com.invalid
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
>> > > > > > > > > > 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.
>> > > > > > > > >
>> > > > > > > > > As the discussion appears to have settled and there
>> appears to
>> > > > be no
>> > > > > > > > > progress on
>> > > > > > > > > providing replacement JARs without Category-X files for
>> old
>> > > > > > releases, I
>> > > > > > > > > would
>> > > > > > > > > like to start 72 hour lazy consensus on "Ask the Infra
>> team to
>> > > > > > delete all
>> > > > > > > > > MXNet
>> > > > > > > > > releases on repository.apache.org".
>> > > > > > > > >
>> > > > > > > > > Best regards
>> > > > > > > > > Leonard
>> > > > > > > > >
>>
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by Carin Meier <ca...@gmail.com>.

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

On Wed, May 27, 2020 at 2:18 PM Lausen, Leonard <la...@amazon.com.invalid>
wrote:

> Ok, so let's restart the lazy consensus on the removal of the Maven
> artifacts.
> As there were concerns that this is to rushed, let's make it a 168 hour (7
> day)
> lazy consenus. I'm happy to cancel it again if anyone has a better idea and
> ressources to implement it.
>
> Just to clarify, similar to the Pypi packages, non-ASF third-parties
> (individuals or companies) are free to publish Maven packages on some
> non-ASF
> infrastructure, as long as they don't infringe trademarks of the ASF.
> Sheng is
> doing that on Pypi.
>
> Best regards
> Leonard
>
> On Wed, 2020-05-27 at 14:54 +0200, Marco de Abreu wrote:
> > Thanks for your input Carin.
> >
> > In that case, I'll take back my -1 and feel free to proceed.
> >
> > -Marco
> >
> > Carin Meier <ca...@gmail.com> schrieb am Mi., 27. Mai 2020, 14:53:
> >
> > > Leonard,
> > >
> > > Thank you for putting the pull request together. Unfortunately, I don't
> > > have any bandwidth to assist with any JVM activities right now, so I
> will
> > > defer to those that are have time and are willing to put in the dev
> effort.
> > >
> > > However, I will give my opinion that having a jar load and then fail
> with
> > > an error message is worse than not having the artifact on Maven at all.
> > > If it is going to fail, it should fail fast before it breaks things
> later
> > > in the chain.
> > >
> > > Removing the artifact from maven is awful and it will break users.
> This is
> > > undoubtably a situation that none of us want to be in, but I understand
> > > from a legal standpoint that we have no other option. The best I can
> > > suggest is to open a preemptive issue on Github, so that users can
> > > remediate the problem by building the package themselves.
> > >
> > > Let's work together to get though this the best we can and move forward
> > > towards graduation.
> > >
> > > Best,
> > > Carin
> > >
> > > On Tue, May 26, 2020 at 9:46 PM Lausen, Leonard
> <lausen@amazon.com.invalid
> > > wrote:
> > >
> > > > Hi Marco,
> > > >
> > > > thank you for explaining your reasoning. Thus let's cancel the lazy
> > > > consensus.
> > > >
> > > > I think we're all aware of the impact of this problem you mention
> and I
> > > > too am
> > > > concerned about it. But, please note that this discussion has been
> > > ongoing
> > > > for
> > > > 14 days and there has been no proposal for mitigating the problems.
> > > Maybe 2
> > > > weeks to you is "driven out of necessity on full speed". From my
> > > > perspective 14
> > > > days is a reasonable timeframe. The issues are severe and certainly
> block
> > > > any
> > > > progress on the graduation of MXNet. So this issue shouldn't be taken
> > > > lightly.
> > > >
> > > > In either case, thank you for your belated addition of a new
> proposal:
> > > > "replace
> > > > the published package with a stub with the same signatures (so it
> loads
> > > > properly), but throwing a fatal error message on load, linking to our
> > > > documentation and explaining the situation"
> > > >
> > > > It's certainly better than deleting the packages, and less effort
> than
> > > > re-doing
> > > > all the releases in an ASF-compliant manner. Let's wait another few
> days
> > > > if any
> > > > MXNet committers, perhaps one that is already familiar with the JVM
> > > > packaging
> > > > and ecosystem, will volunteer to implement this.
> > > >
> > > > Best regards
> > > > Leonard
> > > >
> > > >
> > > > On Wed, 2020-05-27 at 02:36 +0200, Marco de Abreu wrote:
> > > > > Hi,
> > > > >
> > > > > I'm upholding my -1 until a clear path to communicate and handle
> the
> > > > change
> > > > > has been provided paired with assessment to mitigate potentially
> caused
> > > > > damage.
> > > > >
> > > > > I understand that we're required to remove the releases since they
> > > should
> > > > > not have been there in the first place. But what you're suggesting
> here
> > > > is
> > > > > to make a full stop on the highway without even turning on your
> hazard
> > > > > lights before. Thus, I'd recommend to take a few deep breaths (a
> few
> > > days
> > > > > more or less don't hurt as long as we're working on that issue) and
> > > think
> > > > > about a proper way to reduce the user impact. At the current point,
> > > this
> > > > > feel like it's completely driven out of necessity on full speed
> without
> > > > > thinking about our users.
> > > > >
> > > > > Reality is that our users will be hit with a bunch of "could not
> find
> > > > > dependency 'mxnet'" and that's a really bad user experience.
> > > > >
> > > > > Instead, we should figure out how other projects are handling
> retired
> > > or
> > > > > revoked packages on the various distributed platforms. One example
> how
> > > to
> > > > > approach the situation could be to replace the published package
> with a
> > > > > stub with the same signatures (so it loads properly), but throwing
> a
> > > > fatal
> > > > > error message on load, linking to our documentation and explaining
> the
> > > > > situation. Another way could be to talk to the publishing
> platforms and
> > > > > check if there's a way to replace a package with a notice so when a
> > > > > dependency management resolves it, it won't just say "not found"
> but
> > > > > provide meaningful information. Simply expecting that users will
> visit
> > > > the
> > > > > website and figure it out is not sufficient and to me that user
> > > > experience
> > > > > journey has to be addressed before we purge the releases.
> > > > >
> > > > > Best regards,
> > > > > Marco
> > > > >
> > > > > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard
> > > > <la...@amazon.com.invalid>
> > > > > wrote:
> > > > >
> > > > > > @Carin I created
> > > https://github.com/apache/incubator-mxnet/pull/18410
> > > > to
> > > > > > update
> > > > > > the documentation.
> > > > > >
> > > > > > @Marco The replacement is to build from source. But I'm afraid
> that
> > > > there's
> > > > > > nothing to -1 here, as the existing convenience binaries are in
> > > > violation
> > > > > > of ASF
> > > > > > policy and the ASF board has requested their removal. These
> binaries
> > > > only
> > > > > > exists
> > > > > > because the PPMC has previously failed to follow the ASF release
> > > > policies
> > > > > > for
> > > > > > convenience binaries (the policies were only followed and
> discussed
> > > for
> > > > > > source
> > > > > > releases).
> > > > > >
> > > > > > If you have a different proposal to the ones discussed during the
> > > last
> > > > 14
> > > > > > days,
> > > > > > please present it. If you would like to volunteer re-doing all
> the
> > > old
> > > > > > convenience releases in an ASF compliant manner, that would also
> be
> > > > great.
> > > > > > Please clarify this if your "-1" is intended to start a
> procedural
> > > vote
> > > > > > according to [1] in which the majority of votes determines the
> > > > outcome. In
> > > > > > that
> > > > > > case I suggest to change the email title to begin with [VOTE].
> > > > Otherwise
> > > > > > I'll
> > > > > > assume the lazy consensus still remains.
> > > > > >
> > > > > > [1]: https://www.apache.org/foundation/voting.html
> > > > > >
> > > > > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> > > > > >
> > > > > > > Do we offer any replacement for those deletions or will be
> break
> > > > stuff
> > > > > > > then?
> > > > > > >
> > > > > > > If we break anything, I'd -1 until we found a way moving
> forward to
> > > > > > ensure
> > > > > > > uninterrupted service.
> > > > > > >
> > > > > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <
> carinmeier@gmail.com>
> > > > > > wrote:
> > > > > > > > Does anyone have any bandwidth to update installation
> > > > documentation on
> > > > > > the
> > > > > > > > website, so it doesn't refer them to install it from maven?
> > > > > > > >
> > > > > > > > Here are the links to the gpu instructions for Scala, Java,
> and
> > > > > > Clojure.
> > > > > > > > The cpu ones will also need to be updated if also removed.
> > > > > > > >
> > > > > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
> ;
> > > > ;
> > > > > > ;
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
> ;
> > > > ;
> > > > > > ;
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
> ;
> > > > ;
> > > > > > ;
> > > > > > > > Thanks,
> > > > > > > > Carin
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > > > > > <lausen@amazon.com.invalid
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > > > > > > 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.
> > > > > > > > >
> > > > > > > > > As the discussion appears to have settled and there
> appears to
> > > > be no
> > > > > > > > > progress on
> > > > > > > > > providing replacement JARs without Category-X files for old
> > > > > > releases, I
> > > > > > > > > would
> > > > > > > > > like to start 72 hour lazy consensus on "Ask the Infra
> team to
> > > > > > delete all
> > > > > > > > > MXNet
> > > > > > > > > releases on repository.apache.org".
> > > > > > > > >
> > > > > > > > > Best regards
> > > > > > > > > Leonard
> > > > > > > > >
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.

Ok, so let's restart the lazy consensus on the removal of the Maven artifacts.
As there were concerns that this is to rushed, let's make it a 168 hour (7 day)
lazy consenus. I'm happy to cancel it again if anyone has a better idea and
ressources to implement it.

Just to clarify, similar to the Pypi packages, non-ASF third-parties
(individuals or companies) are free to publish Maven packages on some non-ASF
infrastructure, as long as they don't infringe trademarks of the ASF. Sheng is
doing that on Pypi.

Best regards
Leonard

On Wed, 2020-05-27 at 14:54 +0200, Marco de Abreu wrote:
> Thanks for your input Carin.
> 
> In that case, I'll take back my -1 and feel free to proceed.
> 
> -Marco
> 
> Carin Meier <ca...@gmail.com> schrieb am Mi., 27. Mai 2020, 14:53:
> 
> > Leonard,
> > 
> > Thank you for putting the pull request together. Unfortunately, I don't
> > have any bandwidth to assist with any JVM activities right now, so I will
> > defer to those that are have time and are willing to put in the dev effort.
> > 
> > However, I will give my opinion that having a jar load and then fail with
> > an error message is worse than not having the artifact on Maven at all.
> > If it is going to fail, it should fail fast before it breaks things later
> > in the chain.
> > 
> > Removing the artifact from maven is awful and it will break users. This is
> > undoubtably a situation that none of us want to be in, but I understand
> > from a legal standpoint that we have no other option. The best I can
> > suggest is to open a preemptive issue on Github, so that users can
> > remediate the problem by building the package themselves.
> > 
> > Let's work together to get though this the best we can and move forward
> > towards graduation.
> > 
> > Best,
> > Carin
> > 
> > On Tue, May 26, 2020 at 9:46 PM Lausen, Leonard <lausen@amazon.com.invalid
> > wrote:
> > 
> > > Hi Marco,
> > > 
> > > thank you for explaining your reasoning. Thus let's cancel the lazy
> > > consensus.
> > > 
> > > I think we're all aware of the impact of this problem you mention and I
> > > too am
> > > concerned about it. But, please note that this discussion has been
> > ongoing
> > > for
> > > 14 days and there has been no proposal for mitigating the problems.
> > Maybe 2
> > > weeks to you is "driven out of necessity on full speed". From my
> > > perspective 14
> > > days is a reasonable timeframe. The issues are severe and certainly block
> > > any
> > > progress on the graduation of MXNet. So this issue shouldn't be taken
> > > lightly.
> > > 
> > > In either case, thank you for your belated addition of a new proposal:
> > > "replace
> > > the published package with a stub with the same signatures (so it loads
> > > properly), but throwing a fatal error message on load, linking to our
> > > documentation and explaining the situation"
> > > 
> > > It's certainly better than deleting the packages, and less effort than
> > > re-doing
> > > all the releases in an ASF-compliant manner. Let's wait another few days
> > > if any
> > > MXNet committers, perhaps one that is already familiar with the JVM
> > > packaging
> > > and ecosystem, will volunteer to implement this.
> > > 
> > > Best regards
> > > Leonard
> > > 
> > > 
> > > On Wed, 2020-05-27 at 02:36 +0200, Marco de Abreu wrote:
> > > > Hi,
> > > > 
> > > > I'm upholding my -1 until a clear path to communicate and handle the
> > > change
> > > > has been provided paired with assessment to mitigate potentially caused
> > > > damage.
> > > > 
> > > > I understand that we're required to remove the releases since they
> > should
> > > > not have been there in the first place. But what you're suggesting here
> > > is
> > > > to make a full stop on the highway without even turning on your hazard
> > > > lights before. Thus, I'd recommend to take a few deep breaths (a few
> > days
> > > > more or less don't hurt as long as we're working on that issue) and
> > think
> > > > about a proper way to reduce the user impact. At the current point,
> > this
> > > > feel like it's completely driven out of necessity on full speed without
> > > > thinking about our users.
> > > > 
> > > > Reality is that our users will be hit with a bunch of "could not find
> > > > dependency 'mxnet'" and that's a really bad user experience.
> > > > 
> > > > Instead, we should figure out how other projects are handling retired
> > or
> > > > revoked packages on the various distributed platforms. One example how
> > to
> > > > approach the situation could be to replace the published package with a
> > > > stub with the same signatures (so it loads properly), but throwing a
> > > fatal
> > > > error message on load, linking to our documentation and explaining the
> > > > situation. Another way could be to talk to the publishing platforms and
> > > > check if there's a way to replace a package with a notice so when a
> > > > dependency management resolves it, it won't just say "not found" but
> > > > provide meaningful information. Simply expecting that users will visit
> > > the
> > > > website and figure it out is not sufficient and to me that user
> > > experience
> > > > journey has to be addressed before we purge the releases.
> > > > 
> > > > Best regards,
> > > > Marco
> > > > 
> > > > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard
> > > <la...@amazon.com.invalid>
> > > > wrote:
> > > > 
> > > > > @Carin I created
> > https://github.com/apache/incubator-mxnet/pull/18410
> > > to
> > > > > update
> > > > > the documentation.
> > > > > 
> > > > > @Marco The replacement is to build from source. But I'm afraid that
> > > there's
> > > > > nothing to -1 here, as the existing convenience binaries are in
> > > violation
> > > > > of ASF
> > > > > policy and the ASF board has requested their removal. These binaries
> > > only
> > > > > exists
> > > > > because the PPMC has previously failed to follow the ASF release
> > > policies
> > > > > for
> > > > > convenience binaries (the policies were only followed and discussed
> > for
> > > > > source
> > > > > releases).
> > > > > 
> > > > > If you have a different proposal to the ones discussed during the
> > last
> > > 14
> > > > > days,
> > > > > please present it. If you would like to volunteer re-doing all the
> > old
> > > > > convenience releases in an ASF compliant manner, that would also be
> > > great.
> > > > > Please clarify this if your "-1" is intended to start a procedural
> > vote
> > > > > according to [1] in which the majority of votes determines the
> > > outcome. In
> > > > > that
> > > > > case I suggest to change the email title to begin with [VOTE].
> > > Otherwise
> > > > > I'll
> > > > > assume the lazy consensus still remains.
> > > > > 
> > > > > [1]: https://www.apache.org/foundation/voting.html
> > > > > 
> > > > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> > > > > 
> > > > > > Do we offer any replacement for those deletions or will be break
> > > stuff
> > > > > > then?
> > > > > > 
> > > > > > If we break anything, I'd -1 until we found a way moving forward to
> > > > > ensure
> > > > > > uninterrupted service.
> > > > > > 
> > > > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com>
> > > > > wrote:
> > > > > > > Does anyone have any bandwidth to update installation
> > > documentation on
> > > > > the
> > > > > > > website, so it doesn't refer them to install it from maven?
> > > > > > > 
> > > > > > > Here are the links to the gpu instructions for Scala, Java, and
> > > > > Clojure.
> > > > > > > The cpu ones will also need to be updated if also removed.
> > > > > > > 
> > > > > > > 
> > https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&;
> > > ;
> > > > > ;
> > https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&;
> > > ;
> > > > > ;
> > https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&;
> > > ;
> > > > > ;
> > > > > > > Thanks,
> > > > > > > Carin
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > > > > <lausen@amazon.com.invalid
> > > > > > > wrote:
> > > > > > > 
> > > > > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > > > > > 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.
> > > > > > > > 
> > > > > > > > As the discussion appears to have settled and there appears to
> > > be no
> > > > > > > > progress on
> > > > > > > > providing replacement JARs without Category-X files for old
> > > > > releases, I
> > > > > > > > would
> > > > > > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> > > > > delete all
> > > > > > > > MXNet
> > > > > > > > releases on repository.apache.org".
> > > > > > > > 
> > > > > > > > Best regards
> > > > > > > > Leonard
> > > > > > > >

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by Marco de Abreu <ma...@gmail.com>.

Thanks for your input Carin.

In that case, I'll take back my -1 and feel free to proceed.

-Marco

Carin Meier <ca...@gmail.com> schrieb am Mi., 27. Mai 2020, 14:53:

> Leonard,
>
> Thank you for putting the pull request together. Unfortunately, I don't
> have any bandwidth to assist with any JVM activities right now, so I will
> defer to those that are have time and are willing to put in the dev effort.
>
> However, I will give my opinion that having a jar load and then fail with
> an error message is worse than not having the artifact on Maven at all.
> If it is going to fail, it should fail fast before it breaks things later
> in the chain.
>
> Removing the artifact from maven is awful and it will break users. This is
> undoubtably a situation that none of us want to be in, but I understand
> from a legal standpoint that we have no other option. The best I can
> suggest is to open a preemptive issue on Github, so that users can
> remediate the problem by building the package themselves.
>
> Let's work together to get though this the best we can and move forward
> towards graduation.
>
> Best,
> Carin
>
> On Tue, May 26, 2020 at 9:46 PM Lausen, Leonard <lausen@amazon.com.invalid
> >
> wrote:
>
> > Hi Marco,
> >
> > thank you for explaining your reasoning. Thus let's cancel the lazy
> > consensus.
> >
> > I think we're all aware of the impact of this problem you mention and I
> > too am
> > concerned about it. But, please note that this discussion has been
> ongoing
> > for
> > 14 days and there has been no proposal for mitigating the problems.
> Maybe 2
> > weeks to you is "driven out of necessity on full speed". From my
> > perspective 14
> > days is a reasonable timeframe. The issues are severe and certainly block
> > any
> > progress on the graduation of MXNet. So this issue shouldn't be taken
> > lightly.
> >
> > In either case, thank you for your belated addition of a new proposal:
> > "replace
> > the published package with a stub with the same signatures (so it loads
> > properly), but throwing a fatal error message on load, linking to our
> > documentation and explaining the situation"
> >
> > It's certainly better than deleting the packages, and less effort than
> > re-doing
> > all the releases in an ASF-compliant manner. Let's wait another few days
> > if any
> > MXNet committers, perhaps one that is already familiar with the JVM
> > packaging
> > and ecosystem, will volunteer to implement this.
> >
> > Best regards
> > Leonard
> >
> >
> > On Wed, 2020-05-27 at 02:36 +0200, Marco de Abreu wrote:
> > > Hi,
> > >
> > > I'm upholding my -1 until a clear path to communicate and handle the
> > change
> > > has been provided paired with assessment to mitigate potentially caused
> > > damage.
> > >
> > > I understand that we're required to remove the releases since they
> should
> > > not have been there in the first place. But what you're suggesting here
> > is
> > > to make a full stop on the highway without even turning on your hazard
> > > lights before. Thus, I'd recommend to take a few deep breaths (a few
> days
> > > more or less don't hurt as long as we're working on that issue) and
> think
> > > about a proper way to reduce the user impact. At the current point,
> this
> > > feel like it's completely driven out of necessity on full speed without
> > > thinking about our users.
> > >
> > > Reality is that our users will be hit with a bunch of "could not find
> > > dependency 'mxnet'" and that's a really bad user experience.
> > >
> > > Instead, we should figure out how other projects are handling retired
> or
> > > revoked packages on the various distributed platforms. One example how
> to
> > > approach the situation could be to replace the published package with a
> > > stub with the same signatures (so it loads properly), but throwing a
> > fatal
> > > error message on load, linking to our documentation and explaining the
> > > situation. Another way could be to talk to the publishing platforms and
> > > check if there's a way to replace a package with a notice so when a
> > > dependency management resolves it, it won't just say "not found" but
> > > provide meaningful information. Simply expecting that users will visit
> > the
> > > website and figure it out is not sufficient and to me that user
> > experience
> > > journey has to be addressed before we purge the releases.
> > >
> > > Best regards,
> > > Marco
> > >
> > > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard
> > <la...@amazon.com.invalid>
> > > wrote:
> > >
> > > > @Carin I created
> https://github.com/apache/incubator-mxnet/pull/18410
> > to
> > > > update
> > > > the documentation.
> > > >
> > > > @Marco The replacement is to build from source. But I'm afraid that
> > there's
> > > > nothing to -1 here, as the existing convenience binaries are in
> > violation
> > > > of ASF
> > > > policy and the ASF board has requested their removal. These binaries
> > only
> > > > exists
> > > > because the PPMC has previously failed to follow the ASF release
> > policies
> > > > for
> > > > convenience binaries (the policies were only followed and discussed
> for
> > > > source
> > > > releases).
> > > >
> > > > If you have a different proposal to the ones discussed during the
> last
> > 14
> > > > days,
> > > > please present it. If you would like to volunteer re-doing all the
> old
> > > > convenience releases in an ASF compliant manner, that would also be
> > great.
> > > >
> > > > Please clarify this if your "-1" is intended to start a procedural
> vote
> > > > according to [1] in which the majority of votes determines the
> > outcome. In
> > > > that
> > > > case I suggest to change the email title to begin with [VOTE].
> > Otherwise
> > > > I'll
> > > > assume the lazy consensus still remains.
> > > >
> > > > [1]: https://www.apache.org/foundation/voting.html
> > > >
> > > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> > > >
> > > > > Do we offer any replacement for those deletions or will be break
> > stuff
> > > > > then?
> > > > >
> > > > > If we break anything, I'd -1 until we found a way moving forward to
> > > > ensure
> > > > > uninterrupted service.
> > > > >
> > > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com>
> > > > wrote:
> > > > > > Does anyone have any bandwidth to update installation
> > documentation on
> > > > the
> > > > > > website, so it doesn't refer them to install it from maven?
> > > > > >
> > > > > > Here are the links to the gpu instructions for Scala, Java, and
> > > > Clojure.
> > > > > > The cpu ones will also need to be updated if also removed.
> > > > > >
> > > > > >
> > > >
> >
> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
> > ;
> > > > ;
> > > > > >
> > > >
> >
> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
> > ;
> > > > ;
> > > > > >
> > > >
> >
> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
> > ;
> > > > ;
> > > > > > Thanks,
> > > > > > Carin
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > > > <lausen@amazon.com.invalid
> > > > > > wrote:
> > > > > >
> > > > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > > > > 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.
> > > > > > >
> > > > > > > As the discussion appears to have settled and there appears to
> > be no
> > > > > > > progress on
> > > > > > > providing replacement JARs without Category-X files for old
> > > > releases, I
> > > > > > > would
> > > > > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> > > > delete all
> > > > > > > MXNet
> > > > > > > releases on repository.apache.org".
> > > > > > >
> > > > > > > Best regards
> > > > > > > Leonard
> > > > > > >
> >
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by Carin Meier <ca...@gmail.com>.

Leonard,

Thank you for putting the pull request together. Unfortunately, I don't
have any bandwidth to assist with any JVM activities right now, so I will
defer to those that are have time and are willing to put in the dev effort.

However, I will give my opinion that having a jar load and then fail with
an error message is worse than not having the artifact on Maven at all.
If it is going to fail, it should fail fast before it breaks things later
in the chain.

Removing the artifact from maven is awful and it will break users. This is
undoubtably a situation that none of us want to be in, but I understand
from a legal standpoint that we have no other option. The best I can
suggest is to open a preemptive issue on Github, so that users can
remediate the problem by building the package themselves.

Let's work together to get though this the best we can and move forward
towards graduation.

Best,
Carin

On Tue, May 26, 2020 at 9:46 PM Lausen, Leonard <la...@amazon.com.invalid>
wrote:

> Hi Marco,
>
> thank you for explaining your reasoning. Thus let's cancel the lazy
> consensus.
>
> I think we're all aware of the impact of this problem you mention and I
> too am
> concerned about it. But, please note that this discussion has been ongoing
> for
> 14 days and there has been no proposal for mitigating the problems. Maybe 2
> weeks to you is "driven out of necessity on full speed". From my
> perspective 14
> days is a reasonable timeframe. The issues are severe and certainly block
> any
> progress on the graduation of MXNet. So this issue shouldn't be taken
> lightly.
>
> In either case, thank you for your belated addition of a new proposal:
> "replace
> the published package with a stub with the same signatures (so it loads
> properly), but throwing a fatal error message on load, linking to our
> documentation and explaining the situation"
>
> It's certainly better than deleting the packages, and less effort than
> re-doing
> all the releases in an ASF-compliant manner. Let's wait another few days
> if any
> MXNet committers, perhaps one that is already familiar with the JVM
> packaging
> and ecosystem, will volunteer to implement this.
>
> Best regards
> Leonard
>
>
> On Wed, 2020-05-27 at 02:36 +0200, Marco de Abreu wrote:
> > Hi,
> >
> > I'm upholding my -1 until a clear path to communicate and handle the
> change
> > has been provided paired with assessment to mitigate potentially caused
> > damage.
> >
> > I understand that we're required to remove the releases since they should
> > not have been there in the first place. But what you're suggesting here
> is
> > to make a full stop on the highway without even turning on your hazard
> > lights before. Thus, I'd recommend to take a few deep breaths (a few days
> > more or less don't hurt as long as we're working on that issue) and think
> > about a proper way to reduce the user impact. At the current point, this
> > feel like it's completely driven out of necessity on full speed without
> > thinking about our users.
> >
> > Reality is that our users will be hit with a bunch of "could not find
> > dependency 'mxnet'" and that's a really bad user experience.
> >
> > Instead, we should figure out how other projects are handling retired or
> > revoked packages on the various distributed platforms. One example how to
> > approach the situation could be to replace the published package with a
> > stub with the same signatures (so it loads properly), but throwing a
> fatal
> > error message on load, linking to our documentation and explaining the
> > situation. Another way could be to talk to the publishing platforms and
> > check if there's a way to replace a package with a notice so when a
> > dependency management resolves it, it won't just say "not found" but
> > provide meaningful information. Simply expecting that users will visit
> the
> > website and figure it out is not sufficient and to me that user
> experience
> > journey has to be addressed before we purge the releases.
> >
> > Best regards,
> > Marco
> >
> > On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard
> <la...@amazon.com.invalid>
> > wrote:
> >
> > > @Carin I created https://github.com/apache/incubator-mxnet/pull/18410
> to
> > > update
> > > the documentation.
> > >
> > > @Marco The replacement is to build from source. But I'm afraid that
> there's
> > > nothing to -1 here, as the existing convenience binaries are in
> violation
> > > of ASF
> > > policy and the ASF board has requested their removal. These binaries
> only
> > > exists
> > > because the PPMC has previously failed to follow the ASF release
> policies
> > > for
> > > convenience binaries (the policies were only followed and discussed for
> > > source
> > > releases).
> > >
> > > If you have a different proposal to the ones discussed during the last
> 14
> > > days,
> > > please present it. If you would like to volunteer re-doing all the old
> > > convenience releases in an ASF compliant manner, that would also be
> great.
> > >
> > > Please clarify this if your "-1" is intended to start a procedural vote
> > > according to [1] in which the majority of votes determines the
> outcome. In
> > > that
> > > case I suggest to change the email title to begin with [VOTE].
> Otherwise
> > > I'll
> > > assume the lazy consensus still remains.
> > >
> > > [1]: https://www.apache.org/foundation/voting.html
> > >
> > > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> > >
> > > > Do we offer any replacement for those deletions or will be break
> stuff
> > > > then?
> > > >
> > > > If we break anything, I'd -1 until we found a way moving forward to
> > > ensure
> > > > uninterrupted service.
> > > >
> > > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com>
> > > wrote:
> > > > > Does anyone have any bandwidth to update installation
> documentation on
> > > the
> > > > > website, so it doesn't refer them to install it from maven?
> > > > >
> > > > > Here are the links to the gpu instructions for Scala, Java, and
> > > Clojure.
> > > > > The cpu ones will also need to be updated if also removed.
> > > > >
> > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
> ;
> > > ;
> > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
> ;
> > > ;
> > > > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
> ;
> > > ;
> > > > > Thanks,
> > > > > Carin
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > > <lausen@amazon.com.invalid
> > > > > wrote:
> > > > >
> > > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > > > 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.
> > > > > >
> > > > > > As the discussion appears to have settled and there appears to
> be no
> > > > > > progress on
> > > > > > providing replacement JARs without Category-X files for old
> > > releases, I
> > > > > > would
> > > > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> > > delete all
> > > > > > MXNet
> > > > > > releases on repository.apache.org".
> > > > > >
> > > > > > Best regards
> > > > > > Leonard
> > > > > >
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.

Hi Marco,

thank you for explaining your reasoning. Thus let's cancel the lazy consensus.

I think we're all aware of the impact of this problem you mention and I too am
concerned about it. But, please note that this discussion has been ongoing for
14 days and there has been no proposal for mitigating the problems. Maybe 2
weeks to you is "driven out of necessity on full speed". From my perspective 14
days is a reasonable timeframe. The issues are severe and certainly block any
progress on the graduation of MXNet. So this issue shouldn't be taken lightly.

In either case, thank you for your belated addition of a new proposal: "replace
the published package with a stub with the same signatures (so it loads
properly), but throwing a fatal error message on load, linking to our
documentation and explaining the situation"

It's certainly better than deleting the packages, and less effort than re-doing
all the releases in an ASF-compliant manner. Let's wait another few days if any
MXNet committers, perhaps one that is already familiar with the JVM packaging
and ecosystem, will volunteer to implement this.

Best regards
Leonard


On Wed, 2020-05-27 at 02:36 +0200, Marco de Abreu wrote:
> Hi,
> 
> I'm upholding my -1 until a clear path to communicate and handle the change
> has been provided paired with assessment to mitigate potentially caused
> damage.
> 
> I understand that we're required to remove the releases since they should
> not have been there in the first place. But what you're suggesting here is
> to make a full stop on the highway without even turning on your hazard
> lights before. Thus, I'd recommend to take a few deep breaths (a few days
> more or less don't hurt as long as we're working on that issue) and think
> about a proper way to reduce the user impact. At the current point, this
> feel like it's completely driven out of necessity on full speed without
> thinking about our users.
> 
> Reality is that our users will be hit with a bunch of "could not find
> dependency 'mxnet'" and that's a really bad user experience.
> 
> Instead, we should figure out how other projects are handling retired or
> revoked packages on the various distributed platforms. One example how to
> approach the situation could be to replace the published package with a
> stub with the same signatures (so it loads properly), but throwing a fatal
> error message on load, linking to our documentation and explaining the
> situation. Another way could be to talk to the publishing platforms and
> check if there's a way to replace a package with a notice so when a
> dependency management resolves it, it won't just say "not found" but
> provide meaningful information. Simply expecting that users will visit the
> website and figure it out is not sufficient and to me that user experience
> journey has to be addressed before we purge the releases.
> 
> Best regards,
> Marco
> 
> On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard <la...@amazon.com.invalid>
> wrote:
> 
> > @Carin I created https://github.com/apache/incubator-mxnet/pull/18410 to
> > update
> > the documentation.
> > 
> > @Marco The replacement is to build from source. But I'm afraid that there's
> > nothing to -1 here, as the existing convenience binaries are in violation
> > of ASF
> > policy and the ASF board has requested their removal. These binaries only
> > exists
> > because the PPMC has previously failed to follow the ASF release policies
> > for
> > convenience binaries (the policies were only followed and discussed for
> > source
> > releases).
> > 
> > If you have a different proposal to the ones discussed during the last 14
> > days,
> > please present it. If you would like to volunteer re-doing all the old
> > convenience releases in an ASF compliant manner, that would also be great.
> > 
> > Please clarify this if your "-1" is intended to start a procedural vote
> > according to [1] in which the majority of votes determines the outcome. In
> > that
> > case I suggest to change the email title to begin with [VOTE]. Otherwise
> > I'll
> > assume the lazy consensus still remains.
> > 
> > [1]: https://www.apache.org/foundation/voting.html
> > 
> > On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
> > 
> > > Do we offer any replacement for those deletions or will be break stuff
> > > then?
> > > 
> > > If we break anything, I'd -1 until we found a way moving forward to
> > ensure
> > > uninterrupted service.
> > > 
> > > On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com>
> > wrote:
> > > > Does anyone have any bandwidth to update installation documentation on
> > the
> > > > website, so it doesn't refer them to install it from maven?
> > > > 
> > > > Here are the links to the gpu instructions for Scala, Java, and
> > Clojure.
> > > > The cpu ones will also need to be updated if also removed.
> > > > 
> > > > 
> > https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&;
> > ;
> > > > 
> > https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&;
> > ;
> > > > 
> > https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&;
> > ;
> > > > Thanks,
> > > > Carin
> > > > 
> > > > 
> > > > 
> > > > 
> > > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> > <lausen@amazon.com.invalid
> > > > wrote:
> > > > 
> > > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > > 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.
> > > > > 
> > > > > As the discussion appears to have settled and there appears to be no
> > > > > progress on
> > > > > providing replacement JARs without Category-X files for old
> > releases, I
> > > > > would
> > > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> > delete all
> > > > > MXNet
> > > > > releases on repository.apache.org".
> > > > > 
> > > > > Best regards
> > > > > Leonard
> > > > >

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by Marco de Abreu <ma...@gmail.com>.

Hi,

I'm upholding my -1 until a clear path to communicate and handle the change
has been provided paired with assessment to mitigate potentially caused
damage.

I understand that we're required to remove the releases since they should
not have been there in the first place. But what you're suggesting here is
to make a full stop on the highway without even turning on your hazard
lights before. Thus, I'd recommend to take a few deep breaths (a few days
more or less don't hurt as long as we're working on that issue) and think
about a proper way to reduce the user impact. At the current point, this
feel like it's completely driven out of necessity on full speed without
thinking about our users.

Reality is that our users will be hit with a bunch of "could not find
dependency 'mxnet'" and that's a really bad user experience.

Instead, we should figure out how other projects are handling retired or
revoked packages on the various distributed platforms. One example how to
approach the situation could be to replace the published package with a
stub with the same signatures (so it loads properly), but throwing a fatal
error message on load, linking to our documentation and explaining the
situation. Another way could be to talk to the publishing platforms and
check if there's a way to replace a package with a notice so when a
dependency management resolves it, it won't just say "not found" but
provide meaningful information. Simply expecting that users will visit the
website and figure it out is not sufficient and to me that user experience
journey has to be addressed before we purge the releases.

Best regards,
Marco

On Wed, May 27, 2020 at 12:04 AM Lausen, Leonard <la...@amazon.com.invalid>
wrote:

> @Carin I created https://github.com/apache/incubator-mxnet/pull/18410 to
> update
> the documentation.
>
> @Marco The replacement is to build from source. But I'm afraid that there's
> nothing to -1 here, as the existing convenience binaries are in violation
> of ASF
> policy and the ASF board has requested their removal. These binaries only
> exists
> because the PPMC has previously failed to follow the ASF release policies
> for
> convenience binaries (the policies were only followed and discussed for
> source
> releases).
>
> If you have a different proposal to the ones discussed during the last 14
> days,
> please present it. If you would like to volunteer re-doing all the old
> convenience releases in an ASF compliant manner, that would also be great.
>
> Please clarify this if your "-1" is intended to start a procedural vote
> according to [1] in which the majority of votes determines the outcome. In
> that
> case I suggest to change the email title to begin with [VOTE]. Otherwise
> I'll
> assume the lazy consensus still remains.
>
> [1]: https://www.apache.org/foundation/voting.html
>
> On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:
>
> > Do we offer any replacement for those deletions or will be break stuff
> > then?
> >
> > If we break anything, I'd -1 until we found a way moving forward to
> ensure
> > uninterrupted service.
> >
> > On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com>
> wrote:
> >
> > > Does anyone have any bandwidth to update installation documentation on
> the
> > > website, so it doesn't refer them to install it from maven?
> > >
> > > Here are the links to the gpu instructions for Scala, Java, and
> Clojure.
> > > The cpu ones will also need to be updated if also removed.
> > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
> ;
> > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
> ;
> > >
> > >
> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
> ;
> > >
> > > Thanks,
> > > Carin
> > >
> > >
> > >
> > >
> > > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard
> <lausen@amazon.com.invalid
> > > wrote:
> > >
> > > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > > 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.
> > > >
> > > > As the discussion appears to have settled and there appears to be no
> > > > progress on
> > > > providing replacement JARs without Category-X files for old
> releases, I
> > > > would
> > > > like to start 72 hour lazy consensus on "Ask the Infra team to
> delete all
> > > > MXNet
> > > > releases on repository.apache.org".
> > > >
> > > > Best regards
> > > > Leonard
> > > >
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.

@Carin I created https://github.com/apache/incubator-mxnet/pull/18410 to update
the documentation.

@Marco The replacement is to build from source. But I'm afraid that there's
nothing to -1 here, as the existing convenience binaries are in violation of ASF
policy and the ASF board has requested their removal. These binaries only exists
because the PPMC has previously failed to follow the ASF release policies for
convenience binaries (the policies were only followed and discussed for source
releases).

If you have a different proposal to the ones discussed during the last 14 days,
please present it. If you would like to volunteer re-doing all the old
convenience releases in an ASF compliant manner, that would also be great.

Please clarify this if your "-1" is intended to start a procedural vote
according to [1] in which the majority of votes determines the outcome. In that
case I suggest to change the email title to begin with [VOTE]. Otherwise I'll
assume the lazy consensus still remains.

[1]: https://www.apache.org/foundation/voting.html

On Tue, 2020-05-26 at 23:44 +0200, Marco de Abreu wrote:

> Do we offer any replacement for those deletions or will be break stuff
> then?
> 
> If we break anything, I'd -1 until we found a way moving forward to ensure
> uninterrupted service.
> 
> On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com> wrote:
> 
> > Does anyone have any bandwidth to update installation documentation on the
> > website, so it doesn't refer them to install it from maven?
> > 
> > Here are the links to the gpu instructions for Scala, Java, and Clojure.
> > The cpu ones will also need to be updated if also removed.
> > 
> > https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&;
> > 
> > https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&;
> > 
> > https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&;
> > 
> > Thanks,
> > Carin
> > 
> > 
> > 
> > 
> > On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard <lausen@amazon.com.invalid
> > wrote:
> > 
> > > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > > 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.
> > > 
> > > As the discussion appears to have settled and there appears to be no
> > > progress on
> > > providing replacement JARs without Category-X files for old releases, I
> > > would
> > > like to start 72 hour lazy consensus on "Ask the Infra team to delete all
> > > MXNet
> > > releases on repository.apache.org".
> > > 
> > > Best regards
> > > Leonard
> > >

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by Marco de Abreu <ma...@gmail.com>.

Do we offer any replacement for those deletions or will be break stuff
then?

If we break anything, I'd -1 until we found a way moving forward to ensure
uninterrupted service.

On Tue, May 26, 2020 at 7:51 PM Carin Meier <ca...@gmail.com> wrote:

> Does anyone have any bandwidth to update installation documentation on the
> website, so it doesn't refer them to install it from maven?
>
> Here are the links to the gpu instructions for Scala, Java, and Clojure.
> The cpu ones will also need to be updated if also removed.
>
> https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
>
> https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
>
> https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&
>
> Thanks,
> Carin
>
>
>
>
> On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard <lausen@amazon.com.invalid
> >
> wrote:
>
> > On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > > 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.
> >
> > As the discussion appears to have settled and there appears to be no
> > progress on
> > providing replacement JARs without Category-X files for old releases, I
> > would
> > like to start 72 hour lazy consensus on "Ask the Infra team to delete all
> > MXNet
> > releases on repository.apache.org".
> >
> > Best regards
> > Leonard
> >
>

Re: [Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by Carin Meier <ca...@gmail.com>.

Does anyone have any bandwidth to update installation documentation on the
website, so it doesn't refer them to install it from maven?

Here are the links to the gpu instructions for Scala, Java, and Clojure.
The cpu ones will also need to be updated if also removed.
https://mxnet.apache.org/get_started?platform=linux&language=scala&processor=gpu&
https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&
https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&

Thanks,
Carin

On Tue, May 26, 2020 at 1:09 PM Lausen, Leonard <la...@amazon.com.invalid>
wrote:

> On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> > 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.
>
> As the discussion appears to have settled and there appears to be no
> progress on
> providing replacement JARs without Category-X files for old releases, I
> would
> like to start 72 hour lazy consensus on "Ask the Infra team to delete all
> MXNet
> releases on repository.apache.org".
>
> Best regards
> Leonard
>

[Lazy consensus] Removal of all repository.apache.org mxnet artifacts (and their mirrored maven central counterparts)

Posted by "Lausen, Leonard" <la...@amazon.com.INVALID>.

On Fri, 2020-05-08 at 20:49 +0000, Lausen, Leonard wrote:
> 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.

As the discussion appears to have settled and there appears to be no progress on
providing replacement JARs without Category-X files for old releases, I would
like to start 72 hour lazy consensus on "Ask the Infra team to delete all MXNet
releases on repository.apache.org".

Best regards
Leonard