I've raised a GitHub issue [1] for the Play inspired SSL scripts - and have a PR linked to it.
With the source file headers, the -1 votes are based on cases where we believe the original Akka code neglected to retain license headers from source code that they borrowed from. If anyone finds any instances in the Pekko source where they think that we should include 3rd license headers, please raise an issue in the GitHub issues for the repo that the Pekko file exists in. Use the main repo [1] if you are not sure which repo to log the issue in. We are under no obligation to start putting Apache headers on every file, especially when we have made little or no modification to it [3]. [1] https://github.com/apache/incubator-pekko/issues/448 [2] https://github.com/apache/incubator-pekko [3] https://issues.apache.org/jira/browse/LEGAL-626 On Thu, 22 Jun 2023 at 11:43, PJ Fanning <[email protected]> wrote: > > My view on does every file need a license header: > * the Pekko community have made no meaningful changes to these shell > script files, so we don't need to add a Pekko/ASF header > * the Lightbend developers chose not to add Lightbend headers so we > shouldn't add Lightbend headers > > I don't know what to do about the Play inspired stuff. If anyone has > any ideas, could they do a PR? > > On Thu, 22 Jun 2023 at 10:29, Samuele Resca <[email protected]> wrote: > > > > Hi, > > > > I was checking the sources looking for licensing issues. > > I spotted the following files without Apache headers: [1] [2] [3] [4] [5]. > > Also, worth pointing out that [7], [8], are "inspired by" playframework > > samples (see [6]). That said, the original source is CC0 [9] > > > > Do we need to take any action here? > > > > Thanks, > > Samuele > > > > [1] https://github.com/apache/incubator-pekko/blob/main/kubernetes/setup.sh > > [2] > > https://github.com/apache/incubator-pekko/blob/main/scripts/find_fixed_tickets.sh > > [3] > > https://github.com/apache/incubator-pekko/blob/main/scripts/git-remove-history.sh > > [4] > > https://github.com/apache/incubator-pekko/blob/main/scripts/show-serializer.sh > > [5] > > https://github.com/apache/incubator-pekko/blob/main/scripts/build/github-tagging.sh > > [6] > > https://github.com/apache/incubator-pekko/blob/main/remote/src/test/resources/ssl/README.md?plain=1#L4 > > [7] > > https://github.com/apache/incubator-pekko/blob/main/remote/src/test/resources/ssl/genca.sh > > [8] > > https://github.com/apache/incubator-pekko/blob/main/remote/src/test/resources/ssl/gencerts.sh > > [9] https://github.com/playframework/play-samples/blob/2.8.x/LICENSE > > > > > > Il giorno gio 22 giu 2023 alle ore 09:04 Matthew Benedict de Detrich > > <[email protected]> ha scritto: > > > > > Yes, it was mentioned in the announcement > > > > > > > https://repository.apache.org/content/groups/staging/org/apache/pekko/ > > > > > > > In sbt, you can add this resolver. > > > > > > > resolvers += "Apache Pekko Staging" at > > > "https://repository.apache.org/content/groups/staging"; > > > > > > On Thu, 22 June 2023, 10:02 Mehmet Salgar, <[email protected]> wrote: > > > > > > > Would be a stupid question but are we publishing the release candidates > > > to > > > > any Maven Repository? > > > > > > > > > > > > > > > > > > > > Gesendet: Dienstag, 20. Juni 2023 um 09:27 Uhr > > > > Von: "Matthew Benedict de Detrich" <[email protected]> > > > > An: [email protected] > > > > Betreff: Re: [VOTE] Release Apache Pekko(incubating) 1.0.0-rc1 > > > > > 1. Do nothing and leave the files without headers (current state) > > > > 2. Add an Apache header (obviously wrong) > > > > > > > > Just to clarify, as of currently every single source file has an Apache > > > > header. This is a result of the discussions at > > > > https://issues.apache.org/jira/browse/LEGAL-626 > > > > and is also enforced by sbt-header which ensures the header is > > > > forcefully > > > > placed on source files. If we shouldn't be placing the Apache header on > > > > source files taken from 3rd parties then it should be possible to add a > > > > blacklist to sbt-header so it doesn't apply on specific source files. If > > > > this isn't possible then we can just disable sbt-header and figure out > > > the > > > > issue after a release (we shouldn't be adding new source files now > > > anyways > > > > since we are in a release period). > > > > > > > > On Tue, Jun 20, 2023 at 8:07 AM Claude Warren, Jr > > > > <[email protected]> wrote: > > > > > > > > > There seems to be 3 possible solutions for the missing headers > > > > > problem: > > > > > > > > > > > > > > > 1. Do nothing and leave the files without headers (current state) > > > > > 2. Add an Apache header (obviously wrong) > > > > > 3. Add a note that indicates where the file is from (project, version, > > > > > etc., possibly license info) and that the original file had no header. > > > > > > > > > > If we do #3 then I think the header should say something like: > > > > > > > > > > /* This file extracted from <project> <version> <originala file name> > > > > which > > > > > was in a package licensed under <license> */ > > > > > > > > > > Now, I know this technically violates the "don't change the header" > > > rule, > > > > > however, it is in line with the spirit of the "document where the file > > > is > > > > > from" rule. > > > > > > > > > > just my 2 cents, IANAL > > > > > Claude > > > > > > > > > > On Mon, Jun 19, 2023 at 5:19 PM Matthew Benedict de Detrich > > > > > <[email protected]> wrote: > > > > > > > > > > > > Correct me if I am wrong, but I don't think there is ever a case > > > > where > > > > > we > > > > > > changed an original header. If we did do something header wise, it > > > > would > > > > > be > > > > > > just adding the ASF header above the original. Some of these cases > > > > > > do > > > > > > genuinely seem that Akka/Lightbend forgot to put in headers when > > > > > > they > > > > > > should have. > > > > > > > > > > > > Maybe let me ask this more bluntly, what exactly are we supposed to > > > do > > > > in > > > > > > this case? There are source files within Akka that was taken from > > > > > > 3rd > > > > > > parties and those files either originally from the 3rd party or from > > > > Akka > > > > > > don't have headers. > > > > > > > > > > > > I don't see what we can do here aside from acknowledging the code > > > > > > was > > > > > taken > > > > > > from a 3rd source (which we are doing). Adding any header that is > > > > > > not > > > > the > > > > > > ASF just seems wrong. > > > > > > > > > > > > On Mon, Jun 19, 2023 at 5:31 PM Matthew Benedict de Detrich < > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > This is my suggestion - ask yourself: > > > > > > > - Are the copyrights in the header correct? > > > > > > > - Have the file changed significantly from their original? > > > > > > > - Is the 3rd party code just part of the files or the entire file? > > > > > > > > > > > > > > So for [5] I can say the copyright headers seem to be correct, the > > > > file > > > > > > is > > > > > > > basically unchanged from the original (which is from Scala/EPFL) > > > and > > > > > the > > > > > > > 3rd party code is for the entire file. > > > > > > > > > > > > > > [9] is slightly more complicated, the file originally had no > > > > > > > header > > > > and > > > > > > it > > > > > > > was copied from > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/lagom/online-auction-java/blob/1.4.x/bidding-impl/src/main/java/com/example/auction/bidding/impl/AuctionEntity.java[https://github.com/lagom/online-auction-java/blob/1.4.x/bidding-impl/src/main/java/com/example/auction/bidding/impl/AuctionEntity.java] > > > > > > > (as noted in the comment) which is actually from the same company > > > > > > > (Lightbend) behind Akka. My assumption here is that they didn't > > > > bother > > > > > > > putting in a header because it was the same company (Akka and > > > > > > > Lagom > > > > > both > > > > > > > owned by Lightbend). You can make an argument that the change that > > > > Akka > > > > > > did > > > > > > > to that file is significant in the sense that they converted the > > > > sample > > > > > > > code from one type of Actor System untyped to typed but IANAL. In > > > > this > > > > > > case > > > > > > > the entire file is also 3rd party code. > > > > > > > > > > > > > > > I’d use the original header. > > > > > > > > > > > > > > Correct me if I am wrong, but I don't think there is ever a case > > > > where > > > > > we > > > > > > > changed an original header. If we did do something header wise, it > > > > > would > > > > > > be > > > > > > > just adding the ASF header above the original. Some of these cases > > > do > > > > > > > genuinely seem that Akka/Lightbend forgot to put in headers when > > > they > > > > > > > should have. > > > > > > > > > > > > > > On Mon, Jun 19, 2023 at 5:21 PM Justin Mclean < > > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > >> Hi, > > > > > > >> > > > > > > >> > [5] to [9] are all files that originated from non-Lightbend > > > > sources > > > > > - > > > > > > >> > there are issues tracking all these files in the Pekko issues > > > > > tracker. > > > > > > >> > > > > > > > >> > Most of these files were added more than 10 years ago. I'm not > > > > sure > > > > > > >> > how we are going to improve on the header situation. > > > > > > >> > > > > > > >> This is my suggestion - ask yourself: > > > > > > >> - Are the copyrights in the header correct? > > > > > > >> - Have the file changed significantly from their original? > > > > > > >> - Is the 3rd party code just part of the files or the entire > > > > > > >> file? > > > > > > >> > > > > > > >> If the copywriter are incorrect OR file contents have not changed > > > > > > >> significantly (say more than 1/2 and porting to a new language or > > > > > > >> reformatting isn’t a “change”) and the 3rd party code is the > > > > majority > > > > > of > > > > > > >> the file, I’d use the original header. > > > > > > >> > > > > > > >> Or another approach might be, keep the header but a comment in > > > > > > >> it, > > > > > > adding > > > > > > >> the 3rd party copyright(s) and license to make it clear that the > > > > > > standard > > > > > > >> header may not apply to all the code in the file. > > > > > > >> > > > > > > >> Kind Regards, > > > > > > >> Justin > > > > > > >> > > > > --------------------------------------------------------------------- > > > > > > >> To unsubscribe, e-mail: [email protected] > > > > > > >> For additional commands, e-mail: [email protected] > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > > > *w:* aiven.io *e:* [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > *w:* aiven.io *e:* [email protected] > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Matthew de Detrich > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > *m:* +491603708037 > > > > > > > > *w:* aiven.io *e:* [email protected] > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
