Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

Currently there appears to be confusion and/or disagreement regarding what
constitutes a minor vs major change. For context please have a look at
https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140.

The main problem I foresee (which arguably in my opinion has already
started) is that due to the definition of minor vs major being quite
subjective, it's already started holding up the progress of doing work on
Pekko. This has already started with the PR at
https://github.com/apache/incubator-pekko/pull/50 and also at
https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937.
In short, if we are going to debate on every single PR what constitutes a
minor or major change it's going to significantly decrease the velocity of
getting stuff done.

Would it be possible for us to come to a more technical/strict definition
on what constitutes a minor or major change? The current disagreement from
the previously mentioned PR's is about whether a change to the build (which
has no effect on the execution/use of the software) is major but there will
undoubtedly be many more cases in the future (i.e. does the package rename
from akka to org.apache.pekko also count as a major change? This one is a
lot less clear).

Alternatively is it also possible for us to suspend the changing of source
headers depending on minor/major changes just before we decide to make a
release? This way we can completely eliminate overhead as we work towards a
release and then when a release is ready someone can create a PR with the
necessary header changes and in that PR itself we can discuss what is minor
and what is major. This can then be tackled at once with increased focus
and efficiency rather than having to do this work on every PR which incurs
a lot of overhead. This is especially appealing if the decision of minor vs
major is going to remain largely subjective.

Thoughts?
-- 

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:* matthew.dedetrich@aiven.io

Re: Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

Perfect (I am unfamiliar with the process so I am not sure if the matter is
resolved or not).

I assume the ticket will be commented on/closed when a resolution is made?

On Thu, 24 Nov 2022, 10:54 Justin Mclean, <ju...@classsoftware.com> wrote:

> Hi,
>
> > 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
> ,
>
> At this point I would wait until VP legal resolves the issue. (BTW people
> here may not be aware I’m assistant VP of legal affairs.)
>
> Kind Regards,
> Justin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

Re: Clarity about minor vs major change wrt source headers.

[Justin Mclean <ju...@classsoftware.com>]

Hi,

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

At this point I would wait until VP legal resolves the issue. (BTW people here may not be aware I’m assistant VP of legal affairs.)

Kind Regards,
Justin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

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 <gr...@apache.org> 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
> <ma...@aiven.io.invalid> 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 <
> > johannes.rudolph@gmail.com> 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
> > > <ma...@aiven.io.invalid> 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 <gr...@apache.org>
> > 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 <
> > > justin@classsoftware.com>
> > > > > 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: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > 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:* matthew.dedetrich@aiven.io
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
> > --
> >
> > 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:* matthew.dedetrich@aiven.io
> >
>


-- 

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:* matthew.dedetrich@aiven.io

Re: Clarity about minor vs major change wrt source headers.

[Greg Methvin <gr...@apache.org>]

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
<ma...@aiven.io.invalid> 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 <
> johannes.rudolph@gmail.com> 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
> > <ma...@aiven.io.invalid> 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 <gr...@apache.org>
> 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 <
> > justin@classsoftware.com>
> > > > 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: dev-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > 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:* matthew.dedetrich@aiven.io
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
> --
>
> 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:* matthew.dedetrich@aiven.io
>

Re: Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

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 <
johannes.rudolph@gmail.com> 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
> <ma...@aiven.io.invalid> 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 <gr...@apache.org> 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 <
> justin@classsoftware.com>
> > > 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: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> >
> > 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:* matthew.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

-- 

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:* matthew.dedetrich@aiven.io

Re: Clarity about minor vs major change wrt source headers.

[Johannes Rudolph <jo...@gmail.com>]

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
<ma...@aiven.io.invalid> 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 <gr...@apache.org> 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 <ju...@classsoftware.com>
> > 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: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
>
>
> --
>
> 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:* matthew.dedetrich@aiven.io

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

> 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 <gr...@apache.org> 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 <ju...@classsoftware.com>
> 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: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>


-- 

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:* matthew.dedetrich@aiven.io

Re: Clarity about minor vs major change wrt source headers.

[Greg Methvin <gr...@apache.org>]

I agree with Matthew that all our current proposed changes should probably
be considered "minor". So it sounds like for the time being we should:
1. Keep all Lightbend headers on existing files as-is and avoid adding new
headers.
2. For new files whose code is developed at the ASF, use the ASF notice.
3. For new files with significant portions taken from Lightbend code, use
the Lightbend notice.

Presumably most of the planned work will (or can) be done as modifications
to existing files, so we shouldn't need to be concerned much about cases 2
and 3.

Then sometime in the future we will need some clearer guidance from legal
on how to evolve the project forward without placing too much burden on
developers to judge whether or not a change is "major".

On Thu, Nov 17, 2022 at 3:51 PM Justin Mclean <ju...@classsoftware.com>
wrote:

> Hi,
>
> > The thing I don't understand, then, is why there is a distinction between
> > new and existing files.
>
> Short answer is ASF header policy. [1] If you were moving old Akka code
> into a new file, then that’s probably not a candidate for an ASF header as
> that header is only for code created at the ASF.
>
> Kind Regards,
> Justin
>
> 1. https://www.apache.org/legal/src-headers.html#headers
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

Re: Clarity about minor vs major change wrt source headers.

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> The thing I don't understand, then, is why there is a distinction between
> new and existing files.

Short answer is ASF header policy. [1] If you were moving old Akka code into a new file, then that’s probably not a candidate for an ASF header as that header is only for code created at the ASF.

Kind Regards,
Justin

1. https://www.apache.org/legal/src-headers.html#headers
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Clarity about minor vs major change wrt source headers.

[Greg Methvin <gr...@apache.org>]

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 <ju...@classsoftware.com>
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: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

Re: Clarity about minor vs major change wrt source headers.

[Justin Mclean <ju...@classsoftware.com>]

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: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Clarity about minor vs major change wrt source headers.

[Justin Mclean <ju...@classsoftware.com>]

Hi,

>> b. You must cause any modified files to carry prominent notices stating that You changed the files; and

It says that, and IANAL, but these days it is generally considered that version control history is enough to notify that changes have been made. Putting these types of notices in each modified file is not common practice, or something I have encountered at the ASF.

Kind Regards,
Justin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Clarity about minor vs major change wrt source headers.

[Johannes Rudolph <jo...@gmail.com>]

On Thu, Nov 17, 2022 at 4:55 PM Claude Warren, Jr
<cl...@aiven.io.invalid> wrote:
> The only question is whether changes are significant enough to
> warrant adding a license header.

That might be true but ASL states that

> b. You must cause any modified files to carry prominent notices stating that You changed the files; and

This seems completely unambiguous, so if we want to change any file in
any way, we must add a notice to that file to comply with the original
license terms (but not necessarily add a new license).

(In that regard the "Treatment of Third-Party Works" seems incomplete
as it is missing a clause that requires to comply with any rules
stemming from the original licenses.)

If we are required to add notices to most files anyway, why not add a
proper section that covers all cases and can be included right from
the beginning?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

We are not talking about changes just right now, but every possible change
in the future. Currently we only have 2 PR's (which are incidentally
already blocked because we can't come to an agreement for what is minor and
what is major change) but in the future there will be many more PR's,
including numerous 10k line PR's where because every change is technically
not going to be minor each individual file would have to be inspected
multiple times (and I would say if altering the build file for checking
headers is considered a major change then this opens the floodgates). This
is also just for one repo, those same 10k line PR's will have to be
repeated for every one of Pekko's repos.

If we are going to have to individually vet each file whether it has had a
major change since the inception of Pekko I would strongly suggest we
either do it at once just before it's necessary in one big PRs (since this
values everyone's times and is far more efficient) or go the carte blanche
style and just say that every change in source file is major which would
mean updating the header file in every source file just once.

I am personally already starting to feel the effects of extra
bureaucracy here and we have barely scratched the surface for the number of
PR's and changes that we have to go through to do a release and I am not
looking forward to having PR's blocked all the time because we can't agree
on what is minor or major.

On Thu, Nov 17, 2022 at 4:55 PM Claude Warren, Jr
<cl...@aiven.io.invalid> wrote:

