Given that *flink-kubernetes-shaded* already contains a NOTICE file, and *flink-kubernetes-webhook* does not bundle any dependencies. IIUC, what we should do now is to add a correct NOTICE file only for the *flink-kubernetes-operator* module.
If I do not miss anything, this would not be very difficult and I would like to fix it. Best, Yang Thomas Weise <t...@apache.org> 于2022年3月29日周二 11:25写道： > 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 > > >>> > > > >>> > > >>> > > >> > > > > > >
