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