> Maybe I don't understand the problem.
>
> The code that He Pin submitted changes the headers as expected.  There is
> no issue.
>
> The only question is whether changes are significant enough to
> warrant adding a license header.
>
> In most cases we know that is not the case for now.
>
> So reviews should be straightforward review of technical issues.  But
> reviewers should consider whether or not there is enough change to
> warrant the license.  The question is virtually the same as asking if a new
> copyright should be added?  Is there a significant change to the IP.  For
> most of the code from Akka that will be no.  My reasoning here is that at
> most we are making minor changes to a) fit the new naming or b) fix a bug.
> For all most code the Apache license should be present and no copyright
> should be present.  For new code with copyright (a rare thing) there is
> guidance from legal.
>
> Claude
>
>
> On Thu, Nov 17, 2022 at 3:36 PM Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
>
> > > For the moment the Incubator PMC is the arbiter as all releases are
> under
> > the auspices of the incubator.
> >
> > > When Pekko graduates, the Pekko PMC will be the arbiter.  And the Pekko
> > PMC
> > Chair will be responsible to Legal for IP issues.
> >
> > > I hope this clarifies my stance and helps to clarify the situation.
> > Claude
> >
> > If this is the case can we just delegate the decision about whether (or
> > not) to change a header until Pekko graduates to a TLP via a single large
> > PR? I understand the reasoning you provide but currently due to sheer
> > number of PR's as well as volume files being changed it's adding way too
> > much overhead/bureaucracy and if we have to do this it's far more
> > efficient to do it all at once right before the time where it's needed.
> >
> > Johannes also provided a fair point which is that what's being done with
> > Pekko (i.e. a hard fork from a project that used to be under the control
> of
> > a single entity) also appears to be a first in Apache, so we should
> > probably approach this in a more practical manner. It appears that such
> > rules were in place to deal with vendor copyrighted code that had
> > possibility of being gradually included into Apache projects but in our
> > case absolutely every file has a copyright.
> >
> > On Thu, Nov 17, 2022 at 4:10 PM Claude Warren, Jr
> > <cl...@aiven.io.invalid> wrote:
> >
> > > In my opinion:
> > >
> > > Major changes are changes to the result of executing (or using) the
> file
> > in
> > > question.  For the moment I am going to stick to code files as I think
> > the
> > > distinction is clearer for developers.
> > >
> > >    - If the change changes the process of the execution it is
> generally a
> > >    major change.  For example a class called "Sort" could implement a
> > > bubble
> > >    sort.  Changing that to a quick sort does not change the interface
> > (the
> > >    result of the call is the same) but it does change the
> implementation.
> > > The
> > >    IP of the implementation has significantly changed.  If most of the
> > >    execution lines (non blank, non comment) changes then it is a major
> > >    change.  There are lots of edge cases here, but the point is we
> should
> > > be
> > >    measuring the change in functionality of the execution of the file.
> > >
> > >
> > >    - This applies to Pekko code (obviously)
> > >       - This applies to Pekko build system code (not so obviously)
> > >
> > > The reason this is so murky is because we are playing around the edges
> of
> > > intellectual property law and no lawyer worth his/her salt will tell
> you
> > > this applies or this does not apply unless there is some case law
> around
> > > it.
> > >
> > > So now, where are we with the issue of headers.
> > >
> > > In general for most of the next few months, changes are minor (renaming
> > > things).  There are exceptions and one is
> project/CopyrightHeader.scala
> > > <
> > >
> >
> https://github.com/apache/incubator-pekko/pull/50/files#diff-068e87d37c866101b33e15bb754968e8e77fd43f90f2d3ad50344742b9604113
> > > >
> > > Originally this code updated the date in the copyright statement in
> each
> > of
> > > the files.  If the statement did not exist it inserted it.
> > > The change inserts the Apache licence into the file if
> > >
> > >    - There is not a copyright statement.
> > >    - There is not an Apache license header.
> > >
> > >
> > > This is a change in the functionality of project/CopyrightHeader.scala
> > > <
> > >
> >
> https://github.com/apache/incubator-pekko/pull/50/files#diff-068e87d37c866101b33e15bb754968e8e77fd43f90f2d3ad50344742b9604113
> > > >
> > > so the Apache license should be added.
> > >
> > > How much work does this entail?
> > > =========================
> > >
> > > All requests will be reviewed by committers.  If a committer thinks
> that
> > it
> > > rises to the level of a change then the submitter should add the
> headers
> > to
> > > the identified files.
> > > If there is a disagreement that it rises to that level we can have a
> > > discussion here or the committer can decide that it doesn't need to be
> > > changed.
> > >
> > > If new source is contributed and it has copyright marks in it we should
> > ask
> > > the submitter to remove the copyrights (if he/she owns them) or get a
> > > software-grant from the owners of the copyright.  This is all part of
> the
> > > normal code review process.  Most of the time it does not come up as
> the
> > > contribution is a simple file or couple of files and the author
> includes
> > > the Apache headers in them from the start.  However, if there is a
> large
> > > contribution the contributor should fill out an ICLA, as all committers
> > > have done.
> > >
> > > So, yes there is work.  No, in general, it is not a lot of work.  But,
> > > committers have made an implied agreement to ensure that code is
> licensed
> > > under the Apache license.
> > >
> > > Who is the final arbiter?
> > > ==================
> > >
> > > For the moment the Incubator PMC is the arbiter as all releases are
> under
> > > the auspices of the incubator.
> > >
> > > When Pekko graduates, the Pekko PMC will be the arbiter.  And the Pekko
> > PMC
> > > Chair will be responsible to Legal for IP issues.
> > >
> > > I hope this clarifies my stance and helps to clarify the situation.
> > > Claude
> > >
> > > On Thu, Nov 17, 2022 at 2:32 PM Johannes Rudolph <
> > > johannes.rudolph@gmail.com>
> > > wrote:
> > >
> > > > I think the only way forward is to make a change right now to all of
> > > > the existing files, everything else will not work because it cannot
> be
> > > > automated.
> > > >
> > > > Where does this distinction between minor vs major changes come from?
> > > > It doesn't seem to come from the ASL.
> > > >
> > > > AFAICS, ASL says
> > > >
> > > >  b. You must cause any modified files to carry prominent notices
> > > > stating that You changed the files; and
> > > >
> > > > This does not say, in particular, in which way you are allowed to
> > > > change files that contain no or minor changes. The main reason that I
> > > > could think of is making a misleading statement about who or what
> owns
> > > > the original copyright.
> > > >
> > > > IMO we should add a notice to all files right now that says:
> > > >
> > > > "This software is based on Akka (...). This file/repository was
> > > > imported from version [github url including hash]. All changes to
> this
> > > > file are licensed under ASL as shown below. Original license
> follows."
> > > >
> > > > How could such a message be misinterpreted to be a (mis)appropriation
> > > > of the original code?
> > > >
> > > > Also, consider that a file header will never tell the full story (and
> > > > seriously no one expects this). The most comprehensive story will be
> > > > told through the actual commits (and the Github PR history), and to
> > > > figure out who contributed which change or whether it was from the
> > > > original fork can only be figured out by looking through the git
> > > > history (and if the only thing added was the above comment, then
> > > > that's it, nothing misleading there).
> > > >
> > > > In
> > > >
> > >
> >
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > > > ,
> > > > Claude mentioned some rules which seem to come from
> > > > https://www.apache.org/legal/src-headers.html:
> > > >
> > > > > TREATMENT OF THIRD-PARTY WORKS
> > > > >[...]
> > > > > 3. Do not add the standard Apache License header to the top of
> > > > third-party source files.
> > > >
> > > > I can see where that comes from, which is that vendored source code
> > > > should not get any gratuitous licenses (especially, if there's no
> > > > intention to ever change those files).
> > > >
> > > > > 4. Minor modifications/additions to third-party source files should
> > > > typically be licensed under the same terms as the rest of the
> > third-party
> > > > source for convenience.
> > > > > 5. The project's PMC should deal with major modifications/additions
> > to
> > > > third-party source files on a case-by-case basis.
> > > >
> > > > 4. + 5. seem to introduce the distinction between minor and major
> > > > changes. 4. is a "should" rule and also "for convenience", so maybe
> we
> > > > can just ignore that for now. 5. is probably the cause for this
> > > > discussion.
> > > >
> > > > In any case, for a fork the basic assumptions are quite different
> than
> > > > for other projects and, in fact, there will be changes for most
> files.
> > > > Having to decide license headers on a case-by-case basis will not
> work
> > > > for Pekko. It will not work now, because there will be no (I)PMCs
> that
> > > > will review the first release for 10ks of changes to figure out
> > > > whether on a case-by-case basis the license was applied directly and
> > > > it will not work in the future because it will make each single
> change
> > > > an unworkable act of bureaucracy.
> > > >
> > > > So, we need come up with a workable alternative now.
> > > >
> > > > On Thu, Nov 17, 2022 at 2:08 PM Matthew Benedict de Detrich
> > > > <ma...@aiven.io.invalid> wrote:
> > > > >
> > > > > So the problem is not new files, new files will always have a new
> > > Apache
> > > > > header (that is certain). What I am talking about is modifying
> > current
> > > > > files, for example I have an upcoming PR which changes the package
> > name
> > > > > from akka to org.apache.pekko. This PR will likely touch every
> single
> > > > .java
> > > > > and .scala source file and while in some cases the change is
> trivial
> > > > (i.e.
> > > > > literally the `package akka` to `package org.apache.pekko`), other
> > > > changes
> > > > > are not trivial at all. For example parts of the build file need to
> > be
> > > > > changed so that generated source files from protobuff go to the
> right
> > > > > package and even certain source files have to also be changed
> because
> > > > > return types with the FQN (fully qualified name) which includes the
> > > > package
> > > > > name as well. There are also cases like this
> > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > > > .
> > > > >
> > > > > In summary I am starting to notice that as time goes on, even to
> get
> > to
> > > > the
> > > > > full release we will have to modify current files. Also when
> > discussing
> > > > > this with Claude, I proposed another solution which is "can we just
> > > make
> > > > it
> > > > > so that any change aside from just scalafmt is a major change"
> which
> > > > would
> > > > > mean that whenever a currently existing source file is changed in
> any
> > > way
> > > > > then we just add the Apache Header onto the existing Lightbend
> > > copyright
> > > > > one but I am not sure if that will fly. Legal seems to imply that
> we
> > > need
> > > > > to distinguish between minor and major.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Nov 17, 2022 at 1:46 PM PJ Fanning <fa...@apache.org>
> > > wrote:
> > > > >
> > > > > > I was going to suggest something similar - that if we can add new
> > > code
> > > > > > in new class files - that this simplifies the discussion.
> > > > > >
> > > > > > Obviously, this can't always be the answer because if used the
> > wrong
> > > > > > way it messes up the public API. The Lightbend headered file
> could
> > > > > > call the new code in the Apache headered file.
> > > > > >
> > > > > > In some cases, we may still need to make all the changes in the
> > > > > > original Lightbend headered file. And in that case, we could add
> > the
> > > > > > Apache header after the Lightbend header.
> > > > > >
> > > > > > On Thu, 17 Nov 2022 at 13:38, He Pin <he...@apache.org> wrote:
> > > > > > >
> > > > > > > Can we just add new apache header to newly created files,
> that's
> > a
> > > > much
> > > > > > simpler rule to follow?
> > > > > > > And what about the akka/stream/impl/fusing/Ops.scala which
> > > contains a
> > > > > > lots of akka stream operators? Would It be better that adding new
> > > > operators
> > > > > > to a dedicated files?
> > > > > > >
> > > > > > >
> > > > > > > On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote:
> > > > > > > > Yeah the issue is more about having to repeat this discussion
> > on
> > > > every
> > > > > > > > single PR due to having to agree upon what is a minor or a
> > major
> > > > > > change,
> > > > > > > > not about this one specifically. Another thing to keep in
> mind
> > is
> > > > that
> > > > > > > > evidently people also have different opinions on what is a
> > minor
> > > > > > change and
> > > > > > > > what is a major. This itself is completely fine and normal,
> the
> > > > > > problem is
> > > > > > > > that depending on who is reviewing a certain PR we can get
> > > > > > > > different results of what is minor vs major and since we are
> > > > dealing
> > > > > > with
> > > > > > > > legal issues here this is not exactly desirable.
> > > > > > > >
> > > > > > > > This is why I am personally leaning much towards the "lets
> > > > delegate all
> > > > > > > > these header decisions due to minor vs major change at once
> > just
> > > > before
> > > > > > > > release". With such a strategy it's easier to get everyone's
> > > > opinion
> > > > > > from
> > > > > > > > the PMCC on the matter, collectively come to some conclusion
> > and
> > > > then
> > > > > > as a
> > > > > > > > result of that conclusion we can create more clear rules
> going
> > > > forward.
> > > > > > > >
> > > > > > > > On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <
> > > fanningpj@apache.org>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > In https://github.com/apache/incubator-pekko/pull/50 - I'd
> > > > prefer
> > > > > > to add
> > > > > > > > > the ASF header to the CopyrightHeader.scala file - after
> the
> > > > existing
> > > > > > > > > Lightbend header.
> > > > > > > > >
> > > > > > > > > I think the change is non-trivial.
> > > > > > > > >
> > > > > > > > > I think this policy would allow us to make some progress.
> At
> > > the
> > > > > > moment,
> > > > > > > > > the header issue is really jamming up the works.
> > > > > > > > >
> > > > > > > > > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> > > > > > > > > > Currently there appears to be confusion and/or
> disagreement
> > > > > > regarding
> > > > > > > > > what
> > > > > > > > > > constitutes a minor vs major change. For context please
> > have
> > > a
> > > > > > look at
> > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > > > > > > > > .
> > > > > > > > > >
> > > > > > > > > > The main problem I foresee (which arguably in my opinion
> > has
> > > > > > already
> > > > > > > > > > started) is that due to the definition of minor vs major
> > > being
> > > > > > quite
> > > > > > > > > > subjective, it's already started holding up the progress
> of
> > > > doing
> > > > > > work on
> > > > > > > > > > Pekko. This has already started with the PR at
> > > > > > > > > > https://github.com/apache/incubator-pekko/pull/50 and
> also
> > > at
> > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > >
> > >
> >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > > > > > > > .
> > > > > > > > > > In short, if we are going to debate on every single PR
> what
> > > > > > constitutes a
> > > > > > > > > > minor or major change it's going to significantly
> decrease
> > > the
> > > > > > velocity
> > > > > > > > > of
> > > > > > > > > > getting stuff done.
> > > > > > > > > >
> > > > > > > > > > Would it be possible for us to come to a more
> > > technical/strict
> > > > > > definition
> > > > > > > > > > on what constitutes a minor or major change? The current
> > > > > > disagreement
> > > > > > > > > from
> > > > > > > > > > the previously mentioned PR's is about whether a change
> to
> > > the
> > > > > > build
> > > > > > > > > (which
> > > > > > > > > > has no effect on the execution/use of the software) is
> > major
> > > > but
> > > > > > there
> > > > > > > > > will
> > > > > > > > > > undoubtedly be many more cases in the future (i.e. does
> the
> > > > package
> > > > > > > > > rename
> > > > > > > > > > from akka to org.apache.pekko also count as a major
> change?
> > > > This
> > > > > > one is a
> > > > > > > > > > lot less clear).
> > > > > > > > > >
> > > > > > > > > > Alternatively is it also possible for us to suspend the
> > > > changing of
> > > > > > > > > source
> > > > > > > > > > headers depending on minor/major changes just before we
> > > decide
> > > > to
> > > > > > make a
> > > > > > > > > > release? This way we can completely eliminate overhead as
> > we
> > > > work
> > > > > > > > > towards a
> > > > > > > > > > release and then when a release is ready someone can
> > create a
> > > > PR
> > > > > > with the
> > > > > > > > > > necessary header changes and in that PR itself we can
> > discuss
> > > > what
> > > > > > is
> > > > > > > > > minor
> > > > > > > > > > and what is major. This can then be tackled at once with
> > > > increased
> > > > > > focus
> > > > > > > > > > and efficiency rather than having to do this work on
> every
> > PR
> > > > which
> > > > > > > > > incurs
> > > > > > > > > > a lot of overhead. This is especially appealing if the
> > > > decision of
> > > > > > minor
> > > > > > > > > vs
> > > > > > > > > > major is going to remain largely subjective.
> > > > > > > > > >
> > > > > > > > > > Thoughts?
> > > > > > > > > > --
> > > > > > > > > >
> > > > > > > > > > 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:* matthew.dedetrich@aiven.io
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > 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:* matthew.dedetrich@aiven.io
> > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > >
> > > > > 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:* matthew.dedetrich@aiven.io
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> >
> > 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:* matthew.dedetrich@aiven.io
> >
>


-- 

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:* matthew.dedetrich@aiven.io

Re: Clarity about minor vs major change wrt source headers.

["Claude Warren, Jr" <cl...@aiven.io.INVALID>]

Maybe I don't understand the problem.

The code that He Pin submitted changes the headers as expected.  There is
no issue.

The only question is whether changes are significant enough to
warrant adding a license header.

In most cases we know that is not the case for now.

So reviews should be straightforward review of technical issues.  But
reviewers should consider whether or not there is enough change to
warrant the license.  The question is virtually the same as asking if a new
copyright should be added?  Is there a significant change to the IP.  For
most of the code from Akka that will be no.  My reasoning here is that at
most we are making minor changes to a) fit the new naming or b) fix a bug.
For all most code the Apache license should be present and no copyright
should be present.  For new code with copyright (a rare thing) there is
guidance from legal.

Claude


On Thu, Nov 17, 2022 at 3:36 PM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:

