Maybe I don't understand the problem. The code that He Pin submitted changes the headers as expected. There is no issue.
The only question is whether changes are significant enough to warrant adding a license header. In most cases we know that is not the case for now. So reviews should be straightforward review of technical issues. But reviewers should consider whether or not there is enough change to warrant the license. The question is virtually the same as asking if a new copyright should be added? Is there a significant change to the IP. For most of the code from Akka that will be no. My reasoning here is that at most we are making minor changes to a) fit the new naming or b) fix a bug. For all most code the Apache license should be present and no copyright should be present. For new code with copyright (a rare thing) there is guidance from legal. Claude On Thu, Nov 17, 2022 at 3:36 PM Matthew Benedict de Detrich <[email protected]> wrote: > > For the moment the Incubator PMC is the arbiter as all releases are under > the auspices of the incubator. > > > When Pekko graduates, the Pekko PMC will be the arbiter. And the Pekko > PMC > Chair will be responsible to Legal for IP issues. > > > I hope this clarifies my stance and helps to clarify the situation. > Claude > > If this is the case can we just delegate the decision about whether (or > not) to change a header until Pekko graduates to a TLP via a single large > PR? I understand the reasoning you provide but currently due to sheer > number of PR's as well as volume files being changed it's adding way too > much overhead/bureaucracy and if we have to do this it's far more > efficient to do it all at once right before the time where it's needed. > > Johannes also provided a fair point which is that what's being done with > Pekko (i.e. a hard fork from a project that used to be under the control of > a single entity) also appears to be a first in Apache, so we should > probably approach this in a more practical manner. It appears that such > rules were in place to deal with vendor copyrighted code that had > possibility of being gradually included into Apache projects but in our > case absolutely every file has a copyright. > > On Thu, Nov 17, 2022 at 4:10 PM Claude Warren, Jr > <[email protected]> wrote: > > > In my opinion: > > > > Major changes are changes to the result of executing (or using) the file > in > > question. For the moment I am going to stick to code files as I think > the > > distinction is clearer for developers. > > > > - If the change changes the process of the execution it is generally a > > major change. For example a class called "Sort" could implement a > > bubble > > sort. Changing that to a quick sort does not change the interface > (the > > result of the call is the same) but it does change the implementation. > > The > > IP of the implementation has significantly changed. If most of the > > execution lines (non blank, non comment) changes then it is a major > > change. There are lots of edge cases here, but the point is we should > > be > > measuring the change in functionality of the execution of the file. > > > > > > - This applies to Pekko code (obviously) > > - This applies to Pekko build system code (not so obviously) > > > > The reason this is so murky is because we are playing around the edges of > > intellectual property law and no lawyer worth his/her salt will tell you > > this applies or this does not apply unless there is some case law around > > it. > > > > So now, where are we with the issue of headers. > > > > In general for most of the next few months, changes are minor (renaming > > things). There are exceptions and one is project/CopyrightHeader.scala > > < > > > https://github.com/apache/incubator-pekko/pull/50/files#diff-068e87d37c866101b33e15bb754968e8e77fd43f90f2d3ad50344742b9604113 > > > > > Originally this code updated the date in the copyright statement in each > of > > the files. If the statement did not exist it inserted it. > > The change inserts the Apache licence into the file if > > > > - There is not a copyright statement. > > - There is not an Apache license header. > > > > > > This is a change in the functionality of project/CopyrightHeader.scala > > < > > > https://github.com/apache/incubator-pekko/pull/50/files#diff-068e87d37c866101b33e15bb754968e8e77fd43f90f2d3ad50344742b9604113 > > > > > so the Apache license should be added. > > > > How much work does this entail? > > ========================= > > > > All requests will be reviewed by committers. If a committer thinks that > it > > rises to the level of a change then the submitter should add the headers > to > > the identified files. > > If there is a disagreement that it rises to that level we can have a > > discussion here or the committer can decide that it doesn't need to be > > changed. > > > > If new source is contributed and it has copyright marks in it we should > ask > > the submitter to remove the copyrights (if he/she owns them) or get a > > software-grant from the owners of the copyright. This is all part of the > > normal code review process. Most of the time it does not come up as the > > contribution is a simple file or couple of files and the author includes > > the Apache headers in them from the start. However, if there is a large > > contribution the contributor should fill out an ICLA, as all committers > > have done. > > > > So, yes there is work. No, in general, it is not a lot of work. But, > > committers have made an implied agreement to ensure that code is licensed > > under the Apache license. > > > > Who is the final arbiter? > > ================== > > > > For the moment the Incubator PMC is the arbiter as all releases are under > > the auspices of the incubator. > > > > When Pekko graduates, the Pekko PMC will be the arbiter. And the Pekko > PMC > > Chair will be responsible to Legal for IP issues. > > > > I hope this clarifies my stance and helps to clarify the situation. > > Claude > > > > On Thu, Nov 17, 2022 at 2:32 PM Johannes Rudolph < > > [email protected]> > > wrote: > > > > > I think the only way forward is to make a change right now to all of > > > the existing files, everything else will not work because it cannot be > > > automated. > > > > > > Where does this distinction between minor vs major changes come from? > > > It doesn't seem to come from the ASL. > > > > > > AFAICS, ASL says > > > > > > b. You must cause any modified files to carry prominent notices > > > stating that You changed the files; and > > > > > > This does not say, in particular, in which way you are allowed to > > > change files that contain no or minor changes. The main reason that I > > > could think of is making a misleading statement about who or what owns > > > the original copyright. > > > > > > IMO we should add a notice to all files right now that says: > > > > > > "This software is based on Akka (...). This file/repository was > > > imported from version [github url including hash]. All changes to this > > > file are licensed under ASL as shown below. Original license follows." > > > > > > How could such a message be misinterpreted to be a (mis)appropriation > > > of the original code? > > > > > > Also, consider that a file header will never tell the full story (and > > > seriously no one expects this). The most comprehensive story will be > > > told through the actual commits (and the Github PR history), and to > > > figure out who contributed which change or whether it was from the > > > original fork can only be figured out by looking through the git > > > history (and if the only thing added was the above comment, then > > > that's it, nothing misleading there). > > > > > > In > > > > > > https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140 > > > , > > > Claude mentioned some rules which seem to come from > > > https://www.apache.org/legal/src-headers.html: > > > > > > > TREATMENT OF THIRD-PARTY WORKS > > > >[...] > > > > 3. Do not add the standard Apache License header to the top of > > > third-party source files. > > > > > > I can see where that comes from, which is that vendored source code > > > should not get any gratuitous licenses (especially, if there's no > > > intention to ever change those files). > > > > > > > 4. Minor modifications/additions to third-party source files should > > > typically be licensed under the same terms as the rest of the > third-party > > > source for convenience. > > > > 5. The project's PMC should deal with major modifications/additions > to > > > third-party source files on a case-by-case basis. > > > > > > 4. + 5. seem to introduce the distinction between minor and major > > > changes. 4. is a "should" rule and also "for convenience", so maybe we > > > can just ignore that for now. 5. is probably the cause for this > > > discussion. > > > > > > In any case, for a fork the basic assumptions are quite different than > > > for other projects and, in fact, there will be changes for most files. > > > Having to decide license headers on a case-by-case basis will not work > > > for Pekko. It will not work now, because there will be no (I)PMCs that > > > will review the first release for 10ks of changes to figure out > > > whether on a case-by-case basis the license was applied directly and > > > it will not work in the future because it will make each single change > > > an unworkable act of bureaucracy. > > > > > > So, we need come up with a workable alternative now. > > > > > > On Thu, Nov 17, 2022 at 2:08 PM Matthew Benedict de Detrich > > > <[email protected]> wrote: > > > > > > > > So the problem is not new files, new files will always have a new > > Apache > > > > header (that is certain). What I am talking about is modifying > current > > > > files, for example I have an upcoming PR which changes the package > name > > > > from akka to org.apache.pekko. This PR will likely touch every single > > > .java > > > > and .scala source file and while in some cases the change is trivial > > > (i.e. > > > > literally the `package akka` to `package org.apache.pekko`), other > > > changes > > > > are not trivial at all. For example parts of the build file need to > be > > > > changed so that generated source files from protobuff go to the right > > > > package and even certain source files have to also be changed because > > > > return types with the FQN (fully qualified name) which includes the > > > package > > > > name as well. There are also cases like this > > > > > > > > > > https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937 > > > > . > > > > > > > > In summary I am starting to notice that as time goes on, even to get > to > > > the > > > > full release we will have to modify current files. Also when > discussing > > > > this with Claude, I proposed another solution which is "can we just > > make > > > it > > > > so that any change aside from just scalafmt is a major change" which > > > would > > > > mean that whenever a currently existing source file is changed in any > > way > > > > then we just add the Apache Header onto the existing Lightbend > > copyright > > > > one but I am not sure if that will fly. Legal seems to imply that we > > need > > > > to distinguish between minor and major. > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Nov 17, 2022 at 1:46 PM PJ Fanning <[email protected]> > > wrote: > > > > > > > > > I was going to suggest something similar - that if we can add new > > code > > > > > in new class files - that this simplifies the discussion. > > > > > > > > > > Obviously, this can't always be the answer because if used the > wrong > > > > > way it messes up the public API. The Lightbend headered file could > > > > > call the new code in the Apache headered file. > > > > > > > > > > In some cases, we may still need to make all the changes in the > > > > > original Lightbend headered file. And in that case, we could add > the > > > > > Apache header after the Lightbend header. > > > > > > > > > > On Thu, 17 Nov 2022 at 13:38, He Pin <[email protected]> wrote: > > > > > > > > > > > > Can we just add new apache header to newly created files, that's > a > > > much > > > > > simpler rule to follow? > > > > > > And what about the akka/stream/impl/fusing/Ops.scala which > > contains a > > > > > lots of akka stream operators? Would It be better that adding new > > > operators > > > > > to a dedicated files? > > > > > > > > > > > > > > > > > > On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote: > > > > > > > Yeah the issue is more about having to repeat this discussion > on > > > every > > > > > > > single PR due to having to agree upon what is a minor or a > major > > > > > change, > > > > > > > not about this one specifically. Another thing to keep in mind > is > > > that > > > > > > > evidently people also have different opinions on what is a > minor > > > > > change and > > > > > > > what is a major. This itself is completely fine and normal, the > > > > > problem is > > > > > > > that depending on who is reviewing a certain PR we can get > > > > > > > different results of what is minor vs major and since we are > > > dealing > > > > > with > > > > > > > legal issues here this is not exactly desirable. > > > > > > > > > > > > > > This is why I am personally leaning much towards the "lets > > > delegate all > > > > > > > these header decisions due to minor vs major change at once > just > > > before > > > > > > > release". With such a strategy it's easier to get everyone's > > > opinion > > > > > from > > > > > > > the PMCC on the matter, collectively come to some conclusion > and > > > then > > > > > as a > > > > > > > result of that conclusion we can create more clear rules going > > > forward. > > > > > > > > > > > > > > On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning < > > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > > In https://github.com/apache/incubator-pekko/pull/50 - I'd > > > prefer > > > > > to add > > > > > > > > the ASF header to the CopyrightHeader.scala file - after the > > > existing > > > > > > > > Lightbend header. > > > > > > > > > > > > > > > > I think the change is non-trivial. > > > > > > > > > > > > > > > > I think this policy would allow us to make some progress. At > > the > > > > > moment, > > > > > > > > the header issue is really jamming up the works. > > > > > > > > > > > > > > > > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote: > > > > > > > > > Currently there appears to be confusion and/or disagreement > > > > > regarding > > > > > > > > what > > > > > > > > > constitutes a minor vs major change. For context please > have > > a > > > > > look at > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140 > > > > > > > > . > > > > > > > > > > > > > > > > > > The main problem I foresee (which arguably in my opinion > has > > > > > already > > > > > > > > > started) is that due to the definition of minor vs major > > being > > > > > quite > > > > > > > > > subjective, it's already started holding up the progress of > > > doing > > > > > work on > > > > > > > > > Pekko. This has already started with the PR at > > > > > > > > > https://github.com/apache/incubator-pekko/pull/50 and also > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937 > > > > > > > > . > > > > > > > > > In short, if we are going to debate on every single PR what > > > > > constitutes a > > > > > > > > > minor or major change it's going to significantly decrease > > the > > > > > velocity > > > > > > > > of > > > > > > > > > getting stuff done. > > > > > > > > > > > > > > > > > > Would it be possible for us to come to a more > > technical/strict > > > > > definition > > > > > > > > > on what constitutes a minor or major change? The current > > > > > disagreement > > > > > > > > from > > > > > > > > > the previously mentioned PR's is about whether a change to > > the > > > > > build > > > > > > > > (which > > > > > > > > > has no effect on the execution/use of the software) is > major > > > but > > > > > there > > > > > > > > will > > > > > > > > > undoubtedly be many more cases in the future (i.e. does the > > > package > > > > > > > > rename > > > > > > > > > from akka to org.apache.pekko also count as a major change? > > > This > > > > > one is a > > > > > > > > > lot less clear). > > > > > > > > > > > > > > > > > > Alternatively is it also possible for us to suspend the > > > changing of > > > > > > > > source > > > > > > > > > headers depending on minor/major changes just before we > > decide > > > to > > > > > make a > > > > > > > > > release? This way we can completely eliminate overhead as > we > > > work > > > > > > > > towards a > > > > > > > > > release and then when a release is ready someone can > create a > > > PR > > > > > with the > > > > > > > > > necessary header changes and in that PR itself we can > discuss > > > what > > > > > is > > > > > > > > minor > > > > > > > > > and what is major. This can then be tackled at once with > > > increased > > > > > focus > > > > > > > > > and efficiency rather than having to do this work on every > PR > > > which > > > > > > > > incurs > > > > > > > > > a lot of overhead. This is especially appealing if the > > > decision of > > > > > minor > > > > > > > > vs > > > > > > > > > major is going to remain largely subjective. > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > -- > > > > > > > > > > > > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > 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] > > > > > > > > > > > > > > > > > > -- > > > > > > > > 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] > > > > > > > > > > > -- > > 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] >
