To be clear this is a convenience 'binary' for end users, not just an internal packaging to aid the testing framework?
There's nothing wrong with providing an additional official packaging if we vote on it and it follows all the rules. There is an open question about how much value it adds vs that maintenance. I see we do already have some Dockerfiles, sure. Is it possible to reuse or repurpose these so that we don't have more to maintain? or: what is different from the existing Dockerfiles here? (dumb question, never paid much attention to them) We definitely can't release GPL bits or anything, yes. Just releasing a Dockerfile referring to GPL bits is a gray area - no bits are being redistributed, but, does it constitute a derived work where the GPL stuff is a non-optional dependency? Would any publishing of these images cause us to put a copy of third party GPL code anywhere? At the least, we should keep this minimal. One image if possible, that you overlay on top of your preferred OS/Java/Python image. But how much value does that add? I have no info either way that people want or don't need such a thing. On Tue, Feb 11, 2020 at 10:13 AM Erik Erlandson <eerla...@redhat.com> wrote: > > My takeaway from the last time we discussed this was: > 1) To be ASF compliant, we needed to only publish images at official releases > 2) There was some ambiguity about whether or not a container image that > included GPL'ed packages (spark images do) might trip over the GPL "viral > propagation" due to integrating ASL and GPL in a "binary release". The "air > gap" GPL provision may apply - the GPL software interacts only at > command-line boundaries. > > On Wed, Feb 5, 2020 at 1:23 PM Dongjoon Hyun <dongjoon.h...@gmail.com> wrote: >> >> Hi, All. >> >> From 2020, shall we have an official Docker image repository as an >> additional distribution channel? >> >> I'm considering the following images. >> >> - Public binary release (no snapshot image) >> - Public non-Spark base image (OS + R + Python) >> (This can be used in GitHub Action Jobs and Jenkins K8s Integration >> Tests to speed up jobs and to have more stabler environments) >> >> Bests, >> Dongjoon. --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
