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