> > For the moment the Incubator PMC is the arbiter as all releases are under
> the auspices of the incubator.
>
> > When Pekko graduates, the Pekko PMC will be the arbiter.  And the Pekko
> PMC
> Chair will be responsible to Legal for IP issues.
>
> > I hope this clarifies my stance and helps to clarify the situation.
> Claude
>
> If this is the case can we just delegate the decision about whether (or
> not) to change a header until Pekko graduates to a TLP via a single large
> PR? I understand the reasoning you provide but currently due to sheer
> number of PR's as well as volume files being changed it's adding way too
> much overhead/bureaucracy and if we have to do this it's far more
> efficient to do it all at once right before the time where it's needed.
>
> Johannes also provided a fair point which is that what's being done with
> Pekko (i.e. a hard fork from a project that used to be under the control of
> a single entity) also appears to be a first in Apache, so we should
> probably approach this in a more practical manner. It appears that such
> rules were in place to deal with vendor copyrighted code that had
> possibility of being gradually included into Apache projects but in our
> case absolutely every file has a copyright.
>
> On Thu, Nov 17, 2022 at 4:10 PM Claude Warren, Jr
> <cl...@aiven.io.invalid> wrote:
>
> > In my opinion:
> >
> > Major changes are changes to the result of executing (or using) the file
> in
> > question.  For the moment I am going to stick to code files as I think
> the
> > distinction is clearer for developers.
> >
> >    - If the change changes the process of the execution it is generally a
> >    major change.  For example a class called "Sort" could implement a
> > bubble
> >    sort.  Changing that to a quick sort does not change the interface
> (the
> >    result of the call is the same) but it does change the implementation.
> > The
> >    IP of the implementation has significantly changed.  If most of the
> >    execution lines (non blank, non comment) changes then it is a major
> >    change.  There are lots of edge cases here, but the point is we should
> > be
> >    measuring the change in functionality of the execution of the file.
> >
> >
> >    - This applies to Pekko code (obviously)
> >       - This applies to Pekko build system code (not so obviously)
> >
> > The reason this is so murky is because we are playing around the edges of
> > intellectual property law and no lawyer worth his/her salt will tell you
> > this applies or this does not apply unless there is some case law around
> > it.
> >
> > So now, where are we with the issue of headers.
> >
> > In general for most of the next few months, changes are minor (renaming
> > things).  There are exceptions and one is  project/CopyrightHeader.scala
> > <
> >
> https://github.com/apache/incubator-pekko/pull/50/files#diff-068e87d37c866101b33e15bb754968e8e77fd43f90f2d3ad50344742b9604113
> > >
> > Originally this code updated the date in the copyright statement in each
> of
> > the files.  If the statement did not exist it inserted it.
> > The change inserts the Apache licence into the file if
> >
> >    - There is not a copyright statement.
> >    - There is not an Apache license header.
> >
> >
> > This is a change in the functionality of project/CopyrightHeader.scala
> > <
> >
> https://github.com/apache/incubator-pekko/pull/50/files#diff-068e87d37c866101b33e15bb754968e8e77fd43f90f2d3ad50344742b9604113
> > >
> > so the Apache license should be added.
> >
> > How much work does this entail?
> > =========================
> >
> > All requests will be reviewed by committers.  If a committer thinks that
> it
> > rises to the level of a change then the submitter should add the headers
> to
> > the identified files.
> > If there is a disagreement that it rises to that level we can have a
> > discussion here or the committer can decide that it doesn't need to be
> > changed.
> >
> > If new source is contributed and it has copyright marks in it we should
> ask
> > the submitter to remove the copyrights (if he/she owns them) or get a
> > software-grant from the owners of the copyright.  This is all part of the
> > normal code review process.  Most of the time it does not come up as the
> > contribution is a simple file or couple of files and the author includes
> > the Apache headers in them from the start.  However, if there is a large
> > contribution the contributor should fill out an ICLA, as all committers
> > have done.
> >
> > So, yes there is work.  No, in general, it is not a lot of work.  But,
> > committers have made an implied agreement to ensure that code is licensed
> > under the Apache license.
> >
> > Who is the final arbiter?
> > ==================
> >
> > For the moment the Incubator PMC is the arbiter as all releases are under
> > the auspices of the incubator.
> >
> > When Pekko graduates, the Pekko PMC will be the arbiter.  And the Pekko
> PMC
> > Chair will be responsible to Legal for IP issues.
> >
> > I hope this clarifies my stance and helps to clarify the situation.
> > Claude
> >
> > On Thu, Nov 17, 2022 at 2:32 PM Johannes Rudolph <
> > johannes.rudolph@gmail.com>
> > wrote:
> >
> > > I think the only way forward is to make a change right now to all of
> > > the existing files, everything else will not work because it cannot be
> > > automated.
> > >
> > > Where does this distinction between minor vs major changes come from?
> > > It doesn't seem to come from the ASL.
> > >
> > > AFAICS, ASL says
> > >
> > >  b. You must cause any modified files to carry prominent notices
> > > stating that You changed the files; and
> > >
> > > This does not say, in particular, in which way you are allowed to
> > > change files that contain no or minor changes. The main reason that I
> > > could think of is making a misleading statement about who or what owns
> > > the original copyright.
> > >
> > > IMO we should add a notice to all files right now that says:
> > >
> > > "This software is based on Akka (...). This file/repository was
> > > imported from version [github url including hash]. All changes to this
> > > file are licensed under ASL as shown below. Original license follows."
> > >
> > > How could such a message be misinterpreted to be a (mis)appropriation
> > > of the original code?
> > >
> > > Also, consider that a file header will never tell the full story (and
> > > seriously no one expects this). The most comprehensive story will be
> > > told through the actual commits (and the Github PR history), and to
> > > figure out who contributed which change or whether it was from the
> > > original fork can only be figured out by looking through the git
> > > history (and if the only thing added was the above comment, then
> > > that's it, nothing misleading there).
> > >
> > > In
> > >
> >
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > > ,
> > > Claude mentioned some rules which seem to come from
> > > https://www.apache.org/legal/src-headers.html:
> > >
> > > > TREATMENT OF THIRD-PARTY WORKS
> > > >[...]
> > > > 3. Do not add the standard Apache License header to the top of
> > > third-party source files.
> > >
> > > I can see where that comes from, which is that vendored source code
> > > should not get any gratuitous licenses (especially, if there's no
> > > intention to ever change those files).
> > >
> > > > 4. Minor modifications/additions to third-party source files should
> > > typically be licensed under the same terms as the rest of the
> third-party
> > > source for convenience.
> > > > 5. The project's PMC should deal with major modifications/additions
> to
> > > third-party source files on a case-by-case basis.
> > >
> > > 4. + 5. seem to introduce the distinction between minor and major
> > > changes. 4. is a "should" rule and also "for convenience", so maybe we
> > > can just ignore that for now. 5. is probably the cause for this
> > > discussion.
> > >
> > > In any case, for a fork the basic assumptions are quite different than
> > > for other projects and, in fact, there will be changes for most files.
> > > Having to decide license headers on a case-by-case basis will not work
> > > for Pekko. It will not work now, because there will be no (I)PMCs that
> > > will review the first release for 10ks of changes to figure out
> > > whether on a case-by-case basis the license was applied directly and
> > > it will not work in the future because it will make each single change
> > > an unworkable act of bureaucracy.
> > >
> > > So, we need come up with a workable alternative now.
> > >
> > > On Thu, Nov 17, 2022 at 2:08 PM Matthew Benedict de Detrich
> > > <ma...@aiven.io.invalid> wrote:
> > > >
> > > > So the problem is not new files, new files will always have a new
> > Apache
> > > > header (that is certain). What I am talking about is modifying
> current
> > > > files, for example I have an upcoming PR which changes the package
> name
> > > > from akka to org.apache.pekko. This PR will likely touch every single
> > > .java
> > > > and .scala source file and while in some cases the change is trivial
> > > (i.e.
> > > > literally the `package akka` to `package org.apache.pekko`), other
> > > changes
> > > > are not trivial at all. For example parts of the build file need to
> be
> > > > changed so that generated source files from protobuff go to the right
> > > > package and even certain source files have to also be changed because
> > > > return types with the FQN (fully qualified name) which includes the
> > > package
> > > > name as well. There are also cases like this
> > > >
> > >
> >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > > .
> > > >
> > > > In summary I am starting to notice that as time goes on, even to get
> to
> > > the
> > > > full release we will have to modify current files. Also when
> discussing
> > > > this with Claude, I proposed another solution which is "can we just
> > make
> > > it
> > > > so that any change aside from just scalafmt is a major change" which
> > > would
> > > > mean that whenever a currently existing source file is changed in any
> > way
> > > > then we just add the Apache Header onto the existing Lightbend
> > copyright
> > > > one but I am not sure if that will fly. Legal seems to imply that we
> > need
> > > > to distinguish between minor and major.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Nov 17, 2022 at 1:46 PM PJ Fanning <fa...@apache.org>
> > wrote:
> > > >
> > > > > I was going to suggest something similar - that if we can add new
> > code
> > > > > in new class files - that this simplifies the discussion.
> > > > >
> > > > > Obviously, this can't always be the answer because if used the
> wrong
> > > > > way it messes up the public API. The Lightbend headered file could
> > > > > call the new code in the Apache headered file.
> > > > >
> > > > > In some cases, we may still need to make all the changes in the
> > > > > original Lightbend headered file. And in that case, we could add
> the
> > > > > Apache header after the Lightbend header.
> > > > >
> > > > > On Thu, 17 Nov 2022 at 13:38, He Pin <he...@apache.org> wrote:
> > > > > >
> > > > > > Can we just add new apache header to newly created files, that's
> a
> > > much
> > > > > simpler rule to follow?
> > > > > > And what about the akka/stream/impl/fusing/Ops.scala which
> > contains a
> > > > > lots of akka stream operators? Would It be better that adding new
> > > operators
> > > > > to a dedicated files?
> > > > > >
> > > > > >
> > > > > > On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote:
> > > > > > > Yeah the issue is more about having to repeat this discussion
> on
> > > every
> > > > > > > single PR due to having to agree upon what is a minor or a
> major
> > > > > change,
> > > > > > > not about this one specifically. Another thing to keep in mind
> is
> > > that
> > > > > > > evidently people also have different opinions on what is a
> minor
> > > > > change and
> > > > > > > what is a major. This itself is completely fine and normal, the
> > > > > problem is
> > > > > > > that depending on who is reviewing a certain PR we can get
> > > > > > > different results of what is minor vs major and since we are
> > > dealing
> > > > > with
> > > > > > > legal issues here this is not exactly desirable.
> > > > > > >
> > > > > > > This is why I am personally leaning much towards the "lets
> > > delegate all
> > > > > > > these header decisions due to minor vs major change at once
> just
> > > before
> > > > > > > release". With such a strategy it's easier to get everyone's
> > > opinion
> > > > > from
> > > > > > > the PMCC on the matter, collectively come to some conclusion
> and
> > > then
> > > > > as a
> > > > > > > result of that conclusion we can create more clear rules going
> > > forward.
> > > > > > >
> > > > > > > On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <
> > fanningpj@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > > In https://github.com/apache/incubator-pekko/pull/50 - I'd
> > > prefer
> > > > > to add
> > > > > > > > the ASF header to the CopyrightHeader.scala file - after the
> > > existing
> > > > > > > > Lightbend header.
> > > > > > > >
> > > > > > > > I think the change is non-trivial.
> > > > > > > >
> > > > > > > > I think this policy would allow us to make some progress. At
> > the
> > > > > moment,
> > > > > > > > the header issue is really jamming up the works.
> > > > > > > >
> > > > > > > > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> > > > > > > > > Currently there appears to be confusion and/or disagreement
> > > > > regarding
> > > > > > > > what
> > > > > > > > > constitutes a minor vs major change. For context please
> have
> > a
> > > > > look at
> > > > > > > > >
> > > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > > > > > > > .
> > > > > > > > >
> > > > > > > > > The main problem I foresee (which arguably in my opinion
> has
> > > > > already
> > > > > > > > > started) is that due to the definition of minor vs major
> > being
> > > > > quite
> > > > > > > > > subjective, it's already started holding up the progress of
> > > doing
> > > > > work on
> > > > > > > > > Pekko. This has already started with the PR at
> > > > > > > > > https://github.com/apache/incubator-pekko/pull/50 and also
> > at
> > > > > > > > >
> > > > > > > >
> > > > >
> > >
> >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > > > > > > .
> > > > > > > > > In short, if we are going to debate on every single PR what
> > > > > constitutes a
> > > > > > > > > minor or major change it's going to significantly decrease
> > the
> > > > > velocity
> > > > > > > > of
> > > > > > > > > getting stuff done.
> > > > > > > > >
> > > > > > > > > Would it be possible for us to come to a more
> > technical/strict
> > > > > definition
> > > > > > > > > on what constitutes a minor or major change? The current
> > > > > disagreement
> > > > > > > > from
> > > > > > > > > the previously mentioned PR's is about whether a change to
> > the
> > > > > build
> > > > > > > > (which
> > > > > > > > > has no effect on the execution/use of the software) is
> major
> > > but
> > > > > there
> > > > > > > > will
> > > > > > > > > undoubtedly be many more cases in the future (i.e. does the
> > > package
> > > > > > > > rename
> > > > > > > > > from akka to org.apache.pekko also count as a major change?
> > > This
> > > > > one is a
> > > > > > > > > lot less clear).
> > > > > > > > >
> > > > > > > > > Alternatively is it also possible for us to suspend the
> > > changing of
> > > > > > > > source
> > > > > > > > > headers depending on minor/major changes just before we
> > decide
> > > to
> > > > > make a
> > > > > > > > > release? This way we can completely eliminate overhead as
> we
> > > work
> > > > > > > > towards a
> > > > > > > > > release and then when a release is ready someone can
> create a
> > > PR
> > > > > with the
> > > > > > > > > necessary header changes and in that PR itself we can
> discuss
> > > what
> > > > > is
> > > > > > > > minor
> > > > > > > > > and what is major. This can then be tackled at once with
> > > increased
> > > > > focus
> > > > > > > > > and efficiency rather than having to do this work on every
> PR
> > > which
> > > > > > > > incurs
> > > > > > > > > a lot of overhead. This is especially appealing if the
> > > decision of
> > > > > minor
> > > > > > > > vs
> > > > > > > > > major is going to remain largely subjective.
> > > > > > > > >
> > > > > > > > > Thoughts?
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > 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:* matthew.dedetrich@aiven.io
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > 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:* matthew.dedetrich@aiven.io
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > > 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:* matthew.dedetrich@aiven.io
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
>
>
> --
>
> 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:* matthew.dedetrich@aiven.io
>

Re: Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

> For the moment the Incubator PMC is the arbiter as all releases are under
the auspices of the incubator.

> When Pekko graduates, the Pekko PMC will be the arbiter.  And the Pekko
PMC
Chair will be responsible to Legal for IP issues.

> I hope this clarifies my stance and helps to clarify the situation.
Claude

If this is the case can we just delegate the decision about whether (or
not) to change a header until Pekko graduates to a TLP via a single large
PR? I understand the reasoning you provide but currently due to sheer
number of PR's as well as volume files being changed it's adding way too
much overhead/bureaucracy and if we have to do this it's far more
efficient to do it all at once right before the time where it's needed.

Johannes also provided a fair point which is that what's being done with
Pekko (i.e. a hard fork from a project that used to be under the control of
a single entity) also appears to be a first in Apache, so we should
probably approach this in a more practical manner. It appears that such
rules were in place to deal with vendor copyrighted code that had
possibility of being gradually included into Apache projects but in our
case absolutely every file has a copyright.

On Thu, Nov 17, 2022 at 4:10 PM Claude Warren, Jr
<cl...@aiven.io.invalid> wrote:

> In my opinion:
>
> Major changes are changes to the result of executing (or using) the file in
> question.  For the moment I am going to stick to code files as I think the
> distinction is clearer for developers.
>
>    - If the change changes the process of the execution it is generally a
>    major change.  For example a class called "Sort" could implement a
> bubble
>    sort.  Changing that to a quick sort does not change the interface (the
>    result of the call is the same) but it does change the implementation.
> The
>    IP of the implementation has significantly changed.  If most of the
>    execution lines (non blank, non comment) changes then it is a major
>    change.  There are lots of edge cases here, but the point is we should
> be
>    measuring the change in functionality of the execution of the file.
>
>
>    - This applies to Pekko code (obviously)
>       - This applies to Pekko build system code (not so obviously)
>
> The reason this is so murky is because we are playing around the edges of
> intellectual property law and no lawyer worth his/her salt will tell you
> this applies or this does not apply unless there is some case law around
> it.
>
> So now, where are we with the issue of headers.
>
> In general for most of the next few months, changes are minor (renaming
> things).  There are exceptions and one is  project/CopyrightHeader.scala
> <
> https://github.com/apache/incubator-pekko/pull/50/files#diff-068e87d37c866101b33e15bb754968e8e77fd43f90f2d3ad50344742b9604113
> >
> Originally this code updated the date in the copyright statement in each of
> the files.  If the statement did not exist it inserted it.
> The change inserts the Apache licence into the file if
>
>    - There is not a copyright statement.
>    - There is not an Apache license header.
>
>
> This is a change in the functionality of project/CopyrightHeader.scala
> <
> https://github.com/apache/incubator-pekko/pull/50/files#diff-068e87d37c866101b33e15bb754968e8e77fd43f90f2d3ad50344742b9604113
> >
> so the Apache license should be added.
>
> How much work does this entail?
> =========================
>
> All requests will be reviewed by committers.  If a committer thinks that it
> rises to the level of a change then the submitter should add the headers to
> the identified files.
> If there is a disagreement that it rises to that level we can have a
> discussion here or the committer can decide that it doesn't need to be
> changed.
>
> If new source is contributed and it has copyright marks in it we should ask
> the submitter to remove the copyrights (if he/she owns them) or get a
> software-grant from the owners of the copyright.  This is all part of the
> normal code review process.  Most of the time it does not come up as the
> contribution is a simple file or couple of files and the author includes
> the Apache headers in them from the start.  However, if there is a large
> contribution the contributor should fill out an ICLA, as all committers
> have done.
>
> So, yes there is work.  No, in general, it is not a lot of work.  But,
> committers have made an implied agreement to ensure that code is licensed
> under the Apache license.
>
> Who is the final arbiter?
> ==================
>
> For the moment the Incubator PMC is the arbiter as all releases are under
> the auspices of the incubator.
>
> When Pekko graduates, the Pekko PMC will be the arbiter.  And the Pekko PMC
> Chair will be responsible to Legal for IP issues.
>
> I hope this clarifies my stance and helps to clarify the situation.
> Claude
>
> On Thu, Nov 17, 2022 at 2:32 PM Johannes Rudolph <
> johannes.rudolph@gmail.com>
> wrote:
>
> > I think the only way forward is to make a change right now to all of
> > the existing files, everything else will not work because it cannot be
> > automated.
> >
> > Where does this distinction between minor vs major changes come from?
> > It doesn't seem to come from the ASL.
> >
> > AFAICS, ASL says
> >
> >  b. You must cause any modified files to carry prominent notices
> > stating that You changed the files; and
> >
> > This does not say, in particular, in which way you are allowed to
> > change files that contain no or minor changes. The main reason that I
> > could think of is making a misleading statement about who or what owns
> > the original copyright.
> >
> > IMO we should add a notice to all files right now that says:
> >
> > "This software is based on Akka (...). This file/repository was
> > imported from version [github url including hash]. All changes to this
> > file are licensed under ASL as shown below. Original license follows."
> >
> > How could such a message be misinterpreted to be a (mis)appropriation
> > of the original code?
> >
> > Also, consider that a file header will never tell the full story (and
> > seriously no one expects this). The most comprehensive story will be
> > told through the actual commits (and the Github PR history), and to
> > figure out who contributed which change or whether it was from the
> > original fork can only be figured out by looking through the git
> > history (and if the only thing added was the above comment, then
> > that's it, nothing misleading there).
> >
> > In
> >
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > ,
> > Claude mentioned some rules which seem to come from
> > https://www.apache.org/legal/src-headers.html:
> >
> > > TREATMENT OF THIRD-PARTY WORKS
> > >[...]
> > > 3. Do not add the standard Apache License header to the top of
> > third-party source files.
> >
> > I can see where that comes from, which is that vendored source code
> > should not get any gratuitous licenses (especially, if there's no
> > intention to ever change those files).
> >
> > > 4. Minor modifications/additions to third-party source files should
> > typically be licensed under the same terms as the rest of the third-party
> > source for convenience.
> > > 5. The project's PMC should deal with major modifications/additions to
> > third-party source files on a case-by-case basis.
> >
> > 4. + 5. seem to introduce the distinction between minor and major
> > changes. 4. is a "should" rule and also "for convenience", so maybe we
> > can just ignore that for now. 5. is probably the cause for this
> > discussion.
> >
> > In any case, for a fork the basic assumptions are quite different than
> > for other projects and, in fact, there will be changes for most files.
> > Having to decide license headers on a case-by-case basis will not work
> > for Pekko. It will not work now, because there will be no (I)PMCs that
> > will review the first release for 10ks of changes to figure out
> > whether on a case-by-case basis the license was applied directly and
> > it will not work in the future because it will make each single change
> > an unworkable act of bureaucracy.
> >
> > So, we need come up with a workable alternative now.
> >
> > On Thu, Nov 17, 2022 at 2:08 PM Matthew Benedict de Detrich
> > <ma...@aiven.io.invalid> wrote:
> > >
> > > So the problem is not new files, new files will always have a new
> Apache
> > > header (that is certain). What I am talking about is modifying current
> > > files, for example I have an upcoming PR which changes the package name
> > > from akka to org.apache.pekko. This PR will likely touch every single
> > .java
> > > and .scala source file and while in some cases the change is trivial
> > (i.e.
> > > literally the `package akka` to `package org.apache.pekko`), other
> > changes
> > > are not trivial at all. For example parts of the build file need to be
> > > changed so that generated source files from protobuff go to the right
> > > package and even certain source files have to also be changed because
> > > return types with the FQN (fully qualified name) which includes the
> > package
> > > name as well. There are also cases like this
> > >
> >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > .
> > >
> > > In summary I am starting to notice that as time goes on, even to get to
> > the
> > > full release we will have to modify current files. Also when discussing
> > > this with Claude, I proposed another solution which is "can we just
> make
> > it
> > > so that any change aside from just scalafmt is a major change" which
> > would
> > > mean that whenever a currently existing source file is changed in any
> way
> > > then we just add the Apache Header onto the existing Lightbend
> copyright
> > > one but I am not sure if that will fly. Legal seems to imply that we
> need
> > > to distinguish between minor and major.
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Nov 17, 2022 at 1:46 PM PJ Fanning <fa...@apache.org>
> wrote:
> > >
> > > > I was going to suggest something similar - that if we can add new
> code
> > > > in new class files - that this simplifies the discussion.
> > > >
> > > > Obviously, this can't always be the answer because if used the wrong
> > > > way it messes up the public API. The Lightbend headered file could
> > > > call the new code in the Apache headered file.
> > > >
> > > > In some cases, we may still need to make all the changes in the
> > > > original Lightbend headered file. And in that case, we could add the
> > > > Apache header after the Lightbend header.
> > > >
> > > > On Thu, 17 Nov 2022 at 13:38, He Pin <he...@apache.org> wrote:
> > > > >
> > > > > Can we just add new apache header to newly created files, that's a
> > much
> > > > simpler rule to follow?
> > > > > And what about the akka/stream/impl/fusing/Ops.scala which
> contains a
> > > > lots of akka stream operators? Would It be better that adding new
> > operators
> > > > to a dedicated files?
> > > > >
> > > > >
> > > > > On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote:
> > > > > > Yeah the issue is more about having to repeat this discussion on
> > every
> > > > > > single PR due to having to agree upon what is a minor or a major
> > > > change,
> > > > > > not about this one specifically. Another thing to keep in mind is
> > that
> > > > > > evidently people also have different opinions on what is a minor
> > > > change and
> > > > > > what is a major. This itself is completely fine and normal, the
> > > > problem is
> > > > > > that depending on who is reviewing a certain PR we can get
> > > > > > different results of what is minor vs major and since we are
> > dealing
> > > > with
> > > > > > legal issues here this is not exactly desirable.
> > > > > >
> > > > > > This is why I am personally leaning much towards the "lets
> > delegate all
> > > > > > these header decisions due to minor vs major change at once just
> > before
> > > > > > release". With such a strategy it's easier to get everyone's
> > opinion
> > > > from
> > > > > > the PMCC on the matter, collectively come to some conclusion and
> > then
> > > > as a
> > > > > > result of that conclusion we can create more clear rules going
> > forward.
> > > > > >
> > > > > > On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <
> fanningpj@apache.org>
> > > > wrote:
> > > > > >
> > > > > > > In https://github.com/apache/incubator-pekko/pull/50 - I'd
> > prefer
> > > > to add
> > > > > > > the ASF header to the CopyrightHeader.scala file - after the
> > existing
> > > > > > > Lightbend header.
> > > > > > >
> > > > > > > I think the change is non-trivial.
> > > > > > >
> > > > > > > I think this policy would allow us to make some progress. At
> the
> > > > moment,
> > > > > > > the header issue is really jamming up the works.
> > > > > > >
> > > > > > > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> > > > > > > > Currently there appears to be confusion and/or disagreement
> > > > regarding
> > > > > > > what
> > > > > > > > constitutes a minor vs major change. For context please have
> a
> > > > look at
> > > > > > > >
> > > > > > >
> > > >
> >
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > > > > > > .
> > > > > > > >
> > > > > > > > The main problem I foresee (which arguably in my opinion has
> > > > already
> > > > > > > > started) is that due to the definition of minor vs major
> being
> > > > quite
> > > > > > > > subjective, it's already started holding up the progress of
> > doing
> > > > work on
> > > > > > > > Pekko. This has already started with the PR at
> > > > > > > > https://github.com/apache/incubator-pekko/pull/50 and also
> at
> > > > > > > >
> > > > > > >
> > > >
> >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > > > > > .
> > > > > > > > In short, if we are going to debate on every single PR what
> > > > constitutes a
> > > > > > > > minor or major change it's going to significantly decrease
> the
> > > > velocity
> > > > > > > of
> > > > > > > > getting stuff done.
> > > > > > > >
> > > > > > > > Would it be possible for us to come to a more
> technical/strict
> > > > definition
> > > > > > > > on what constitutes a minor or major change? The current
> > > > disagreement
> > > > > > > from
> > > > > > > > the previously mentioned PR's is about whether a change to
> the
> > > > build
> > > > > > > (which
> > > > > > > > has no effect on the execution/use of the software) is major
> > but
> > > > there
> > > > > > > will
> > > > > > > > undoubtedly be many more cases in the future (i.e. does the
> > package
> > > > > > > rename
> > > > > > > > from akka to org.apache.pekko also count as a major change?
> > This
> > > > one is a
> > > > > > > > lot less clear).
> > > > > > > >
> > > > > > > > Alternatively is it also possible for us to suspend the
> > changing of
> > > > > > > source
> > > > > > > > headers depending on minor/major changes just before we
> decide
> > to
> > > > make a
> > > > > > > > release? This way we can completely eliminate overhead as we
> > work
> > > > > > > towards a
> > > > > > > > release and then when a release is ready someone can create a
> > PR
> > > > with the
> > > > > > > > necessary header changes and in that PR itself we can discuss
> > what
> > > > is
> > > > > > > minor
> > > > > > > > and what is major. This can then be tackled at once with
> > increased
> > > > focus
> > > > > > > > and efficiency rather than having to do this work on every PR
> > which
> > > > > > > incurs
> > > > > > > > a lot of overhead. This is especially appealing if the
> > decision of
> > > > minor
> > > > > > > vs
> > > > > > > > major is going to remain largely subjective.
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > > --
> > > > > > > >
> > > > > > > > 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:* matthew.dedetrich@aiven.io
> > > > > > > >
> > > > > > >
> > > > > > >
> > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > 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:* matthew.dedetrich@aiven.io
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >
> > > >
> > >
> > > --
> > >
> > > 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:* matthew.dedetrich@aiven.io
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>


-- 

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:* matthew.dedetrich@aiven.io

Re: Clarity about minor vs major change wrt source headers.

["Claude Warren, Jr" <cl...@aiven.io.INVALID>]

Matthew is correct, the release is the source code.  Everything else is
considered a user convenience.

And yes, for large scale projects being a PCM member is a lot of work.  And
yes there is a level of trust between the PCM and the committers.  And part
of the Incubation process is to ensure that that trust exists, and to get
processes embedded in the culture of the project.

For a release the questions are:

   1. Does the code have the right licensing
   2. Are there additional licenses that are required to be included?
   3. Can the product be built from the source?
   4. Are the jars and additional convenience items properly signed?
   5. Do the jars and additional convenience items contain the result of
   source compilation?

If so and if the project has determined that the code is of sufficient
quality then it can be released.

And yes, as we work through Pekko we will find things that are edge and
corner cases for the standard Apache release process.  We, as a team, will
determine how that should work and the Incubator will help us make sure
that what we decide meets the requirements of Apache.

Once ouf of the incubator, all of the process will be second nature.

We are currently in the hard part -- understanding the Apache requirements
and how to apply them to what was the Akka development model to achieve an
Apache Pekko development model.



On Thu, Nov 17, 2022 at 3:50 PM Johannes Rudolph <jo...@gmail.com>
wrote:

> On Thu, Nov 17, 2022 at 4:09 PM Claude Warren, Jr
> <cl...@aiven.io.invalid> wrote:
> > For the moment the Incubator PMC is the arbiter as all releases are under
> > the auspices of the incubator.
> >
> > When Pekko graduates, the Pekko PMC will be the arbiter.  And the Pekko
> PMC
> > Chair will be responsible to Legal for IP issues.
>
> Based on the scale of the project, this will set up the PMCs to be in
> a bad position, because they have either to trust a big list of
> committers to have carefully vetted each single change, or, they have
> to do their own due diligence and go through 10ks of changes. Who
> would want to greenlight a release under those conditions?
>
> (Incidentally, I find it somewhat questionable that releases are
> treated differently than the ongoing publication of merged work. Why
> are released binaries treated differently than source code?)
>
> Johannes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

Re: Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

> (Incidentally, I find it somewhat questionable that releases are
treated differently than the ongoing publication of merged work. Why
are released binaries treated differently than source code?)

I believe this stems from the fact that at least according to Apache, the
only thing they consider a release is the source code (which gets pushed to
an SVN repository as part of the process). Anything aside from that (i.e.
deploying jar's to sonatype/maven) is secondary and technically not part of
the Apache release.

Then again it appears that its not releases where the headers are critical
but rather incubation to a TLP which muddies it even further.

On Thu, Nov 17, 2022 at 4:50 PM Johannes Rudolph <jo...@gmail.com>
wrote:

> On Thu, Nov 17, 2022 at 4:09 PM Claude Warren, Jr
> <cl...@aiven.io.invalid> wrote:
> > For the moment the Incubator PMC is the arbiter as all releases are under
> > the auspices of the incubator.
> >
> > When Pekko graduates, the Pekko PMC will be the arbiter.  And the Pekko
> PMC
> > Chair will be responsible to Legal for IP issues.
>
> Based on the scale of the project, this will set up the PMCs to be in
> a bad position, because they have either to trust a big list of
> committers to have carefully vetted each single change, or, they have
> to do their own due diligence and go through 10ks of changes. Who
> would want to greenlight a release under those conditions?
>
> (Incidentally, I find it somewhat questionable that releases are
> treated differently than the ongoing publication of merged work. Why
> are released binaries treated differently than source code?)
>
> Johannes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

-- 

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:* matthew.dedetrich@aiven.io

Re: Clarity about minor vs major change wrt source headers.

[Johannes Rudolph <jo...@gmail.com>]

On Thu, Nov 17, 2022 at 4:09 PM Claude Warren, Jr
<cl...@aiven.io.invalid> wrote:
> For the moment the Incubator PMC is the arbiter as all releases are under
> the auspices of the incubator.
>
> When Pekko graduates, the Pekko PMC will be the arbiter.  And the Pekko PMC
> Chair will be responsible to Legal for IP issues.

Based on the scale of the project, this will set up the PMCs to be in
a bad position, because they have either to trust a big list of
committers to have carefully vetted each single change, or, they have
to do their own due diligence and go through 10ks of changes. Who
would want to greenlight a release under those conditions?

(Incidentally, I find it somewhat questionable that releases are
treated differently than the ongoing publication of merged work. Why
are released binaries treated differently than source code?)

Johannes

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Clarity about minor vs major change wrt source headers.

["Claude Warren, Jr" <cl...@aiven.io.INVALID>]

In my opinion:

Major changes are changes to the result of executing (or using) the file in
question.  For the moment I am going to stick to code files as I think the
distinction is clearer for developers.

   - If the change changes the process of the execution it is generally a
   major change.  For example a class called "Sort" could implement a bubble
   sort.  Changing that to a quick sort does not change the interface (the
   result of the call is the same) but it does change the implementation.  The
   IP of the implementation has significantly changed.  If most of the
   execution lines (non blank, non comment) changes then it is a major
   change.  There are lots of edge cases here, but the point is we should be
   measuring the change in functionality of the execution of the file.


   - This applies to Pekko code (obviously)
      - This applies to Pekko build system code (not so obviously)

The reason this is so murky is because we are playing around the edges of
intellectual property law and no lawyer worth his/her salt will tell you
this applies or this does not apply unless there is some case law around it.

So now, where are we with the issue of headers.

In general for most of the next few months, changes are minor (renaming
things).  There are exceptions and one is  project/CopyrightHeader.scala
<https://github.com/apache/incubator-pekko/pull/50/files#diff-068e87d37c866101b33e15bb754968e8e77fd43f90f2d3ad50344742b9604113>
Originally this code updated the date in the copyright statement in each of
the files.  If the statement did not exist it inserted it.
The change inserts the Apache licence into the file if

   - There is not a copyright statement.
   - There is not an Apache license header.


This is a change in the functionality of project/CopyrightHeader.scala
<https://github.com/apache/incubator-pekko/pull/50/files#diff-068e87d37c866101b33e15bb754968e8e77fd43f90f2d3ad50344742b9604113>
so the Apache license should be added.

How much work does this entail?
=========================

All requests will be reviewed by committers.  If a committer thinks that it
rises to the level of a change then the submitter should add the headers to
the identified files.
If there is a disagreement that it rises to that level we can have a
discussion here or the committer can decide that it doesn't need to be
changed.

If new source is contributed and it has copyright marks in it we should ask
the submitter to remove the copyrights (if he/she owns them) or get a
software-grant from the owners of the copyright.  This is all part of the
normal code review process.  Most of the time it does not come up as the
contribution is a simple file or couple of files and the author includes
the Apache headers in them from the start.  However, if there is a large
contribution the contributor should fill out an ICLA, as all committers
have done.

So, yes there is work.  No, in general, it is not a lot of work.  But,
committers have made an implied agreement to ensure that code is licensed
under the Apache license.

Who is the final arbiter?
==================

For the moment the Incubator PMC is the arbiter as all releases are under
the auspices of the incubator.

When Pekko graduates, the Pekko PMC will be the arbiter.  And the Pekko PMC
Chair will be responsible to Legal for IP issues.

I hope this clarifies my stance and helps to clarify the situation.
Claude

On Thu, Nov 17, 2022 at 2:32 PM Johannes Rudolph <jo...@gmail.com>
wrote:

> I think the only way forward is to make a change right now to all of
> the existing files, everything else will not work because it cannot be
> automated.
>
> Where does this distinction between minor vs major changes come from?
> It doesn't seem to come from the ASL.
>
> AFAICS, ASL says
>
>  b. You must cause any modified files to carry prominent notices
> stating that You changed the files; and
>
> This does not say, in particular, in which way you are allowed to
> change files that contain no or minor changes. The main reason that I
> could think of is making a misleading statement about who or what owns
> the original copyright.
>
> IMO we should add a notice to all files right now that says:
>
> "This software is based on Akka (...). This file/repository was
> imported from version [github url including hash]. All changes to this
> file are licensed under ASL as shown below. Original license follows."
>
> How could such a message be misinterpreted to be a (mis)appropriation
> of the original code?
>
> Also, consider that a file header will never tell the full story (and
> seriously no one expects this). The most comprehensive story will be
> told through the actual commits (and the Github PR history), and to
> figure out who contributed which change or whether it was from the
> original fork can only be figured out by looking through the git
> history (and if the only thing added was the above comment, then
> that's it, nothing misleading there).
>
> In
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> ,
> Claude mentioned some rules which seem to come from
> https://www.apache.org/legal/src-headers.html:
>
> > TREATMENT OF THIRD-PARTY WORKS
> >[...]
> > 3. Do not add the standard Apache License header to the top of
> third-party source files.
>
> I can see where that comes from, which is that vendored source code
> should not get any gratuitous licenses (especially, if there's no
> intention to ever change those files).
>
> > 4. Minor modifications/additions to third-party source files should
> typically be licensed under the same terms as the rest of the third-party
> source for convenience.
> > 5. The project's PMC should deal with major modifications/additions to
> third-party source files on a case-by-case basis.
>
> 4. + 5. seem to introduce the distinction between minor and major
> changes. 4. is a "should" rule and also "for convenience", so maybe we
> can just ignore that for now. 5. is probably the cause for this
> discussion.
>
> In any case, for a fork the basic assumptions are quite different than
> for other projects and, in fact, there will be changes for most files.
> Having to decide license headers on a case-by-case basis will not work
> for Pekko. It will not work now, because there will be no (I)PMCs that
> will review the first release for 10ks of changes to figure out
> whether on a case-by-case basis the license was applied directly and
> it will not work in the future because it will make each single change
> an unworkable act of bureaucracy.
>
> So, we need come up with a workable alternative now.
>
> On Thu, Nov 17, 2022 at 2:08 PM Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
> >
> > So the problem is not new files, new files will always have a new Apache
> > header (that is certain). What I am talking about is modifying current
> > files, for example I have an upcoming PR which changes the package name
> > from akka to org.apache.pekko. This PR will likely touch every single
> .java
> > and .scala source file and while in some cases the change is trivial
> (i.e.
> > literally the `package akka` to `package org.apache.pekko`), other
> changes
> > are not trivial at all. For example parts of the build file need to be
> > changed so that generated source files from protobuff go to the right
> > package and even certain source files have to also be changed because
> > return types with the FQN (fully qualified name) which includes the
> package
> > name as well. There are also cases like this
> >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > .
> >
> > In summary I am starting to notice that as time goes on, even to get to
> the
> > full release we will have to modify current files. Also when discussing
> > this with Claude, I proposed another solution which is "can we just make
> it
> > so that any change aside from just scalafmt is a major change" which
> would
> > mean that whenever a currently existing source file is changed in any way
> > then we just add the Apache Header onto the existing Lightbend copyright
> > one but I am not sure if that will fly. Legal seems to imply that we need
> > to distinguish between minor and major.
> >
> >
> >
> >
> >
> > On Thu, Nov 17, 2022 at 1:46 PM PJ Fanning <fa...@apache.org> wrote:
> >
> > > I was going to suggest something similar - that if we can add new code
> > > in new class files - that this simplifies the discussion.
> > >
> > > Obviously, this can't always be the answer because if used the wrong
> > > way it messes up the public API. The Lightbend headered file could
> > > call the new code in the Apache headered file.
> > >
> > > In some cases, we may still need to make all the changes in the
> > > original Lightbend headered file. And in that case, we could add the
> > > Apache header after the Lightbend header.
> > >
> > > On Thu, 17 Nov 2022 at 13:38, He Pin <he...@apache.org> wrote:
> > > >
> > > > Can we just add new apache header to newly created files, that's a
> much
> > > simpler rule to follow?
> > > > And what about the akka/stream/impl/fusing/Ops.scala which contains a
> > > lots of akka stream operators? Would It be better that adding new
> operators
> > > to a dedicated files?
> > > >
> > > >
> > > > On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote:
> > > > > Yeah the issue is more about having to repeat this discussion on
> every
> > > > > single PR due to having to agree upon what is a minor or a major
> > > change,
> > > > > not about this one specifically. Another thing to keep in mind is
> that
> > > > > evidently people also have different opinions on what is a minor
> > > change and
> > > > > what is a major. This itself is completely fine and normal, the
> > > problem is
> > > > > that depending on who is reviewing a certain PR we can get
> > > > > different results of what is minor vs major and since we are
> dealing
> > > with
> > > > > legal issues here this is not exactly desirable.
> > > > >
> > > > > This is why I am personally leaning much towards the "lets
> delegate all
> > > > > these header decisions due to minor vs major change at once just
> before
> > > > > release". With such a strategy it's easier to get everyone's
> opinion
> > > from
> > > > > the PMCC on the matter, collectively come to some conclusion and
> then
> > > as a
> > > > > result of that conclusion we can create more clear rules going
> forward.
> > > > >
> > > > > On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <fa...@apache.org>
> > > wrote:
> > > > >
> > > > > > In https://github.com/apache/incubator-pekko/pull/50 - I'd
> prefer
> > > to add
> > > > > > the ASF header to the CopyrightHeader.scala file - after the
> existing
> > > > > > Lightbend header.
> > > > > >
> > > > > > I think the change is non-trivial.
> > > > > >
> > > > > > I think this policy would allow us to make some progress. At the
> > > moment,
> > > > > > the header issue is really jamming up the works.
> > > > > >
> > > > > > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> > > > > > > Currently there appears to be confusion and/or disagreement
> > > regarding
> > > > > > what
> > > > > > > constitutes a minor vs major change. For context please have a
> > > look at
> > > > > > >
> > > > > >
> > >
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > > > > > .
> > > > > > >
> > > > > > > The main problem I foresee (which arguably in my opinion has
> > > already
> > > > > > > started) is that due to the definition of minor vs major being
> > > quite
> > > > > > > subjective, it's already started holding up the progress of
> doing
> > > work on
> > > > > > > Pekko. This has already started with the PR at
> > > > > > > https://github.com/apache/incubator-pekko/pull/50 and also at
> > > > > > >
> > > > > >
> > >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > > > > .
> > > > > > > In short, if we are going to debate on every single PR what
> > > constitutes a
> > > > > > > minor or major change it's going to significantly decrease the
> > > velocity
> > > > > > of
> > > > > > > getting stuff done.
> > > > > > >
> > > > > > > Would it be possible for us to come to a more technical/strict
> > > definition
> > > > > > > on what constitutes a minor or major change? The current
> > > disagreement
> > > > > > from
> > > > > > > the previously mentioned PR's is about whether a change to the
> > > build
> > > > > > (which
> > > > > > > has no effect on the execution/use of the software) is major
> but
> > > there
> > > > > > will
> > > > > > > undoubtedly be many more cases in the future (i.e. does the
> package
> > > > > > rename
> > > > > > > from akka to org.apache.pekko also count as a major change?
> This
> > > one is a
> > > > > > > lot less clear).
> > > > > > >
> > > > > > > Alternatively is it also possible for us to suspend the
> changing of
> > > > > > source
> > > > > > > headers depending on minor/major changes just before we decide
> to
> > > make a
> > > > > > > release? This way we can completely eliminate overhead as we
> work
> > > > > > towards a
> > > > > > > release and then when a release is ready someone can create a
> PR
> > > with the
> > > > > > > necessary header changes and in that PR itself we can discuss
> what
> > > is
> > > > > > minor
> > > > > > > and what is major. This can then be tackled at once with
> increased
> > > focus
> > > > > > > and efficiency rather than having to do this work on every PR
> which
> > > > > > incurs
> > > > > > > a lot of overhead. This is especially appealing if the
> decision of
> > > minor
> > > > > > vs
> > > > > > > major is going to remain largely subjective.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > > --
> > > > > > >
> > > > > > > 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:* matthew.dedetrich@aiven.io
> > > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > >
> > > > > 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:* matthew.dedetrich@aiven.io
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
> > --
> >
> > 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:* matthew.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

Re: Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

> 4. + 5. seem to introduce the distinction between minor and major
changes. 4. is a "should" rule and also "for convenience", so maybe we
can just ignore that for now. 5. is probably the cause for this
discussion.

Yes this is where it stems from

> In any case, for a fork the basic assumptions are quite different than
for other projects and, in fact, there will be changes for most files.
Having to decide license headers on a case-by-case basis will not work
for Pekko. It will not work now, because there will be no (I)PMCs that
will review the first release for 10ks of changes to figure out
whether on a case-by-case basis the license was applied directly and
it will not work in the future because it will make each single change
an unworkable act of bureaucracy.

> So, we need come up with a workable alternative now.

Strongly agreed, already having to deal with this bureaucracy now and
its going to worse, especially as more external contributors come onboard.

On Thu, Nov 17, 2022 at 3:32 PM Johannes Rudolph <jo...@gmail.com>
wrote:

> I think the only way forward is to make a change right now to all of
> the existing files, everything else will not work because it cannot be
> automated.
>
> Where does this distinction between minor vs major changes come from?
> It doesn't seem to come from the ASL.
>
> AFAICS, ASL says
>
>  b. You must cause any modified files to carry prominent notices
> stating that You changed the files; and
>
> This does not say, in particular, in which way you are allowed to
> change files that contain no or minor changes. The main reason that I
> could think of is making a misleading statement about who or what owns
> the original copyright.
>
> IMO we should add a notice to all files right now that says:
>
> "This software is based on Akka (...). This file/repository was
> imported from version [github url including hash]. All changes to this
> file are licensed under ASL as shown below. Original license follows."
>
> How could such a message be misinterpreted to be a (mis)appropriation
> of the original code?
>
> Also, consider that a file header will never tell the full story (and
> seriously no one expects this). The most comprehensive story will be
> told through the actual commits (and the Github PR history), and to
> figure out who contributed which change or whether it was from the
> original fork can only be figured out by looking through the git
> history (and if the only thing added was the above comment, then
> that's it, nothing misleading there).
>
> In
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> ,
> Claude mentioned some rules which seem to come from
> https://www.apache.org/legal/src-headers.html:
>
> > TREATMENT OF THIRD-PARTY WORKS
> >[...]
> > 3. Do not add the standard Apache License header to the top of
> third-party source files.
>
> I can see where that comes from, which is that vendored source code
> should not get any gratuitous licenses (especially, if there's no
> intention to ever change those files).
>
> > 4. Minor modifications/additions to third-party source files should
> typically be licensed under the same terms as the rest of the third-party
> source for convenience.
> > 5. The project's PMC should deal with major modifications/additions to
> third-party source files on a case-by-case basis.
>
> 4. + 5. seem to introduce the distinction between minor and major
> changes. 4. is a "should" rule and also "for convenience", so maybe we
> can just ignore that for now. 5. is probably the cause for this
> discussion.
>
> In any case, for a fork the basic assumptions are quite different than
> for other projects and, in fact, there will be changes for most files.
> Having to decide license headers on a case-by-case basis will not work
> for Pekko. It will not work now, because there will be no (I)PMCs that
> will review the first release for 10ks of changes to figure out
> whether on a case-by-case basis the license was applied directly and
> it will not work in the future because it will make each single change
> an unworkable act of bureaucracy.
>
> So, we need come up with a workable alternative now.
>
> On Thu, Nov 17, 2022 at 2:08 PM Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
> >
> > So the problem is not new files, new files will always have a new Apache
> > header (that is certain). What I am talking about is modifying current
> > files, for example I have an upcoming PR which changes the package name
> > from akka to org.apache.pekko. This PR will likely touch every single
> .java
> > and .scala source file and while in some cases the change is trivial
> (i.e.
> > literally the `package akka` to `package org.apache.pekko`), other
> changes
> > are not trivial at all. For example parts of the build file need to be
> > changed so that generated source files from protobuff go to the right
> > package and even certain source files have to also be changed because
> > return types with the FQN (fully qualified name) which includes the
> package
> > name as well. There are also cases like this
> >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > .
> >
> > In summary I am starting to notice that as time goes on, even to get to
> the
> > full release we will have to modify current files. Also when discussing
> > this with Claude, I proposed another solution which is "can we just make
> it
> > so that any change aside from just scalafmt is a major change" which
> would
> > mean that whenever a currently existing source file is changed in any way
> > then we just add the Apache Header onto the existing Lightbend copyright
> > one but I am not sure if that will fly. Legal seems to imply that we need
> > to distinguish between minor and major.
> >
> >
> >
> >
> >
> > On Thu, Nov 17, 2022 at 1:46 PM PJ Fanning <fa...@apache.org> wrote:
> >
> > > I was going to suggest something similar - that if we can add new code
> > > in new class files - that this simplifies the discussion.
> > >
> > > Obviously, this can't always be the answer because if used the wrong
> > > way it messes up the public API. The Lightbend headered file could
> > > call the new code in the Apache headered file.
> > >
> > > In some cases, we may still need to make all the changes in the
> > > original Lightbend headered file. And in that case, we could add the
> > > Apache header after the Lightbend header.
> > >
> > > On Thu, 17 Nov 2022 at 13:38, He Pin <he...@apache.org> wrote:
> > > >
> > > > Can we just add new apache header to newly created files, that's a
> much
> > > simpler rule to follow?
> > > > And what about the akka/stream/impl/fusing/Ops.scala which contains a
> > > lots of akka stream operators? Would It be better that adding new
> operators
> > > to a dedicated files?
> > > >
> > > >
> > > > On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote:
> > > > > Yeah the issue is more about having to repeat this discussion on
> every
> > > > > single PR due to having to agree upon what is a minor or a major
> > > change,
> > > > > not about this one specifically. Another thing to keep in mind is
> that
> > > > > evidently people also have different opinions on what is a minor
> > > change and
> > > > > what is a major. This itself is completely fine and normal, the
> > > problem is
> > > > > that depending on who is reviewing a certain PR we can get
> > > > > different results of what is minor vs major and since we are
> dealing
> > > with
> > > > > legal issues here this is not exactly desirable.
> > > > >
> > > > > This is why I am personally leaning much towards the "lets
> delegate all
> > > > > these header decisions due to minor vs major change at once just
> before
> > > > > release". With such a strategy it's easier to get everyone's
> opinion
> > > from
> > > > > the PMCC on the matter, collectively come to some conclusion and
> then
> > > as a
> > > > > result of that conclusion we can create more clear rules going
> forward.
> > > > >
> > > > > On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <fa...@apache.org>
> > > wrote:
> > > > >
> > > > > > In https://github.com/apache/incubator-pekko/pull/50 - I'd
> prefer
> > > to add
> > > > > > the ASF header to the CopyrightHeader.scala file - after the
> existing
> > > > > > Lightbend header.
> > > > > >
> > > > > > I think the change is non-trivial.
> > > > > >
> > > > > > I think this policy would allow us to make some progress. At the
> > > moment,
> > > > > > the header issue is really jamming up the works.
> > > > > >
> > > > > > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> > > > > > > Currently there appears to be confusion and/or disagreement
> > > regarding
> > > > > > what
> > > > > > > constitutes a minor vs major change. For context please have a
> > > look at
> > > > > > >
> > > > > >
> > >
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > > > > > .
> > > > > > >
> > > > > > > The main problem I foresee (which arguably in my opinion has
> > > already
> > > > > > > started) is that due to the definition of minor vs major being
> > > quite
> > > > > > > subjective, it's already started holding up the progress of
> doing
> > > work on
> > > > > > > Pekko. This has already started with the PR at
> > > > > > > https://github.com/apache/incubator-pekko/pull/50 and also at
> > > > > > >
> > > > > >
> > >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > > > > .
> > > > > > > In short, if we are going to debate on every single PR what
> > > constitutes a
> > > > > > > minor or major change it's going to significantly decrease the
> > > velocity
> > > > > > of
> > > > > > > getting stuff done.
> > > > > > >
> > > > > > > Would it be possible for us to come to a more technical/strict
> > > definition
> > > > > > > on what constitutes a minor or major change? The current
> > > disagreement
> > > > > > from
> > > > > > > the previously mentioned PR's is about whether a change to the
> > > build
> > > > > > (which
> > > > > > > has no effect on the execution/use of the software) is major
> but
> > > there
> > > > > > will
> > > > > > > undoubtedly be many more cases in the future (i.e. does the
> package
> > > > > > rename
> > > > > > > from akka to org.apache.pekko also count as a major change?
> This
> > > one is a
> > > > > > > lot less clear).
> > > > > > >
> > > > > > > Alternatively is it also possible for us to suspend the
> changing of
> > > > > > source
> > > > > > > headers depending on minor/major changes just before we decide
> to
> > > make a
> > > > > > > release? This way we can completely eliminate overhead as we
> work
> > > > > > towards a
> > > > > > > release and then when a release is ready someone can create a
> PR
> > > with the
> > > > > > > necessary header changes and in that PR itself we can discuss
> what
> > > is
> > > > > > minor
> > > > > > > and what is major. This can then be tackled at once with
> increased
> > > focus
> > > > > > > and efficiency rather than having to do this work on every PR
> which
> > > > > > incurs
> > > > > > > a lot of overhead. This is especially appealing if the
> decision of
> > > minor
> > > > > > vs
> > > > > > > major is going to remain largely subjective.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > > --
> > > > > > >
> > > > > > > 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:* matthew.dedetrich@aiven.io
> > > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > >
> > > > > 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:* matthew.dedetrich@aiven.io
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
> > --
> >
> > 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:* matthew.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

-- 

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:* matthew.dedetrich@aiven.io

Re: Clarity about minor vs major change wrt source headers.

[Johannes Rudolph <jo...@gmail.com>]

I think the only way forward is to make a change right now to all of
the existing files, everything else will not work because it cannot be
automated.

Where does this distinction between minor vs major changes come from?
It doesn't seem to come from the ASL.

AFAICS, ASL says

 b. You must cause any modified files to carry prominent notices
stating that You changed the files; and

This does not say, in particular, in which way you are allowed to
change files that contain no or minor changes. The main reason that I
could think of is making a misleading statement about who or what owns
the original copyright.

IMO we should add a notice to all files right now that says:

"This software is based on Akka (...). This file/repository was
imported from version [github url including hash]. All changes to this
file are licensed under ASL as shown below. Original license follows."

How could such a message be misinterpreted to be a (mis)appropriation
of the original code?

Also, consider that a file header will never tell the full story (and
seriously no one expects this). The most comprehensive story will be
told through the actual commits (and the Github PR history), and to
figure out who contributed which change or whether it was from the
original fork can only be figured out by looking through the git
history (and if the only thing added was the above comment, then
that's it, nothing misleading there).

In https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140,
Claude mentioned some rules which seem to come from
https://www.apache.org/legal/src-headers.html:

> TREATMENT OF THIRD-PARTY WORKS
>[...]
> 3. Do not add the standard Apache License header to the top of third-party source files.

I can see where that comes from, which is that vendored source code
should not get any gratuitous licenses (especially, if there's no
intention to ever change those files).

> 4. Minor modifications/additions to third-party source files should typically be licensed under the same terms as the rest of the third-party source for convenience.
> 5. The project's PMC should deal with major modifications/additions to third-party source files on a case-by-case basis.

4. + 5. seem to introduce the distinction between minor and major
changes. 4. is a "should" rule and also "for convenience", so maybe we
can just ignore that for now. 5. is probably the cause for this
discussion.

In any case, for a fork the basic assumptions are quite different than
for other projects and, in fact, there will be changes for most files.
Having to decide license headers on a case-by-case basis will not work
for Pekko. It will not work now, because there will be no (I)PMCs that
will review the first release for 10ks of changes to figure out
whether on a case-by-case basis the license was applied directly and
it will not work in the future because it will make each single change
an unworkable act of bureaucracy.

So, we need come up with a workable alternative now.

On Thu, Nov 17, 2022 at 2:08 PM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
>
> So the problem is not new files, new files will always have a new Apache
> header (that is certain). What I am talking about is modifying current
> files, for example I have an upcoming PR which changes the package name
> from akka to org.apache.pekko. This PR will likely touch every single .java
> and .scala source file and while in some cases the change is trivial (i.e.
> literally the `package akka` to `package org.apache.pekko`), other changes
> are not trivial at all. For example parts of the build file need to be
> changed so that generated source files from protobuff go to the right
> package and even certain source files have to also be changed because
> return types with the FQN (fully qualified name) which includes the package
> name as well. There are also cases like this
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> .
>
> In summary I am starting to notice that as time goes on, even to get to the
> full release we will have to modify current files. Also when discussing
> this with Claude, I proposed another solution which is "can we just make it
> so that any change aside from just scalafmt is a major change" which would
> mean that whenever a currently existing source file is changed in any way
> then we just add the Apache Header onto the existing Lightbend copyright
> one but I am not sure if that will fly. Legal seems to imply that we need
> to distinguish between minor and major.
>
>
>
>
>
> On Thu, Nov 17, 2022 at 1:46 PM PJ Fanning <fa...@apache.org> wrote:
>
> > I was going to suggest something similar - that if we can add new code
> > in new class files - that this simplifies the discussion.
> >
> > Obviously, this can't always be the answer because if used the wrong
> > way it messes up the public API. The Lightbend headered file could
> > call the new code in the Apache headered file.
> >
> > In some cases, we may still need to make all the changes in the
> > original Lightbend headered file. And in that case, we could add the
> > Apache header after the Lightbend header.
> >
> > On Thu, 17 Nov 2022 at 13:38, He Pin <he...@apache.org> wrote:
> > >
> > > Can we just add new apache header to newly created files, that's a much
> > simpler rule to follow?
> > > And what about the akka/stream/impl/fusing/Ops.scala which contains a
> > lots of akka stream operators? Would It be better that adding new operators
> > to a dedicated files?
> > >
> > >
> > > On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote:
> > > > Yeah the issue is more about having to repeat this discussion on every
> > > > single PR due to having to agree upon what is a minor or a major
> > change,
> > > > not about this one specifically. Another thing to keep in mind is that
> > > > evidently people also have different opinions on what is a minor
> > change and
> > > > what is a major. This itself is completely fine and normal, the
> > problem is
> > > > that depending on who is reviewing a certain PR we can get
> > > > different results of what is minor vs major and since we are dealing
> > with
> > > > legal issues here this is not exactly desirable.
> > > >
> > > > This is why I am personally leaning much towards the "lets delegate all
> > > > these header decisions due to minor vs major change at once just before
> > > > release". With such a strategy it's easier to get everyone's opinion
> > from
> > > > the PMCC on the matter, collectively come to some conclusion and then
> > as a
> > > > result of that conclusion we can create more clear rules going forward.
> > > >
> > > > On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <fa...@apache.org>
> > wrote:
> > > >
> > > > > In https://github.com/apache/incubator-pekko/pull/50 - I'd prefer
> > to add
> > > > > the ASF header to the CopyrightHeader.scala file - after the existing
> > > > > Lightbend header.
> > > > >
> > > > > I think the change is non-trivial.
> > > > >
> > > > > I think this policy would allow us to make some progress. At the
> > moment,
> > > > > the header issue is really jamming up the works.
> > > > >
> > > > > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> > > > > > Currently there appears to be confusion and/or disagreement
> > regarding
> > > > > what
> > > > > > constitutes a minor vs major change. For context please have a
> > look at
> > > > > >
> > > > >
> > https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > > > > .
> > > > > >
> > > > > > The main problem I foresee (which arguably in my opinion has
> > already
> > > > > > started) is that due to the definition of minor vs major being
> > quite
> > > > > > subjective, it's already started holding up the progress of doing
> > work on
> > > > > > Pekko. This has already started with the PR at
> > > > > > https://github.com/apache/incubator-pekko/pull/50 and also at
> > > > > >
> > > > >
> > https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > > > .
> > > > > > In short, if we are going to debate on every single PR what
> > constitutes a
> > > > > > minor or major change it's going to significantly decrease the
> > velocity
> > > > > of
> > > > > > getting stuff done.
> > > > > >
> > > > > > Would it be possible for us to come to a more technical/strict
> > definition
> > > > > > on what constitutes a minor or major change? The current
> > disagreement
> > > > > from
> > > > > > the previously mentioned PR's is about whether a change to the
> > build
> > > > > (which
> > > > > > has no effect on the execution/use of the software) is major but
> > there
> > > > > will
> > > > > > undoubtedly be many more cases in the future (i.e. does the package
> > > > > rename
> > > > > > from akka to org.apache.pekko also count as a major change? This
> > one is a
> > > > > > lot less clear).
> > > > > >
> > > > > > Alternatively is it also possible for us to suspend the changing of
> > > > > source
> > > > > > headers depending on minor/major changes just before we decide to
> > make a
> > > > > > release? This way we can completely eliminate overhead as we work
> > > > > towards a
> > > > > > release and then when a release is ready someone can create a PR
> > with the
> > > > > > necessary header changes and in that PR itself we can discuss what
> > is
> > > > > minor
> > > > > > and what is major. This can then be tackled at once with increased
> > focus
> > > > > > and efficiency rather than having to do this work on every PR which
> > > > > incurs
> > > > > > a lot of overhead. This is especially appealing if the decision of
> > minor
> > > > > vs
> > > > > > major is going to remain largely subjective.
> > > > > >
> > > > > > Thoughts?
> > > > > > --
> > > > > >
> > > > > > 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:* matthew.dedetrich@aiven.io
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > > 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:* matthew.dedetrich@aiven.io
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
> --
>
> 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:* matthew.dedetrich@aiven.io

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

So the problem is not new files, new files will always have a new Apache
header (that is certain). What I am talking about is modifying current
files, for example I have an upcoming PR which changes the package name
from akka to org.apache.pekko. This PR will likely touch every single .java
and .scala source file and while in some cases the change is trivial (i.e.
literally the `package akka` to `package org.apache.pekko`), other changes
are not trivial at all. For example parts of the build file need to be
changed so that generated source files from protobuff go to the right
package and even certain source files have to also be changed because
return types with the FQN (fully qualified name) which includes the package
name as well. There are also cases like this
https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
.

In summary I am starting to notice that as time goes on, even to get to the
full release we will have to modify current files. Also when discussing
this with Claude, I proposed another solution which is "can we just make it
so that any change aside from just scalafmt is a major change" which would
mean that whenever a currently existing source file is changed in any way
then we just add the Apache Header onto the existing Lightbend copyright
one but I am not sure if that will fly. Legal seems to imply that we need
to distinguish between minor and major.





On Thu, Nov 17, 2022 at 1:46 PM PJ Fanning <fa...@apache.org> wrote:

> I was going to suggest something similar - that if we can add new code
> in new class files - that this simplifies the discussion.
>
> Obviously, this can't always be the answer because if used the wrong
> way it messes up the public API. The Lightbend headered file could
> call the new code in the Apache headered file.
>
> In some cases, we may still need to make all the changes in the
> original Lightbend headered file. And in that case, we could add the
> Apache header after the Lightbend header.
>
> On Thu, 17 Nov 2022 at 13:38, He Pin <he...@apache.org> wrote:
> >
> > Can we just add new apache header to newly created files, that's a much
> simpler rule to follow?
> > And what about the akka/stream/impl/fusing/Ops.scala which contains a
> lots of akka stream operators? Would It be better that adding new operators
> to a dedicated files?
> >
> >
> > On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote:
> > > Yeah the issue is more about having to repeat this discussion on every
> > > single PR due to having to agree upon what is a minor or a major
> change,
> > > not about this one specifically. Another thing to keep in mind is that
> > > evidently people also have different opinions on what is a minor
> change and
> > > what is a major. This itself is completely fine and normal, the
> problem is
> > > that depending on who is reviewing a certain PR we can get
> > > different results of what is minor vs major and since we are dealing
> with
> > > legal issues here this is not exactly desirable.
> > >
> > > This is why I am personally leaning much towards the "lets delegate all
> > > these header decisions due to minor vs major change at once just before
> > > release". With such a strategy it's easier to get everyone's opinion
> from
> > > the PMCC on the matter, collectively come to some conclusion and then
> as a
> > > result of that conclusion we can create more clear rules going forward.
> > >
> > > On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <fa...@apache.org>
> wrote:
> > >
> > > > In https://github.com/apache/incubator-pekko/pull/50 - I'd prefer
> to add
> > > > the ASF header to the CopyrightHeader.scala file - after the existing
> > > > Lightbend header.
> > > >
> > > > I think the change is non-trivial.
> > > >
> > > > I think this policy would allow us to make some progress. At the
> moment,
> > > > the header issue is really jamming up the works.
> > > >
> > > > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> > > > > Currently there appears to be confusion and/or disagreement
> regarding
> > > > what
> > > > > constitutes a minor vs major change. For context please have a
> look at
> > > > >
> > > >
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > > > .
> > > > >
> > > > > The main problem I foresee (which arguably in my opinion has
> already
> > > > > started) is that due to the definition of minor vs major being
> quite
> > > > > subjective, it's already started holding up the progress of doing
> work on
> > > > > Pekko. This has already started with the PR at
> > > > > https://github.com/apache/incubator-pekko/pull/50 and also at
> > > > >
> > > >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > > .
> > > > > In short, if we are going to debate on every single PR what
> constitutes a
> > > > > minor or major change it's going to significantly decrease the
> velocity
> > > > of
> > > > > getting stuff done.
> > > > >
> > > > > Would it be possible for us to come to a more technical/strict
> definition
> > > > > on what constitutes a minor or major change? The current
> disagreement
> > > > from
> > > > > the previously mentioned PR's is about whether a change to the
> build
> > > > (which
> > > > > has no effect on the execution/use of the software) is major but
> there
> > > > will
> > > > > undoubtedly be many more cases in the future (i.e. does the package
> > > > rename
> > > > > from akka to org.apache.pekko also count as a major change? This
> one is a
> > > > > lot less clear).
> > > > >
> > > > > Alternatively is it also possible for us to suspend the changing of
> > > > source
> > > > > headers depending on minor/major changes just before we decide to
> make a
> > > > > release? This way we can completely eliminate overhead as we work
> > > > towards a
> > > > > release and then when a release is ready someone can create a PR
> with the
> > > > > necessary header changes and in that PR itself we can discuss what
> is
> > > > minor
> > > > > and what is major. This can then be tackled at once with increased
> focus
> > > > > and efficiency rather than having to do this work on every PR which
> > > > incurs
> > > > > a lot of overhead. This is especially appealing if the decision of
> minor
> > > > vs
> > > > > major is going to remain largely subjective.
> > > > >
> > > > > Thoughts?
> > > > > --
> > > > >
> > > > > 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:* matthew.dedetrich@aiven.io
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > >
> > > >
> > >
> > > --
> > >
> > > 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:* matthew.dedetrich@aiven.io
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

-- 

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:* matthew.dedetrich@aiven.io

Re: Clarity about minor vs major change wrt source headers.

[PJ Fanning <fa...@apache.org>]

I was going to suggest something similar - that if we can add new code
in new class files - that this simplifies the discussion.

Obviously, this can't always be the answer because if used the wrong
way it messes up the public API. The Lightbend headered file could
call the new code in the Apache headered file.

In some cases, we may still need to make all the changes in the
original Lightbend headered file. And in that case, we could add the
Apache header after the Lightbend header.

On Thu, 17 Nov 2022 at 13:38, He Pin <he...@apache.org> wrote:
>
> Can we just add new apache header to newly created files, that's a much simpler rule to follow?
> And what about the akka/stream/impl/fusing/Ops.scala which contains a lots of akka stream operators? Would It be better that adding new operators to a dedicated files?
>
>
> On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote:
> > Yeah the issue is more about having to repeat this discussion on every
> > single PR due to having to agree upon what is a minor or a major change,
> > not about this one specifically. Another thing to keep in mind is that
> > evidently people also have different opinions on what is a minor change and
> > what is a major. This itself is completely fine and normal, the problem is
> > that depending on who is reviewing a certain PR we can get
> > different results of what is minor vs major and since we are dealing with
> > legal issues here this is not exactly desirable.
> >
> > This is why I am personally leaning much towards the "lets delegate all
> > these header decisions due to minor vs major change at once just before
> > release". With such a strategy it's easier to get everyone's opinion from
> > the PMCC on the matter, collectively come to some conclusion and then as a
> > result of that conclusion we can create more clear rules going forward.
> >
> > On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <fa...@apache.org> wrote:
> >
> > > In https://github.com/apache/incubator-pekko/pull/50 - I'd prefer to add
> > > the ASF header to the CopyrightHeader.scala file - after the existing
> > > Lightbend header.
> > >
> > > I think the change is non-trivial.
> > >
> > > I think this policy would allow us to make some progress. At the moment,
> > > the header issue is really jamming up the works.
> > >
> > > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> > > > Currently there appears to be confusion and/or disagreement regarding
> > > what
> > > > constitutes a minor vs major change. For context please have a look at
> > > >
> > > https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > > .
> > > >
> > > > The main problem I foresee (which arguably in my opinion has already
> > > > started) is that due to the definition of minor vs major being quite
> > > > subjective, it's already started holding up the progress of doing work on
> > > > Pekko. This has already started with the PR at
> > > > https://github.com/apache/incubator-pekko/pull/50 and also at
> > > >
> > > https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > > .
> > > > In short, if we are going to debate on every single PR what constitutes a
> > > > minor or major change it's going to significantly decrease the velocity
> > > of
> > > > getting stuff done.
> > > >
> > > > Would it be possible for us to come to a more technical/strict definition
> > > > on what constitutes a minor or major change? The current disagreement
> > > from
> > > > the previously mentioned PR's is about whether a change to the build
> > > (which
> > > > has no effect on the execution/use of the software) is major but there
> > > will
> > > > undoubtedly be many more cases in the future (i.e. does the package
> > > rename
> > > > from akka to org.apache.pekko also count as a major change? This one is a
> > > > lot less clear).
> > > >
> > > > Alternatively is it also possible for us to suspend the changing of
> > > source
> > > > headers depending on minor/major changes just before we decide to make a
> > > > release? This way we can completely eliminate overhead as we work
> > > towards a
> > > > release and then when a release is ready someone can create a PR with the
> > > > necessary header changes and in that PR itself we can discuss what is
> > > minor
> > > > and what is major. This can then be tackled at once with increased focus
> > > > and efficiency rather than having to do this work on every PR which
> > > incurs
> > > > a lot of overhead. This is especially appealing if the decision of minor
> > > vs
> > > > major is going to remain largely subjective.
> > > >
> > > > Thoughts?
> > > > --
> > > >
> > > > 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:* matthew.dedetrich@aiven.io
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > For additional commands, e-mail: dev-help@pekko.apache.org
> > >
> > >
> >
> > --
> >
> > 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:* matthew.dedetrich@aiven.io
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Clarity about minor vs major change wrt source headers.

[He Pin <he...@apache.org>]

Can we just add new apache header to newly created files, that's a much simpler rule to follow?
And what about the akka/stream/impl/fusing/Ops.scala which contains a lots of akka stream operators? Would It be better that adding new operators to a dedicated files?


On 2022/11/17 12:04:37 Matthew Benedict de Detrich wrote:
> Yeah the issue is more about having to repeat this discussion on every
> single PR due to having to agree upon what is a minor or a major change,
> not about this one specifically. Another thing to keep in mind is that
> evidently people also have different opinions on what is a minor change and
> what is a major. This itself is completely fine and normal, the problem is
> that depending on who is reviewing a certain PR we can get
> different results of what is minor vs major and since we are dealing with
> legal issues here this is not exactly desirable.
> 
> This is why I am personally leaning much towards the "lets delegate all
> these header decisions due to minor vs major change at once just before
> release". With such a strategy it's easier to get everyone's opinion from
> the PMCC on the matter, collectively come to some conclusion and then as a
> result of that conclusion we can create more clear rules going forward.
> 
> On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <fa...@apache.org> wrote:
> 
> > In https://github.com/apache/incubator-pekko/pull/50 - I'd prefer to add
> > the ASF header to the CopyrightHeader.scala file - after the existing
> > Lightbend header.
> >
> > I think the change is non-trivial.
> >
> > I think this policy would allow us to make some progress. At the moment,
> > the header issue is really jamming up the works.
> >
> > On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> > > Currently there appears to be confusion and/or disagreement regarding
> > what
> > > constitutes a minor vs major change. For context please have a look at
> > >
> > https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> > .
> > >
> > > The main problem I foresee (which arguably in my opinion has already
> > > started) is that due to the definition of minor vs major being quite
> > > subjective, it's already started holding up the progress of doing work on
> > > Pekko. This has already started with the PR at
> > > https://github.com/apache/incubator-pekko/pull/50 and also at
> > >
> > https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> > .
> > > In short, if we are going to debate on every single PR what constitutes a
> > > minor or major change it's going to significantly decrease the velocity
> > of
> > > getting stuff done.
> > >
> > > Would it be possible for us to come to a more technical/strict definition
> > > on what constitutes a minor or major change? The current disagreement
> > from
> > > the previously mentioned PR's is about whether a change to the build
> > (which
> > > has no effect on the execution/use of the software) is major but there
> > will
> > > undoubtedly be many more cases in the future (i.e. does the package
> > rename
> > > from akka to org.apache.pekko also count as a major change? This one is a
> > > lot less clear).
> > >
> > > Alternatively is it also possible for us to suspend the changing of
> > source
> > > headers depending on minor/major changes just before we decide to make a
> > > release? This way we can completely eliminate overhead as we work
> > towards a
> > > release and then when a release is ready someone can create a PR with the
> > > necessary header changes and in that PR itself we can discuss what is
> > minor
> > > and what is major. This can then be tackled at once with increased focus
> > > and efficiency rather than having to do this work on every PR which
> > incurs
> > > a lot of overhead. This is especially appealing if the decision of minor
> > vs
> > > major is going to remain largely subjective.
> > >
> > > Thoughts?
> > > --
> > >
> > > 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:* matthew.dedetrich@aiven.io
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
> 
> -- 
> 
> 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:* matthew.dedetrich@aiven.io
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org

Re: Clarity about minor vs major change wrt source headers.

[Matthew Benedict de Detrich <ma...@aiven.io.INVALID>]

Yeah the issue is more about having to repeat this discussion on every
single PR due to having to agree upon what is a minor or a major change,
not about this one specifically. Another thing to keep in mind is that
evidently people also have different opinions on what is a minor change and
what is a major. This itself is completely fine and normal, the problem is
that depending on who is reviewing a certain PR we can get
different results of what is minor vs major and since we are dealing with
legal issues here this is not exactly desirable.

This is why I am personally leaning much towards the "lets delegate all
these header decisions due to minor vs major change at once just before
release". With such a strategy it's easier to get everyone's opinion from
the PMCC on the matter, collectively come to some conclusion and then as a
result of that conclusion we can create more clear rules going forward.

On Thu, Nov 17, 2022 at 12:51 PM PJ Fanning <fa...@apache.org> wrote:

> In https://github.com/apache/incubator-pekko/pull/50 - I'd prefer to add
> the ASF header to the CopyrightHeader.scala file - after the existing
> Lightbend header.
>
> I think the change is non-trivial.
>
> I think this policy would allow us to make some progress. At the moment,
> the header issue is really jamming up the works.
>
> On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> > Currently there appears to be confusion and/or disagreement regarding
> what
> > constitutes a minor vs major change. For context please have a look at
> >
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140
> .
> >
> > The main problem I foresee (which arguably in my opinion has already
> > started) is that due to the definition of minor vs major being quite
> > subjective, it's already started holding up the progress of doing work on
> > Pekko. This has already started with the PR at
> > https://github.com/apache/incubator-pekko/pull/50 and also at
> >
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937
> .
> > In short, if we are going to debate on every single PR what constitutes a
> > minor or major change it's going to significantly decrease the velocity
> of
> > getting stuff done.
> >
> > Would it be possible for us to come to a more technical/strict definition
> > on what constitutes a minor or major change? The current disagreement
> from
> > the previously mentioned PR's is about whether a change to the build
> (which
> > has no effect on the execution/use of the software) is major but there
> will
> > undoubtedly be many more cases in the future (i.e. does the package
> rename
> > from akka to org.apache.pekko also count as a major change? This one is a
> > lot less clear).
> >
> > Alternatively is it also possible for us to suspend the changing of
> source
> > headers depending on minor/major changes just before we decide to make a
> > release? This way we can completely eliminate overhead as we work
> towards a
> > release and then when a release is ready someone can create a PR with the
> > necessary header changes and in that PR itself we can discuss what is
> minor
> > and what is major. This can then be tackled at once with increased focus
> > and efficiency rather than having to do this work on every PR which
> incurs
> > a lot of overhead. This is especially appealing if the decision of minor
> vs
> > major is going to remain largely subjective.
> >
> > Thoughts?
> > --
> >
> > 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:* matthew.dedetrich@aiven.io
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>

-- 

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:* matthew.dedetrich@aiven.io

Re: Clarity about minor vs major change wrt source headers.

[PJ Fanning <fa...@apache.org>]

In https://github.com/apache/incubator-pekko/pull/50 - I'd prefer to add the ASF header to the CopyrightHeader.scala file - after the existing Lightbend header.

I think the change is non-trivial.

I think this policy would allow us to make some progress. At the moment, the header issue is really jamming up the works. 

On 2022/11/17 09:21:21 Matthew Benedict de Detrich wrote:
> Currently there appears to be confusion and/or disagreement regarding what
> constitutes a minor vs major change. For context please have a look at
> https://github.com/apache/incubator-pekko/issues/38#issuecomment-1311468140.
> 
> The main problem I foresee (which arguably in my opinion has already
> started) is that due to the definition of minor vs major being quite
> subjective, it's already started holding up the progress of doing work on
> Pekko. This has already started with the PR at
> https://github.com/apache/incubator-pekko/pull/50 and also at
> https://github.com/apache/incubator-pekko-http/pull/8#issuecomment-1316786937.
> In short, if we are going to debate on every single PR what constitutes a
> minor or major change it's going to significantly decrease the velocity of
> getting stuff done.
> 
> Would it be possible for us to come to a more technical/strict definition
> on what constitutes a minor or major change? The current disagreement from
> the previously mentioned PR's is about whether a change to the build (which
> has no effect on the execution/use of the software) is major but there will
> undoubtedly be many more cases in the future (i.e. does the package rename
> from akka to org.apache.pekko also count as a major change? This one is a
> lot less clear).
> 
> Alternatively is it also possible for us to suspend the changing of source
> headers depending on minor/major changes just before we decide to make a
> release? This way we can completely eliminate overhead as we work towards a
> release and then when a release is ready someone can create a PR with the
> necessary header changes and in that PR itself we can discuss what is minor
> and what is major. This can then be tackled at once with increased focus
> and efficiency rather than having to do this work on every PR which incurs
> a lot of overhead. This is especially appealing if the decision of minor vs
> major is going to remain largely subjective.
> 
> Thoughts?
> -- 
> 
> 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:* matthew.dedetrich@aiven.io
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org