incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrle Krantz <mkra...@mifos.org>
Subject Re: [DISCUSS] publishing docker image for podling
Date Fri, 06 Jan 2017 08:47:56 GMT
On Thu, Jan 5, 2017 at 8:13 PM, Roman Shaposhnik <roman@shaposhnik.org>
wrote:

> On Thu, Jan 5, 2017 at 1:32 AM, Greg Stein <gstein@gmail.com> wrote:
> > Taking off my Infrastructure hat from within that issue, and speaking to
> > this from a Foundation policy standpoint ... I think this is probably
> okay,
> > if the docker image is named (say) u/apache/incubator-singa. We allow
> > incubator projects in our github namespace as
> > github.com/apache/incubator-singa.
>
> This is orthogonal to the podling discussion, but have we settled the issue
> of any Docker container being full of not only GPLed binaries, but also,
> interesting potential trademark implications along the lines of:
>     https://mjg59.dreamwidth.org/36312.html
>
> The reason I'm raising this is because we're now talking about an official
> ASF account on DockerHub which means ramifications are Foundation-level
> (not PMC level).
>
> Apologies if it was settled and I missed it.
>

I assume based on the discussion you linked to that by the GPLed binaries
you mean the OS.  But if you look at image file specification, you'll
notice that it does not contain the OS itself, but rather a reference to an
OS:
https://github.com/docker/docker/blob/master/image/spec/v1.md

Actually, if you think about it, all binaries are dependent on one or more
OS's, and that dependency is almost always documented.    What a docker
image does differently than other forms of binary distribution is that it
documents the OS dependency explicitly and in a machine-readable form.  It
does not distribute the OS itself however -- docker itself takes care of
that.

Whether those technical truths are enough to comfort the ASF's legal
department, or the legal department of any company which wishes to use a
docker image is a question I cannot answer.  Probably, the distributors of
at least one linux distro would have to put it in writing before anyone
will feel very comfortable with it.


> > But then we also get into an area of "what happens around graduation?"
> ...
> > do we then offer both u/incubator-singa *and* u/singa ? ... If that's
> > acceptable, then this may be a simple decision. But for downstream
> > stability/continuity reasons would a podling want to *start* at
> > docker/u/singa ? ... and that is where I ask if the IPMC is willing to
> give
> > up the incubator- signal within our namespace on docker.
> >
> > And yes, I recognize the similarity to the concurrent discussion about
> > Maven Central artifacts. There are costs/benefits around continuity and
> > impacts on downstream users.
>
> I just want to point out that just like with Maven -- you can achieve
> -incubator
> tagging with versions/tags of Docker containers which will solve the naming
> issue.
>
>
And actually -incubator tagging of a docker image is a little less hairy
than it is with a maven artifact, because you don't have the issues with
transitive dependencies on version ranges and multiple routes to the same
dependency.  Docker dependency specifications are always... specific, and
you can only specify one of them per docker image.

Still, while I think the ASF is within its rights to request that a
description contain an incubation disclaimer, making requirements on tag
names is micromanaging.

Greets,
Myrle

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message