Is there a Jira marked as blocking 2.29.0 for the cherrypick? On Fri, Mar 19, 2021 at 6:16 PM Valentyn Tymofieiev <[email protected]> wrote:
> I also noticed (with a help of an automated tool) that > https://github.com/apache/beam/blob/master/runners/google-cloud-dataflow-java/worker/src/main/resources/NOTICES > includes additional licenses not included in > https://github.com/apache/beam/blob/master/LICENSE. Is that WAI since > Dataflow runner is released as a separate jar artifact, and the licenses in > question (GPL 2.0, CDDL) pertain to its dependencies, or we need to include > those licenses as well? > > > > > On Thu, Mar 18, 2021 at 9:51 AM Ahmet Altay <[email protected]> wrote: > >> >> >> On Thu, Mar 18, 2021 at 6:39 AM Brian Hulette <[email protected]> >> wrote: >> >>> Thanks Robert! I'm +1 for reverting and engaging pkg.go.dev >>> >>> > and probably cherry pick it into the affected release branches. >>> Even if we do this, the Java artifacts from the affected releases are >>> missing the additional LICENSE text. >>> >> >> IMO we can skip the cherry picks perhaps with the exception of the >> upcoming 2.29 release. >> >>> >>> > I do not know how to interpret this ASF guide. As an example from >>> another project: airflow also has a LICENSE file, NOTICE file, and a >>> licenses directory. There are even overlapping mentions. >>> Agreed. I am a software engineer, not a lawyer, and even the ASF's guide >>> that presumably targets engineers is not particularly clear to me. This was >>> just my tenuous understanding after a quick review. >>> >> >> Agreed. We can ask LEGAL for further clarification. >> >> >>> >>> On Wed, Mar 17, 2021 at 7:49 PM Ahmet Altay <[email protected]> wrote: >>> >>>> Thank you Rebo. I agree with reverting first and then figure out the >>>> next steps. >>>> >>>> Here is a PR to revert your change: >>>> https://github.com/apache/beam/pull/14267 >>>> >>>> On Wed, Mar 17, 2021 at 4:02 PM Robert Burke <[email protected]> >>>> wrote: >>>> >>>>> Looking at the history it seems that before the python text was added, >>>>> pkg.go.dev can parse the license stack just fine. It doesn't >>>>> recognize the PSF license, and fails closed entirely as a result. >>>>> >>>>> I've filed an issue with pkg.go.dev ( >>>>> https://github.com/golang/go/issues/45095). If the bug is fixed, the >>>>> affected versions will become visible as well. >>>>> >>>>> In the meantime, we should revert my change which clobbered the other >>>>> licenses and probably cherry pick it into the affected release branches. >>>>> >>>>> The PSF license is annoying as it's explicitly unique. Nothing but >>>>> python can use it and call it the PSF license. However it is a >>>>> redistribution friendly license, which is what matters. >>>>> >>>>> On Wed, Mar 17, 2021, 3:00 PM Ahmet Altay <[email protected]> wrote: >>>>> >>>>>> Thank you for this email. >>>>>> >>>>>> >>>>>> On Wed, Mar 17, 2021 at 2:32 PM Brian Hulette <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I just noticed that there was a recent change to our LICENSE file to >>>>>>> make it exactly match the Apache 2.0 License [1]. This seems to be the >>>>>>> result of two conflicting LICENSE issues. >>>>>>> >>>>>>> Go LICENSE issue: The motivation for [1] was to satisfy pkg.go.dev's >>>>>>> license policies [2]. Prior to the change our documentation didn't show >>>>>>> up >>>>>>> there [3]. >>>>>>> >>>>>>> Java artifact LICENSE issue: The removed text contained information >>>>>>> relevant to "convenience binary distributions". This text was added in >>>>>>> [4] >>>>>>> as a result of this dev@ thread [5], where we noticed that >>>>>>> copyright notices were missing in binary artifacts. The suggested >>>>>>> solution >>>>>>> (that we went with) was to just add the information to the root (source) >>>>>>> LICENSE. >>>>>>> >>>>>> >>>>>> Python distribution is missing both files as well. ( >>>>>> https://issues.apache.org/jira/browse/BEAM-1746) >>>>>> >>>>>> >>>>>>> >>>>>>> I'm not sure that that solution is consistent with this ASF guide >>>>>>> [6] which states: >>>>>>> >>>>>>> > The LICENSE and NOTICE files must *exactly* represent the contents >>>>>>> of the distribution they reside in. Only components and resources that >>>>>>> are >>>>>>> actually included in a distribution have any bearing on the content of >>>>>>> that >>>>>>> distribution's NOTICE and LICENSE. >>>>>>> >>>>>>> I would argue that *just* Apache 2.0 is the correct text for our >>>>>>> root (source) LICENSE, and the correct way to deal with binary >>>>>>> artifacts is >>>>>>> to generate per-artifact LICENSE/NOTICE files. >>>>>>> >>>>>> >>>>>> I do not know how to interpret this ASF guide. As an example from >>>>>> another project: airflow also has a LICENSE file, NOTICE file, and a >>>>>> licenses directory. There are even overlapping mentions. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> So right now the Go issue is fixed, but the Java artifact issue has >>>>>>> regressed. I can think of two potential solutions to resolve both: >>>>>>> 1) Restore the "convenience binary distributions" information, and >>>>>>> see if we can get pkg.go.dev to allow it. >>>>>>> 2) Add infrastructure to generate LICENSE and NOTICE files for Java >>>>>>> binary artifacts. >>>>>>> >>>>>>> I have no idea how we might implement (2) so (1) seems more tenable, >>>>>>> but less correct since it's adding information not relevant to the >>>>>>> source >>>>>>> release. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>> [1] https://github.com/apache/beam/pull/11657 >>>>>>> [2] https://pkg.go.dev/license-policy >>>>>>> [3] >>>>>>> https://pkg.go.dev/github.com/apache/[email protected]+incompatible/sdks/go/pkg/beam >>>>>>> [4] https://github.com/apache/beam/pull/5461 >>>>>>> [5] >>>>>>> https://lists.apache.org/thread.html/6ef6630e908147ee83e1f1efd4befbda43efb2a59271c5cb49473103@%3Cdev.beam.apache.org%3E >>>>>>> [6] https://infra.apache.org/licensing-howto.html >>>>>>> >>>>>>
