If the decision from legal is to apply the header to every existing source file that contains the lightbend header then I am perfectly fine with that (this was actually one of my original suggestions).
I am just trying to be pragmatic here, because at least in my view it's currently chaos right now with everyone having different conclusions. On Fri, Nov 18, 2022 at 10:10 AM Johannes Rudolph < [email protected]> wrote: > 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] > > -- 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]
