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