So with the discussion on the legal ticket at https://issues.apache.org/jira/browse/LEGAL-626?focusedCommentId=17635668&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17635668, it seems like the best conclusion is to just update every single source file by adding the Apache header and I think the best place to do it is with the already existing open PR at https://github.com/apache/incubator-pekko/pull/50.
Should we proceed to do this or should I binding vote be summoned instead? On Fri, Nov 18, 2022 at 9:31 PM Greg Methvin <[email protected]> wrote: > 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] > > > -- 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]
