I was just proposing something in the context of not having a comprehensive answer from legal right now. But I would generally agree with Johannes that it's best to deal with now, and I support Henri's proposal.
On Fri, Nov 18, 2022 at 1:25 AM Matthew Benedict de Detrich <[email protected]> wrote: > 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] >
