I believe if we as the PMC distribute a docker image (which is optional, "convenience"), then that image has to follow the rules for binary packages [1]. (And I would assume that applies regardless where we host the images.)
Now to say that we only publish sources kind of side steps that problem. At the same time it probably also defeats the purpose of the preview release, which is to make it easier for folks that are not active contributors to take the operator for a test drive. So I'm leaning towards publishing the images with respective NOTICE requirements (for the layers that we add). We are also planning to publish the jar files in the future as it helps to build clients and those would need to have the binary NOTICE also. Cheers, Thomas [1] https://infra.apache.org/licensing-howto.html#binary On Mon, Mar 28, 2022 at 9:20 AM Gyula Fóra <gyf...@apache.org> wrote: > I see your point and the value for having such a notice added. > > I think there are 2 completely distinct questions at play here: > > a) Is there a legal requirement for a NOTICE file for the docker image? > b) If not, should we block the release on this and add it immediately? > > For a) > I think from a legal (and ASF policy) perspective there is one question > that decides whether this is a requirement for this release or not: > Is the docker image part of the release? > > I think the answer here is clearly no, the image is not part of the > release. Only the Dockerfile is part of the release. > > For b) > I think adding the NOTICE is a good idea but it will take some work so I > would not block the preview release on it. > If someone has some handy utility or experience generating it, I don't mind > including it in later RCs of course. > Otherwise we can aim for the next release. > > Gyula > > > On Mon, Mar 28, 2022 at 6:03 PM Chesnay Schepler <ches...@apache.org> > wrote: > > > One difference to Flink is that the distribution bundled in the docker > > image still contains the NOTICE covering the contents of it. > > > > It may admittedly not be the most discoverable place, but a reasonable > one > > I think. > > > > Docker as a whole is very weird when it comes to licensing. > > Think of all the things are are shipped in an image; I don't think we can > > (nor should) try to document everything in there. > > For the most part this is also not necessary as the Flink images are > based > > on Debian, > > where (al)most every installed package already embeds licensing > > information into the image. > > > > However, for content that we copy into the image (i.e., the jars), I > think > > it would be reasonable to document that. > > (and based on experience from the Flink side has also shown other > > advantages beyond licensing...) > > > > On 28/03/2022 17:41, Gyula Fóra wrote: > > > > Thanks for the input! > > > > I am not an expert on this topic and have been contemplating this myself > > also. > > We are basically trying to follow the precedent set by Flink and Statefun > > projects where the docker builds that we use to publish images to > > dockerhub do not declare any notices. > > > > We will not use ghcr.io for the final release but will use dockerhub > like > > flink and other apache projects. > > > > If I look at it from a strictly technical point of view, the docker image > > is not part of the official release (as it's also not part of the > > flink/statefun release). > > > > It would be good to get some input from others on this. It's not > > impossible to add the notices but it's considerable work and maintenance > > overhead. > > By extending the logic would you then also add license information for > the > > base images of the docker container (and so on so forth)? > > > > My gut feeling would be that we could highlight this in the NOTICE of the > > main project (or some other appropriate place) but we do not explicitly > > list the dependencies. > > > > Would be good to hear how others feel about this! > > > > Gyula > > > > On Mon, Mar 28, 2022 at 5:26 PM Chesnay Schepler <ches...@apache.org> > > wrote: > > > >> I don't think having users build the fat-jar & docker image absolves us > >> of all responsibility w.r.t. the licensing of used products. > >> > >> At the very least we need to inform users what licenses the fat-jar & > >> docker image fall under such that they can make an informed decision as > to > >> whether they can adhere to said restrictions. > >> In particular since building it yourself is (apparently) a hard > >> requirement for using said product. > >> > >> Even beyond that though, as *we* push images to ghcr.io we still need > to > >> adhere to the licensing requirements in any case afaict. > >> > >> On 28/03/2022 17:07, Gyula Fóra wrote: > >> > >> Hi Chesnay, > >> > >> Let me try to explain the "strange stuff" > >> > >> flink-kubernetes-shaded relocates some classes found in flink-kubernetes > >> in order to not conflict with some of the operator dependencies. > >> This is necessary as flink-kubernetes packages almost everything in the > >> fat-jar as-is without relocation. I think this should be fine from a > >> release perspective, as flink-kubernetes already contains the > >> relevant notice files. > >> > >> For flink-kubernetes-operator we are not releasing a fat-jar as we > don't > >> have any client binaries etc. It is not necessary for the users > therefore > >> it's not part of the release. > >> We release the Dockerfile instead so that users can build the image. > >> Since the fatjar is not part of the release we do not have bundled > >> dependencies, and we do not need extra licensing information I believe. > >> > >> Cheers, > >> Gyula > >> > >> On Mon, Mar 28, 2022 at 4:40 PM Chesnay Schepler <ches...@apache.org> > >> wrote: > >> > >>> There's some strange stuff in here. > >>> > >>> What exactly is the purpose of flink-kubernetes-shaded? You're just > >>> re-packaging flink-kubernetes without making any changes. > >>> > >>> The uploaded flink-kubernetes-operator jar isn't bundling any > >>> dependencies. Why is the fat jar not uploaded? Is it used anywhere else > >>> (e.g., directly embedded into a docker image) > >>> If it is used, where do you have the appropriate licensing information > >>> for the bundled dependencies? > >>> > >>> On 28/03/2022 16:14, Gyula Fóra wrote: > >>> > Hi everyone, > >>> > > >>> > Please review and vote on the release candidate #1 for the version > >>> 0.1.0 of > >>> > Apache Flink Kubernetes Operator, > >>> > as follows: > >>> > [ ] +1, Approve the release > >>> > [ ] -1, Do not approve the release (please provide specific comments) > >>> > > >>> > **Release Overview** > >>> > > >>> > As an overview, the release consists of the following: > >>> > a) Kubernetes Operator canonical source distribution (including the > >>> > Dockerfile), to be deployed to the release repository at > >>> dist.apache.org > >>> > b) Kubernetes Operator Helm Chart to be deployed to the release > >>> repository > >>> > at dist.apache.org > >>> > c) Maven artifacts to be deployed to the Maven Central Repository > >>> > > >>> > **Staging Areas to Review** > >>> > > >>> > The staging areas containing the above mentioned artifacts are as > >>> follows, > >>> > for your review: > >>> > * All artifacts for a,b) can be found in the corresponding dev > >>> repository > >>> > at dist.apache.org [1] > >>> > * All artifacts for c) can be found at the Apache Nexus Repository > [2] > >>> > > >>> > All artifacts are signed with the > >>> > key 911F218F79ACEA8EB453799EEE325DDEBFED467D [3] > >>> > > >>> > Other links for your review: > >>> > * JIRA release notes [4] > >>> > * source code tag "release-0.1.0-rc1" [5] > >>> > * PR to update the website Downloads page to include Kubernetes > >>> Operator > >>> > links [6] > >>> > > >>> > **Vote Duration** > >>> > > >>> > The voting time will run for at least 72 hours. > >>> > It is adopted by majority approval, with at least 3 PMC affirmative > >>> votes. > >>> > > >>> > **Note for Functional Verification** > >>> > Please use the source distribution and helm chart directly from [1] > to > >>> > build and deploy the operator in your testing environment. > >>> > > >>> > Thanks, > >>> > Gyula > >>> > > >>> > [1] > >>> > > >>> > https://dist.apache.org/repos/dist/dev/flink/flink-kubernetes-operator-0.1.0-rc1/ > >>> > [2] > >>> > https://repository.apache.org/content/repositories/orgapacheflink-1490/ > >>> > [3] https://dist.apache.org/repos/dist/release/flink/KEYS > >>> > [4] > >>> > > >>> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12351499 > >>> > [5] > >>> > > >>> > https://github.com/apache/flink-kubernetes-operator/tree/release-0.1.0-rc1 > >>> > [6] https://github.com/apache/flink-web/pull/519 > >>> > > >>> > >>> > >> > > >
