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 >
