This makes no sense for me. There's only one single binding legal document which is the license of the original code which we should not interpret liberally. This license is clear that changed code files need a notice. This is well in line with the open source spirit of respecting the original owner and providing clarity of how source code is being reused. This is particularly true for the Akka code which does not even include the ASL license header, so we should be even more diligent to follow the rules of the existing license and make clear how source code is being reused and under which license. Not adding a notice (and somehow silently deferring to git history) will make it difficult both for (re)users and the original owner to understand that and how the code has been reused.
As soon as we have to add any notice, we should do it anywhere preemptively (in good faith, of course, not giving the impression of appropriating any of the existing code) as soon as possible to conclude the discussion and settle the issue for the future. IMO it's not our judgement to make whether a change should be considered minor or major. We should document our actions and comply with the license's rules and not more. We can not defer the decision about how to go forward because 1. We will only defer the decision and if we cannot come to a conclusion we want to know it rather now than later because it makes no sense to create a 1.0.0 if we cannot continue development afterwards 2. There's no agreement on what major changes are and if we need them right now. E.g. we might want to include bug fixes right now which are functional changes which minor or not definitely warrant a notice that something was changed in the file. 3. We might have to do urgent fixes in cases of security fixes which is the worst time having doubts about how exactly we can merge a change. Also, see the proposal of Henry Yandell at https://issues.apache.org/jira/browse/LEGAL-626?focusedCommentId=17635668&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17635668 which I support. On Fri, Nov 18, 2022 at 12:22 AM Matthew Benedict de Detrich <[email protected]> wrote: > > > So it sounds like we probably won't be making any "major" changes from an > IP standpoint anytime soon. I would guess that a "major" change would > generally require a PIP, so there would be some review process at that > point to decide on copyright headers. > > So generally speaking PIP is for major architectural/design/backwards > breaking changes, at least in my view there are changes outside of this > scope which could classify as major. However, the gist I am getting from > Justin is that this rule was more applicable in the old days where either > VCS didn't exist or it was a lot more primitive compared to git (in other > words if there is some sought of IP dispute/confusion it's very easy to > figure this out via git history which was more difficult in the past with > CVS/SVN or nothing at all). > > For this reason (amongst others) I would propose to classify all of the > proposed changes we are planning to do as minor and if there are any > supposed major changes in the future we can cross that bridge when we get > there. The only exception to this that I can come up with right now is the > pekko <-> akka wire incompatibility feature which was already discussed and > I would argue this is ambiguously more clear that it's theoretically a > major change (but even this could be argued is still a minor change). > > If it so happens that we have significantly more major changes than > anticipated this raises more questions than answers and more critically it > implicitly goes against our goal of a 1.0.0 release (which aside from > package renames is meant to be identical, as much as possible, to the > latest Akka ASL 2 release). > > On Fri, Nov 18, 2022 at 12:03 AM Greg Methvin <[email protected]> wrote: > > > So it sounds like we probably won't be making any "major" changes from an > > IP standpoint anytime soon. I would guess that a "major" change would > > generally require a PIP, so there would be some review process at that > > point to decide on copyright headers. > > > > The thing I don't understand, then, is why there is a distinction between > > new and existing files. It's somewhat arbitrary whether we choose to put > > code into new files or existing files. If new files are also part of a > > derivative work of the original library, then what's the justification for > > including the ASF header there versus the Lightbend header? "New" files > > could easily contain code that was moved or copied from files that are > > under Lightbend copyright, unless we are careful about it and figure out a > > way to nicely separate that code. Should we just ignore that problem for > > now? > > > > On Thu, Nov 17, 2022 at 2:15 PM Justin Mclean <[email protected]> > > wrote: > > > > > HI, > > > > > > For context, where this has been discussed before, major changes mean > > > significant changes to IP, so reformatting is not a major change, > > renaming > > > things is not a major change, an update to support a new language version > > > or porting to another language would not be a major change. Even if a > > large > > > amount of the text changes, it may not be a major change from an IP point > > > of view. As Claude said, you would need to significantly change the > > > functionality or the algorithm for it to be considered a major change. A > > > major change is when it stops being a derivative of the original and its > > > something entirely new and original. > > > > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
