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