On Thu, Jan 5, 2017 at 8:13 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> On Thu, Jan 5, 2017 at 1:32 AM, Greg Stein <gst...@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
