You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pekko.apache.org by Johannes Rudolph <jo...@gmail.com> on 2022/11/03 10:07:40 UTC
Pekko-HTTP approach
Hi,
for pekko-http, we need to think about how to approach the first few
changes. We should do:
* integrate the Scala 3 branch that was not yet released
* move from scalariform to scalafmt
* new package names
Originally, the Scala 3 branch was not yet merged (and therefore
missed 10.2.10) because it does not mix all to well with Scala 2.12
support. It works but it requires some hacky patching of source files
to remove some code that cannot be compiled on all targets (we tried
to avoid version-dependent source files especially here since it
touches the biggest source file, headers.scala, and we have had many
bad experiences with bugs in versioned forks of source files).
At this point I would probably just merge the existing Scala 3 branch
to ensure this work is not lost even if it adds complexity to the
build. The hope would be that we might be able to drop Scala 2.12 soon
after the first release to clean things up.
In general, it goes somewhat against the goal of not adding any
changes in the first version of pekko but doing the merge later on
will be quite painful.
If you agree, we should try to do the changes in the order as shown above.
(Obviously, we should use the state of the scala-3 branch before the
license change. Afterwards, a merge from main was added containing the
license change.)
WDYT?
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Pekko-HTTP approach
Posted by Alexandru Nedelcu <ap...@a.alexn.org>.
Hi,
On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
> (Obviously, we should use the state of the scala-3 branch before the
> license change. Afterwards, a merge from main was added containing the
> license change.)
It would be great to merge that scala-3 branch. I think Akka-HTTP is
what’s keeping us at $work from migrating to Scala 3 (plus other
annoyances, but this is the big one).
However — I’d ask if we are allowed.
I am not a lawyer, but does code in that PR represent code that’s
released under APL-2.0? My hunch is that there may be issues with this.
I think we should ask someone with legal expertise if we are allowed.
Can ASF help?
--
Alexandru Nedelcu
https://alexn.org
Re: Pekko-HTTP approach
Posted by PJ Fanning <fa...@gmail.com>.
Thanks Johannes for creating the branch. It looks like the 'main'
branch will merge ok to the scala-3 branch. There is just one small
merge conflict in one of the github workflow files (and easily fixed).
It seems like there is no major need to get that merge done yet.
On Thu, 3 Nov 2022 at 12:27, Johannes Rudolph
<jo...@gmail.com> wrote:
>
> On Thu, Nov 3, 2022 at 12:07 PM PJ Fanning <fa...@gmail.com> wrote:
> > Johannes - would it help to copy over the scala3 branch to
> > incubator-pekko-http now and we can all chip in on ensuring regular
> > merges from the main branch?
>
> I created a branch at
> https://github.com/apache/incubator-pekko-http/tree/scala-3 with the
> latest version I think we should use (last commit 2022-08-23).
>
> ---------------------------------------------------------------------
> 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: Pekko-HTTP approach
Posted by Johannes Rudolph <jo...@gmail.com>.
On Thu, Nov 3, 2022 at 12:07 PM PJ Fanning <fa...@gmail.com> wrote:
> Johannes - would it help to copy over the scala3 branch to
> incubator-pekko-http now and we can all chip in on ensuring regular
> merges from the main branch?
I created a branch at
https://github.com/apache/incubator-pekko-http/tree/scala-3 with the
latest version I think we should use (last commit 2022-08-23).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Pekko-HTTP approach
Posted by PJ Fanning <fa...@gmail.com>.
I tend to agree with Matthew and Daniel.
Johannes - would it help to copy over the scala3 branch to
incubator-pekko-http now and we can all chip in on ensuring regular
merges from the main branch?
On Thu, 3 Nov 2022 at 11:56, Johannes Rudolph
<jo...@gmail.com> wrote:
>
> On Thu, Nov 3, 2022 at 11:31 AM Daniel Schroeter <ds...@theone.ch> wrote:
> > Please correct me if i am wrong but i think the "scalafmt" and "new
> > package names" should be straight forward transformations that could be
> > applied to the scala3 branch as well.
> > This should not lead to a merge hell i believe. Wouldn't this also be a
> > possible approach?
>
> In theory, it might work, can still be somewhat of a hassle which big
> changes like this. But I agree,
> if the Scala 3 merge is difficult or contentious, it should not hold
> up the rest of the process.
>
> ---------------------------------------------------------------------
> 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: Pekko-HTTP approach
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
The scalafmt changes shouldn’t create a large conflict if you apply the same scalafmt to the changes you are trying to apply, I have done this before in upstream projects.
--
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
On 3. Nov 2022 at 11:56 +0100, Johannes Rudolph <jo...@gmail.com>, wrote:
> On Thu, Nov 3, 2022 at 11:31 AM Daniel Schroeter <ds...@theone.ch> wrote:
> > Please correct me if i am wrong but i think the "scalafmt" and "new
> > package names" should be straight forward transformations that could be
> > applied to the scala3 branch as well.
> > This should not lead to a merge hell i believe. Wouldn't this also be a
> > possible approach?
>
> In theory, it might work, can still be somewhat of a hassle which big
> changes like this. But I agree,
> if the Scala 3 merge is difficult or contentious, it should not hold
> up the rest of the process.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
Re: Pekko-HTTP approach
Posted by Johannes Rudolph <jo...@gmail.com>.
On Thu, Nov 3, 2022 at 11:31 AM Daniel Schroeter <ds...@theone.ch> wrote:
> Please correct me if i am wrong but i think the "scalafmt" and "new
> package names" should be straight forward transformations that could be
> applied to the scala3 branch as well.
> This should not lead to a merge hell i believe. Wouldn't this also be a
> possible approach?
In theory, it might work, can still be somewhat of a hassle which big
changes like this. But I agree,
if the Scala 3 merge is difficult or contentious, it should not hold
up the rest of the process.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Pekko-HTTP approach
Posted by Daniel Schroeter <ds...@theone.ch>.
Hi Johannes
Please correct me if i am wrong but i think the "scalafmt" and "new
package names" should be straight forward transformations that could be
applied to the scala3 branch as well.
This should not lead to a merge hell i believe. Wouldn't this also be a
possible approach?
Daniel
On 11/3/22 11:07, Johannes Rudolph wrote:
> Hi,
>
> for pekko-http, we need to think about how to approach the first few
> changes. We should do:
>
> * integrate the Scala 3 branch that was not yet released
> * move from scalariform to scalafmt
> * new package names
>
> Originally, the Scala 3 branch was not yet merged (and therefore
> missed 10.2.10) because it does not mix all to well with Scala 2.12
> support. It works but it requires some hacky patching of source files
> to remove some code that cannot be compiled on all targets (we tried
> to avoid version-dependent source files especially here since it
> touches the biggest source file, headers.scala, and we have had many
> bad experiences with bugs in versioned forks of source files).
>
> At this point I would probably just merge the existing Scala 3 branch
> to ensure this work is not lost even if it adds complexity to the
> build. The hope would be that we might be able to drop Scala 2.12 soon
> after the first release to clean things up.
>
> In general, it goes somewhat against the goal of not adding any
> changes in the first version of pekko but doing the merge later on
> will be quite painful.
>
> If you agree, we should try to do the changes in the order as shown above.
>
> (Obviously, we should use the state of the scala-3 branch before the
> license change. Afterwards, a merge from main was added containing the
> license change.)
>
> WDYT?
> Johannes
>
> ---------------------------------------------------------------------
> 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: Pekko-HTTP approach
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
The Lightbend CLAs are based on Apache ones and do not transfer copyright as are fine to use as long as they are under the ALv2.
Kind Regards,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Pekko-HTTP approach
Posted by Johannes Rudolph <jo...@gmail.com>.
Maybe more info about the scala-3 branch: Most of it was contributed
from external contributors (big shout out to Hugh Simpson and Jan
Chyb) with only some parts done by me itself. All the contributions
already have gone through PRs to be merged into the scala-3 branch. We
kept this long running branch to keep a public record of what's
already done and what is still missing.
As such, I see the existing Scala 3 PR only as a kind of discussion
ground and way to make the branch itself more visible. The branch has
been public on the real repository from the beginning with the
existing ASL, so my interpretation would be that this work can be seen
as published under ASL (but IANAL, of course).
On Fri, Nov 4, 2022 at 10:06 AM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> > If Johannes is the author of that PR, it’s a big deal, because he
> still owns the copyright for his work. This case, as far as I’m
> concerned, is closed.
While this might be technically true, my contributions have been made
as an employee, so additional restrictions apply. But this should not
matter in this case because the whole has been publicized under ASL.
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Pekko-HTTP approach
Posted by Jean-Luc Deprez <Je...@gmail.com>.
For clarity, it's my understanding that Johannes was employed by Lightbend
until recently. Now I don't know about you guys, but code I write is
property of my employer. That's also the reason CCLA's exist. If the case,
there wouldn't be any sublicense stuff going on for that work.
Anyhow, I don't think it matters.
Any git commit defines a working tree or could be extracted to a zip, which
would adhere to being an ASL compliant distribution. As such, as long as
BSL wasn't merged to a branch it would be legit to consume it.
As stated, we're not relying on a software grant from Lightbend and the
legal ground for both cases is the same.
On Fri, Nov 4, 2022, 11:01 Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> Specifically wrt having the code in pull requests that haven’t been merged
> yet, I had a discussion with colleagues about this in the past and at least
> hypothetically speaking since the code is sitting on the branch of the pull
> request author, if that branch’s main is still based off of Ikea’s ASFL 2
> version then it should be okay.
>
> Again IANAL.
>
> --
> 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
> On 4. Nov 2022 at 10:41 +0100, Greg Methvin <gr...@apache.org>, wrote:
> > IANAL either, but I think the gray area is that some pull requests need
> to
> > copy parts of existing code or certain aspects of the design of the
> > library. Once you've looked at a library's code and written a PR, there's
> > some risk that you included some content that isn't technically your
> > original work. So maybe you don't have the right to just take everything
> in
> > the PR and contribute it to another library.
> >
> > On Fri, Nov 4, 2022 at 2:06 AM Matthew Benedict de Detrich
> > <ma...@aiven.io.invalid> wrote:
> >
> > > > If Johannes is the author of that PR, it’s a big deal, because he
> > > still owns the copyright for his work. This case, as far as I’m
> > > concerned, is closed.
> > >
> > > IANAL but this is my understanding as well. If you yourself create a PR
> > > then you retain copyright for it (i.e. the code) which means that its
> fine
> > > to contribute that same code to another project even if it has a
> different
> > > license (in this case BSL vs ASFL 2), the problem is copying/reading
> other
> > > peoples BSL code.
> > >
> > > On Fri, Nov 4, 2022 at 9:44 AM Alexandru Nedelcu <al...@apache.org>
> > > wrote:
> > >
> > > > Lightbend’s CLA doesn’t transfer the copyright, but what it does is
> > > > it allows Lightbend to “sublicense” it as proprietary, which I guess
> > > > (IANAL, etc) is why they can legally change the license in their
> > > > repository without mentioning that some of that code is still
> available
> > > > as ASL-2.
> > > >
> > > > If Johannes is the author of that PR, it’s a big deal, because he
> > > > still owns the copyright for his work. This case, as far as I’m
> > > > concerned, is closed.
> > > >
> > > > My objection was about PRs in general — if a PR was made, that
> > > > doesn’t mean that the contribution was licensed under ASL-2, just
> > > > because the repository’s LICENSE was indicating ASL-2 at that time.
> > > >
> > > > Consider the situation in which (royal) you made a PR to Akka when it
> > > > was licensed as ASL-2, but it gets rejected for whatever reason.
> > > > That’s life, and you move on. Well, what happens if Lightbend copies
> > > > the code in that rejected PR, after the license changed? The
> original PR
> > > > was rejected, it was never “distributed”, you never agreed to the
> > > > merge, because the merge never happened. The PR itself was only a
> > > > proposal, after all.
> > > >
> > > > Therefore I’m wondering — is it legal to copy code from PRs that
> > > > were open before the license change? Are those PRs actually licensed
> as
> > > > ASL-2?
> > > >
> > > > If yes, well, let’s copy them all, I’m sure there are gems in there.
> > > > But my hunch is that there are issues with it, and I’d really like to
> > > > know the answer to this conundrum, as copyright law is really
> confusing
> > > > for me.
> > > >
> > > > And does the ASF have some legal expertise available, such that we
> can
> > > > settle these matters?
> > > >
> > > > On 3 Nov 2022, at 22:54, Greg Methvin wrote:
> > > >
> > > > > My understanding is that the Lightbend CLA only gives Lightbend a
> > > > > license
> > > > > to use and redistribute the code; it doesn't transfer copyright.
> Where
> > > > > it
> > > > > gets tricky is that many PRs can incorporate parts of the existing
> > > > > code in
> > > > > various ways, so are effectively a derivative work rather than
> being
> > > > > totally original, and you're on shaky ground unless you can prove
> that
> > > > > the
> > > > > code it's based on is entirely ASL licensed. But like you said, the
> > > > > commit
> > > > > it's based on is entirely ASL licensed code so there is no issue.
> > > > >
> > > > > On Thu, Nov 3, 2022 at 10:50 AM Jean-Luc Deprez
> > > > > <Je...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Fact that Johannes authored most of the work wouldn't matter
> much, as
> > > > > > I'd
> > > > > > guess copyright transfer would be in place.
> > > > > >
> > > > > > But what Johannes stated doing is the legal ground. A git commit
> is a
> > > > > > copy
> > > > > > of the source, if that copy contains the ASL license instead of
> the
> > > > > > BSL,
> > > > > > the ASL terms apply. So the last commit on branch before BSL
> merge is
> > > > > > safe.
> > > > > >
> > > > > > Which is the legal ground for this whole endeavor anyway.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Nov 3, 2022, 12:44 PJ Fanning <fa...@gmail.com>
> wrote:
> > > > > >
> > > > > > > The original PR was created before the license was changed. I
> think
> > > > > > > it
> > > > > > > should be safe to take into pekko-http, especially since
> Johannes
> > > > > > > who
> > > > > > > wrote the original PR is and is offering to help with getting
> it
> > > > > > > into
> > > > > > > pekko-http.
> > > > > > >
> > > > > > > On Thu, 3 Nov 2022 at 12:29, Alexandru Nedelcu <
> alexelcu@apache.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I’m resending this message from the “right” email address
> > > > > > > > 🙂
> > > > > > > > sorry for the duplicate…
> > > > > > > >
> > > > > > > > On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
> > > > > > > > > (Obviously, we should use the state of the scala-3 branch
> before
> > > > > > > > > the
> > > > > > > > > license change. Afterwards, a merge from main was added
> containing
> > > > > > the
> > > > > > > > > license change.)
> > > > > > > >
> > > > > > > > It would be great to merge that scala-3 branch. I think
> Akka-HTTP
> > > > > > > > is
> > > > > > > > what’s keeping us at $work from migrating to Scala 3 (plus
> other
> > > > > > > > annoyances, but this is the big one).
> > > > > > > >
> > > > > > > > However — I’d ask if we are allowed.
> > > > > > > >
> > > > > > > > I am not a lawyer. Does code in that PR represent code that’s
> > > > > > > > released
> > > > > > > > under APL-2.0? My hunch is that there may be issues with
> this.
> > > > > > > >
> > > > > > > > I think we should ask someone with legal expertise if we are
> > > > > > > > allowed.
> > > > > > > > Can ASF help?
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alexandru Nedelcu
> > > > > > > > https://alexn.org
> > > > > > >
> > > > > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > >
> > > > --
> > > > Alexandru Nedelcu
> > > > https://alexn.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: Pekko-HTTP approach
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
Specifically wrt having the code in pull requests that haven’t been merged yet, I had a discussion with colleagues about this in the past and at least hypothetically speaking since the code is sitting on the branch of the pull request author, if that branch’s main is still based off of Ikea’s ASFL 2 version then it should be okay.
Again IANAL.
--
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
On 4. Nov 2022 at 10:41 +0100, Greg Methvin <gr...@apache.org>, wrote:
> IANAL either, but I think the gray area is that some pull requests need to
> copy parts of existing code or certain aspects of the design of the
> library. Once you've looked at a library's code and written a PR, there's
> some risk that you included some content that isn't technically your
> original work. So maybe you don't have the right to just take everything in
> the PR and contribute it to another library.
>
> On Fri, Nov 4, 2022 at 2:06 AM Matthew Benedict de Detrich
> <ma...@aiven.io.invalid> wrote:
>
> > > If Johannes is the author of that PR, it’s a big deal, because he
> > still owns the copyright for his work. This case, as far as I’m
> > concerned, is closed.
> >
> > IANAL but this is my understanding as well. If you yourself create a PR
> > then you retain copyright for it (i.e. the code) which means that its fine
> > to contribute that same code to another project even if it has a different
> > license (in this case BSL vs ASFL 2), the problem is copying/reading other
> > peoples BSL code.
> >
> > On Fri, Nov 4, 2022 at 9:44 AM Alexandru Nedelcu <al...@apache.org>
> > wrote:
> >
> > > Lightbend’s CLA doesn’t transfer the copyright, but what it does is
> > > it allows Lightbend to “sublicense” it as proprietary, which I guess
> > > (IANAL, etc) is why they can legally change the license in their
> > > repository without mentioning that some of that code is still available
> > > as ASL-2.
> > >
> > > If Johannes is the author of that PR, it’s a big deal, because he
> > > still owns the copyright for his work. This case, as far as I’m
> > > concerned, is closed.
> > >
> > > My objection was about PRs in general — if a PR was made, that
> > > doesn’t mean that the contribution was licensed under ASL-2, just
> > > because the repository’s LICENSE was indicating ASL-2 at that time.
> > >
> > > Consider the situation in which (royal) you made a PR to Akka when it
> > > was licensed as ASL-2, but it gets rejected for whatever reason.
> > > That’s life, and you move on. Well, what happens if Lightbend copies
> > > the code in that rejected PR, after the license changed? The original PR
> > > was rejected, it was never “distributed”, you never agreed to the
> > > merge, because the merge never happened. The PR itself was only a
> > > proposal, after all.
> > >
> > > Therefore I’m wondering — is it legal to copy code from PRs that
> > > were open before the license change? Are those PRs actually licensed as
> > > ASL-2?
> > >
> > > If yes, well, let’s copy them all, I’m sure there are gems in there.
> > > But my hunch is that there are issues with it, and I’d really like to
> > > know the answer to this conundrum, as copyright law is really confusing
> > > for me.
> > >
> > > And does the ASF have some legal expertise available, such that we can
> > > settle these matters?
> > >
> > > On 3 Nov 2022, at 22:54, Greg Methvin wrote:
> > >
> > > > My understanding is that the Lightbend CLA only gives Lightbend a
> > > > license
> > > > to use and redistribute the code; it doesn't transfer copyright. Where
> > > > it
> > > > gets tricky is that many PRs can incorporate parts of the existing
> > > > code in
> > > > various ways, so are effectively a derivative work rather than being
> > > > totally original, and you're on shaky ground unless you can prove that
> > > > the
> > > > code it's based on is entirely ASL licensed. But like you said, the
> > > > commit
> > > > it's based on is entirely ASL licensed code so there is no issue.
> > > >
> > > > On Thu, Nov 3, 2022 at 10:50 AM Jean-Luc Deprez
> > > > <Je...@gmail.com>
> > > > wrote:
> > > >
> > > > > Fact that Johannes authored most of the work wouldn't matter much, as
> > > > > I'd
> > > > > guess copyright transfer would be in place.
> > > > >
> > > > > But what Johannes stated doing is the legal ground. A git commit is a
> > > > > copy
> > > > > of the source, if that copy contains the ASL license instead of the
> > > > > BSL,
> > > > > the ASL terms apply. So the last commit on branch before BSL merge is
> > > > > safe.
> > > > >
> > > > > Which is the legal ground for this whole endeavor anyway.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Nov 3, 2022, 12:44 PJ Fanning <fa...@gmail.com> wrote:
> > > > >
> > > > > > The original PR was created before the license was changed. I think
> > > > > > it
> > > > > > should be safe to take into pekko-http, especially since Johannes
> > > > > > who
> > > > > > wrote the original PR is and is offering to help with getting it
> > > > > > into
> > > > > > pekko-http.
> > > > > >
> > > > > > On Thu, 3 Nov 2022 at 12:29, Alexandru Nedelcu <al...@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I’m resending this message from the “right” email address
> > > > > > > 🙂
> > > > > > > sorry for the duplicate…
> > > > > > >
> > > > > > > On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
> > > > > > > > (Obviously, we should use the state of the scala-3 branch before
> > > > > > > > the
> > > > > > > > license change. Afterwards, a merge from main was added containing
> > > > > the
> > > > > > > > license change.)
> > > > > > >
> > > > > > > It would be great to merge that scala-3 branch. I think Akka-HTTP
> > > > > > > is
> > > > > > > what’s keeping us at $work from migrating to Scala 3 (plus other
> > > > > > > annoyances, but this is the big one).
> > > > > > >
> > > > > > > However — I’d ask if we are allowed.
> > > > > > >
> > > > > > > I am not a lawyer. Does code in that PR represent code that’s
> > > > > > > released
> > > > > > > under APL-2.0? My hunch is that there may be issues with this.
> > > > > > >
> > > > > > > I think we should ask someone with legal expertise if we are
> > > > > > > allowed.
> > > > > > > Can ASF help?
> > > > > > >
> > > > > > > --
> > > > > > > Alexandru Nedelcu
> > > > > > > https://alexn.org
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > > > > > For additional commands, e-mail: dev-help@pekko.apache.org
> > > > > >
> > > > > >
> > > > >
> > >
> > >
> > > --
> > > Alexandru Nedelcu
> > > https://alexn.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: Pekko-HTTP approach
Posted by Greg Methvin <gr...@apache.org>.
IANAL either, but I think the gray area is that some pull requests need to
copy parts of existing code or certain aspects of the design of the
library. Once you've looked at a library's code and written a PR, there's
some risk that you included some content that isn't technically your
original work. So maybe you don't have the right to just take everything in
the PR and contribute it to another library.
On Fri, Nov 4, 2022 at 2:06 AM Matthew Benedict de Detrich
<ma...@aiven.io.invalid> wrote:
> > If Johannes is the author of that PR, it’s a big deal, because he
> still owns the copyright for his work. This case, as far as I’m
> concerned, is closed.
>
> IANAL but this is my understanding as well. If you yourself create a PR
> then you retain copyright for it (i.e. the code) which means that its fine
> to contribute that same code to another project even if it has a different
> license (in this case BSL vs ASFL 2), the problem is copying/reading other
> peoples BSL code.
>
> On Fri, Nov 4, 2022 at 9:44 AM Alexandru Nedelcu <al...@apache.org>
> wrote:
>
> > Lightbend’s CLA doesn’t transfer the copyright, but what it does is
> > it allows Lightbend to “sublicense” it as proprietary, which I guess
> > (IANAL, etc) is why they can legally change the license in their
> > repository without mentioning that some of that code is still available
> > as ASL-2.
> >
> > If Johannes is the author of that PR, it’s a big deal, because he
> > still owns the copyright for his work. This case, as far as I’m
> > concerned, is closed.
> >
> > My objection was about PRs in general — if a PR was made, that
> > doesn’t mean that the contribution was licensed under ASL-2, just
> > because the repository’s LICENSE was indicating ASL-2 at that time.
> >
> > Consider the situation in which (royal) you made a PR to Akka when it
> > was licensed as ASL-2, but it gets rejected for whatever reason.
> > That’s life, and you move on. Well, what happens if Lightbend copies
> > the code in that rejected PR, after the license changed? The original PR
> > was rejected, it was never “distributed”, you never agreed to the
> > merge, because the merge never happened. The PR itself was only a
> > proposal, after all.
> >
> > Therefore I’m wondering — is it legal to copy code from PRs that
> > were open before the license change? Are those PRs actually licensed as
> > ASL-2?
> >
> > If yes, well, let’s copy them all, I’m sure there are gems in there.
> > But my hunch is that there are issues with it, and I’d really like to
> > know the answer to this conundrum, as copyright law is really confusing
> > for me.
> >
> > And does the ASF have some legal expertise available, such that we can
> > settle these matters?
> >
> > On 3 Nov 2022, at 22:54, Greg Methvin wrote:
> >
> > > My understanding is that the Lightbend CLA only gives Lightbend a
> > > license
> > > to use and redistribute the code; it doesn't transfer copyright. Where
> > > it
> > > gets tricky is that many PRs can incorporate parts of the existing
> > > code in
> > > various ways, so are effectively a derivative work rather than being
> > > totally original, and you're on shaky ground unless you can prove that
> > > the
> > > code it's based on is entirely ASL licensed. But like you said, the
> > > commit
> > > it's based on is entirely ASL licensed code so there is no issue.
> > >
> > > On Thu, Nov 3, 2022 at 10:50 AM Jean-Luc Deprez
> > > <Je...@gmail.com>
> > > wrote:
> > >
> > >> Fact that Johannes authored most of the work wouldn't matter much, as
> > >> I'd
> > >> guess copyright transfer would be in place.
> > >>
> > >> But what Johannes stated doing is the legal ground. A git commit is a
> > >> copy
> > >> of the source, if that copy contains the ASL license instead of the
> > >> BSL,
> > >> the ASL terms apply. So the last commit on branch before BSL merge is
> > >> safe.
> > >>
> > >> Which is the legal ground for this whole endeavor anyway.
> > >>
> > >>
> > >>
> > >>
> > >> On Thu, Nov 3, 2022, 12:44 PJ Fanning <fa...@gmail.com> wrote:
> > >>
> > >>> The original PR was created before the license was changed. I think
> > >>> it
> > >>> should be safe to take into pekko-http, especially since Johannes
> > >>> who
> > >>> wrote the original PR is and is offering to help with getting it
> > >>> into
> > >>> pekko-http.
> > >>>
> > >>> On Thu, 3 Nov 2022 at 12:29, Alexandru Nedelcu <al...@apache.org>
> > >>> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> I’m resending this message from the “right” email address
> > >>>> 🙂
> > >>>> sorry for the duplicate…
> > >>>>
> > >>>> On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
> > >>>>> (Obviously, we should use the state of the scala-3 branch before
> > >>>>> the
> > >>>>> license change. Afterwards, a merge from main was added containing
> > >> the
> > >>>>> license change.)
> > >>>>
> > >>>> It would be great to merge that scala-3 branch. I think Akka-HTTP
> > >>>> is
> > >>>> what’s keeping us at $work from migrating to Scala 3 (plus other
> > >>>> annoyances, but this is the big one).
> > >>>>
> > >>>> However — I’d ask if we are allowed.
> > >>>>
> > >>>> I am not a lawyer. Does code in that PR represent code that’s
> > >>>> released
> > >>>> under APL-2.0? My hunch is that there may be issues with this.
> > >>>>
> > >>>> I think we should ask someone with legal expertise if we are
> > >>>> allowed.
> > >>>> Can ASF help?
> > >>>>
> > >>>> --
> > >>>> Alexandru Nedelcu
> > >>>> https://alexn.org
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > >>> For additional commands, e-mail: dev-help@pekko.apache.org
> > >>>
> > >>>
> > >>
> >
> >
> > --
> > Alexandru Nedelcu
> > https://alexn.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: Pekko-HTTP approach
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
> If Johannes is the author of that PR, it’s a big deal, because he
still owns the copyright for his work. This case, as far as I’m
concerned, is closed.
IANAL but this is my understanding as well. If you yourself create a PR
then you retain copyright for it (i.e. the code) which means that its fine
to contribute that same code to another project even if it has a different
license (in this case BSL vs ASFL 2), the problem is copying/reading other
peoples BSL code.
On Fri, Nov 4, 2022 at 9:44 AM Alexandru Nedelcu <al...@apache.org>
wrote:
> Lightbend’s CLA doesn’t transfer the copyright, but what it does is
> it allows Lightbend to “sublicense” it as proprietary, which I guess
> (IANAL, etc) is why they can legally change the license in their
> repository without mentioning that some of that code is still available
> as ASL-2.
>
> If Johannes is the author of that PR, it’s a big deal, because he
> still owns the copyright for his work. This case, as far as I’m
> concerned, is closed.
>
> My objection was about PRs in general — if a PR was made, that
> doesn’t mean that the contribution was licensed under ASL-2, just
> because the repository’s LICENSE was indicating ASL-2 at that time.
>
> Consider the situation in which (royal) you made a PR to Akka when it
> was licensed as ASL-2, but it gets rejected for whatever reason.
> That’s life, and you move on. Well, what happens if Lightbend copies
> the code in that rejected PR, after the license changed? The original PR
> was rejected, it was never “distributed”, you never agreed to the
> merge, because the merge never happened. The PR itself was only a
> proposal, after all.
>
> Therefore I’m wondering — is it legal to copy code from PRs that
> were open before the license change? Are those PRs actually licensed as
> ASL-2?
>
> If yes, well, let’s copy them all, I’m sure there are gems in there.
> But my hunch is that there are issues with it, and I’d really like to
> know the answer to this conundrum, as copyright law is really confusing
> for me.
>
> And does the ASF have some legal expertise available, such that we can
> settle these matters?
>
> On 3 Nov 2022, at 22:54, Greg Methvin wrote:
>
> > My understanding is that the Lightbend CLA only gives Lightbend a
> > license
> > to use and redistribute the code; it doesn't transfer copyright. Where
> > it
> > gets tricky is that many PRs can incorporate parts of the existing
> > code in
> > various ways, so are effectively a derivative work rather than being
> > totally original, and you're on shaky ground unless you can prove that
> > the
> > code it's based on is entirely ASL licensed. But like you said, the
> > commit
> > it's based on is entirely ASL licensed code so there is no issue.
> >
> > On Thu, Nov 3, 2022 at 10:50 AM Jean-Luc Deprez
> > <Je...@gmail.com>
> > wrote:
> >
> >> Fact that Johannes authored most of the work wouldn't matter much, as
> >> I'd
> >> guess copyright transfer would be in place.
> >>
> >> But what Johannes stated doing is the legal ground. A git commit is a
> >> copy
> >> of the source, if that copy contains the ASL license instead of the
> >> BSL,
> >> the ASL terms apply. So the last commit on branch before BSL merge is
> >> safe.
> >>
> >> Which is the legal ground for this whole endeavor anyway.
> >>
> >>
> >>
> >>
> >> On Thu, Nov 3, 2022, 12:44 PJ Fanning <fa...@gmail.com> wrote:
> >>
> >>> The original PR was created before the license was changed. I think
> >>> it
> >>> should be safe to take into pekko-http, especially since Johannes
> >>> who
> >>> wrote the original PR is and is offering to help with getting it
> >>> into
> >>> pekko-http.
> >>>
> >>> On Thu, 3 Nov 2022 at 12:29, Alexandru Nedelcu <al...@apache.org>
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I’m resending this message from the “right” email address
> >>>> 🙂
> >>>> sorry for the duplicate…
> >>>>
> >>>> On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
> >>>>> (Obviously, we should use the state of the scala-3 branch before
> >>>>> the
> >>>>> license change. Afterwards, a merge from main was added containing
> >> the
> >>>>> license change.)
> >>>>
> >>>> It would be great to merge that scala-3 branch. I think Akka-HTTP
> >>>> is
> >>>> what’s keeping us at $work from migrating to Scala 3 (plus other
> >>>> annoyances, but this is the big one).
> >>>>
> >>>> However — I’d ask if we are allowed.
> >>>>
> >>>> I am not a lawyer. Does code in that PR represent code that’s
> >>>> released
> >>>> under APL-2.0? My hunch is that there may be issues with this.
> >>>>
> >>>> I think we should ask someone with legal expertise if we are
> >>>> allowed.
> >>>> Can ASF help?
> >>>>
> >>>> --
> >>>> Alexandru Nedelcu
> >>>> https://alexn.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >>> For additional commands, e-mail: dev-help@pekko.apache.org
> >>>
> >>>
> >>
>
>
> --
> Alexandru Nedelcu
> https://alexn.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: Pekko-HTTP approach
Posted by Greg Methvin <gr...@apache.org>.
> Therefore I’m wondering — is it legal to copy code from PRs that
were open before the license change? Are those PRs actually licensed as
ASL-2?
The ASL2 suggests the answer is yes:
> 5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work by You
to the Licensor shall be under the terms and conditions of this License,
without any additional terms or conditions. Notwithstanding the above,
nothing herein shall supersede or modify the terms of any separate license
agreement you may have executed with Licensor regarding such Contributions.
This implies that it should be safe to copy any existing Akka pull requests
and merge them into Pekko, but it would be good to get someone from Apache
legal to confirm.
On Fri, Nov 4, 2022 at 1:44 AM Alexandru Nedelcu <al...@apache.org>
wrote:
> Lightbend’s CLA doesn’t transfer the copyright, but what it does is
> it allows Lightbend to “sublicense” it as proprietary, which I guess
> (IANAL, etc) is why they can legally change the license in their
> repository without mentioning that some of that code is still available
> as ASL-2.
>
> If Johannes is the author of that PR, it’s a big deal, because he
> still owns the copyright for his work. This case, as far as I’m
> concerned, is closed.
>
> My objection was about PRs in general — if a PR was made, that
> doesn’t mean that the contribution was licensed under ASL-2, just
> because the repository’s LICENSE was indicating ASL-2 at that time.
>
> Consider the situation in which (royal) you made a PR to Akka when it
> was licensed as ASL-2, but it gets rejected for whatever reason.
> That’s life, and you move on. Well, what happens if Lightbend copies
> the code in that rejected PR, after the license changed? The original PR
> was rejected, it was never “distributed”, you never agreed to the
> merge, because the merge never happened. The PR itself was only a
> proposal, after all.
>
> Therefore I’m wondering — is it legal to copy code from PRs that
> were open before the license change? Are those PRs actually licensed as
> ASL-2?
>
> If yes, well, let’s copy them all, I’m sure there are gems in there.
> But my hunch is that there are issues with it, and I’d really like to
> know the answer to this conundrum, as copyright law is really confusing
> for me.
>
> And does the ASF have some legal expertise available, such that we can
> settle these matters?
>
> On 3 Nov 2022, at 22:54, Greg Methvin wrote:
>
> > My understanding is that the Lightbend CLA only gives Lightbend a
> > license
> > to use and redistribute the code; it doesn't transfer copyright. Where
> > it
> > gets tricky is that many PRs can incorporate parts of the existing
> > code in
> > various ways, so are effectively a derivative work rather than being
> > totally original, and you're on shaky ground unless you can prove that
> > the
> > code it's based on is entirely ASL licensed. But like you said, the
> > commit
> > it's based on is entirely ASL licensed code so there is no issue.
> >
> > On Thu, Nov 3, 2022 at 10:50 AM Jean-Luc Deprez
> > <Je...@gmail.com>
> > wrote:
> >
> >> Fact that Johannes authored most of the work wouldn't matter much, as
> >> I'd
> >> guess copyright transfer would be in place.
> >>
> >> But what Johannes stated doing is the legal ground. A git commit is a
> >> copy
> >> of the source, if that copy contains the ASL license instead of the
> >> BSL,
> >> the ASL terms apply. So the last commit on branch before BSL merge is
> >> safe.
> >>
> >> Which is the legal ground for this whole endeavor anyway.
> >>
> >>
> >>
> >>
> >> On Thu, Nov 3, 2022, 12:44 PJ Fanning <fa...@gmail.com> wrote:
> >>
> >>> The original PR was created before the license was changed. I think
> >>> it
> >>> should be safe to take into pekko-http, especially since Johannes
> >>> who
> >>> wrote the original PR is and is offering to help with getting it
> >>> into
> >>> pekko-http.
> >>>
> >>> On Thu, 3 Nov 2022 at 12:29, Alexandru Nedelcu <al...@apache.org>
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I’m resending this message from the “right” email address
> >>>> 🙂
> >>>> sorry for the duplicate…
> >>>>
> >>>> On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
> >>>>> (Obviously, we should use the state of the scala-3 branch before
> >>>>> the
> >>>>> license change. Afterwards, a merge from main was added containing
> >> the
> >>>>> license change.)
> >>>>
> >>>> It would be great to merge that scala-3 branch. I think Akka-HTTP
> >>>> is
> >>>> what’s keeping us at $work from migrating to Scala 3 (plus other
> >>>> annoyances, but this is the big one).
> >>>>
> >>>> However — I’d ask if we are allowed.
> >>>>
> >>>> I am not a lawyer. Does code in that PR represent code that’s
> >>>> released
> >>>> under APL-2.0? My hunch is that there may be issues with this.
> >>>>
> >>>> I think we should ask someone with legal expertise if we are
> >>>> allowed.
> >>>> Can ASF help?
> >>>>
> >>>> --
> >>>> Alexandru Nedelcu
> >>>> https://alexn.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >>> For additional commands, e-mail: dev-help@pekko.apache.org
> >>>
> >>>
> >>
>
>
> --
> Alexandru Nedelcu
> https://alexn.org
>
Re: Pekko-HTTP approach
Posted by Alexandru Nedelcu <al...@apache.org>.
Lightbend’s CLA doesn’t transfer the copyright, but what it does is
it allows Lightbend to “sublicense” it as proprietary, which I guess
(IANAL, etc) is why they can legally change the license in their
repository without mentioning that some of that code is still available
as ASL-2.
If Johannes is the author of that PR, it’s a big deal, because he
still owns the copyright for his work. This case, as far as I’m
concerned, is closed.
My objection was about PRs in general — if a PR was made, that
doesn’t mean that the contribution was licensed under ASL-2, just
because the repository’s LICENSE was indicating ASL-2 at that time.
Consider the situation in which (royal) you made a PR to Akka when it
was licensed as ASL-2, but it gets rejected for whatever reason.
That’s life, and you move on. Well, what happens if Lightbend copies
the code in that rejected PR, after the license changed? The original PR
was rejected, it was never “distributed”, you never agreed to the
merge, because the merge never happened. The PR itself was only a
proposal, after all.
Therefore I’m wondering — is it legal to copy code from PRs that
were open before the license change? Are those PRs actually licensed as
ASL-2?
If yes, well, let’s copy them all, I’m sure there are gems in there.
But my hunch is that there are issues with it, and I’d really like to
know the answer to this conundrum, as copyright law is really confusing
for me.
And does the ASF have some legal expertise available, such that we can
settle these matters?
On 3 Nov 2022, at 22:54, Greg Methvin wrote:
> My understanding is that the Lightbend CLA only gives Lightbend a
> license
> to use and redistribute the code; it doesn't transfer copyright. Where
> it
> gets tricky is that many PRs can incorporate parts of the existing
> code in
> various ways, so are effectively a derivative work rather than being
> totally original, and you're on shaky ground unless you can prove that
> the
> code it's based on is entirely ASL licensed. But like you said, the
> commit
> it's based on is entirely ASL licensed code so there is no issue.
>
> On Thu, Nov 3, 2022 at 10:50 AM Jean-Luc Deprez
> <Je...@gmail.com>
> wrote:
>
>> Fact that Johannes authored most of the work wouldn't matter much, as
>> I'd
>> guess copyright transfer would be in place.
>>
>> But what Johannes stated doing is the legal ground. A git commit is a
>> copy
>> of the source, if that copy contains the ASL license instead of the
>> BSL,
>> the ASL terms apply. So the last commit on branch before BSL merge is
>> safe.
>>
>> Which is the legal ground for this whole endeavor anyway.
>>
>>
>>
>>
>> On Thu, Nov 3, 2022, 12:44 PJ Fanning <fa...@gmail.com> wrote:
>>
>>> The original PR was created before the license was changed. I think
>>> it
>>> should be safe to take into pekko-http, especially since Johannes
>>> who
>>> wrote the original PR is and is offering to help with getting it
>>> into
>>> pekko-http.
>>>
>>> On Thu, 3 Nov 2022 at 12:29, Alexandru Nedelcu <al...@apache.org>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I’m resending this message from the “right” email address
>>>> 🙂
>>>> sorry for the duplicate…
>>>>
>>>> On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
>>>>> (Obviously, we should use the state of the scala-3 branch before
>>>>> the
>>>>> license change. Afterwards, a merge from main was added containing
>> the
>>>>> license change.)
>>>>
>>>> It would be great to merge that scala-3 branch. I think Akka-HTTP
>>>> is
>>>> what’s keeping us at $work from migrating to Scala 3 (plus other
>>>> annoyances, but this is the big one).
>>>>
>>>> However — I’d ask if we are allowed.
>>>>
>>>> I am not a lawyer. Does code in that PR represent code that’s
>>>> released
>>>> under APL-2.0? My hunch is that there may be issues with this.
>>>>
>>>> I think we should ask someone with legal expertise if we are
>>>> allowed.
>>>> Can ASF help?
>>>>
>>>> --
>>>> Alexandru Nedelcu
>>>> https://alexn.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>>> For additional commands, e-mail: dev-help@pekko.apache.org
>>>
>>>
>>
--
Alexandru Nedelcu
https://alexn.org
Re: Pekko-HTTP approach
Posted by Alexandru Nedelcu <ap...@a.alexn.org>.
Lightbend’s CLA doesn’t transfer the copyright, but what it does is
it allows Lightbend to “sublicense” it as proprietary, which I guess
(IANAL, etc) is why they can legally change the license in their
repository without mentioning that some of that code is still available
as ASL-2.
If Johannes is the author of that PR, it’s a big deal, because he
still owns the copyright for his work. This case, as far as I’m
concerned, is closed.
My objection was about PRs in general — if a PR was made, that
doesn’t mean that the contribution was licensed under ASL-2, just
because the repository’s LICENSE was indicating ASL-2 at that time.
Consider the situation in which (royal) you made a PR to Akka when it
was licensed as ASL-2, but it gets rejected for whatever reason.
That’s life, and you move on. Well, what happens if Lightbend copies
the code in that rejected PR, after the license changed? The original PR
was rejected, it was never “distributed”, you never agreed to the
merge, because the merge never happened. The PR itself was only a
proposal, after all.
Therefore I’m wondering — is it legal to copy code from PRs that
were open before the license change? Are those PRs actually licensed as
ASL-2?
If yes, well, let’s copy them all, I’m sure there are gems in there.
But my hunch is that there are issues with it, and I’d really like to
know the answer to this conundrum, as copyright law is really confusing
for me.
And does the ASF have some legal expertise available, such that we can
settle these matters?
On 3 Nov 2022, at 22:54, Greg Methvin wrote:
> My understanding is that the Lightbend CLA only gives Lightbend a
> license
> to use and redistribute the code; it doesn't transfer copyright. Where
> it
> gets tricky is that many PRs can incorporate parts of the existing
> code in
> various ways, so are effectively a derivative work rather than being
> totally original, and you're on shaky ground unless you can prove that
> the
> code it's based on is entirely ASL licensed. But like you said, the
> commit
> it's based on is entirely ASL licensed code so there is no issue.
>
> On Thu, Nov 3, 2022 at 10:50 AM Jean-Luc Deprez
> <Je...@gmail.com>
> wrote:
>
>> Fact that Johannes authored most of the work wouldn't matter much, as
>> I'd
>> guess copyright transfer would be in place.
>>
>> But what Johannes stated doing is the legal ground. A git commit is a
>> copy
>> of the source, if that copy contains the ASL license instead of the
>> BSL,
>> the ASL terms apply. So the last commit on branch before BSL merge is
>> safe.
>>
>> Which is the legal ground for this whole endeavor anyway.
>>
>>
>>
>>
>> On Thu, Nov 3, 2022, 12:44 PJ Fanning <fa...@gmail.com> wrote:
>>
>>> The original PR was created before the license was changed. I think
>>> it
>>> should be safe to take into pekko-http, especially since Johannes
>>> who
>>> wrote the original PR is and is offering to help with getting it
>>> into
>>> pekko-http.
>>>
>>> On Thu, 3 Nov 2022 at 12:29, Alexandru Nedelcu <al...@apache.org>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I’m resending this message from the “right” email address
>>>> 🙂
>>>> sorry for the duplicate…
>>>>
>>>> On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
>>>>> (Obviously, we should use the state of the scala-3 branch before
>>>>> the
>>>>> license change. Afterwards, a merge from main was added containing
>> the
>>>>> license change.)
>>>>
>>>> It would be great to merge that scala-3 branch. I think Akka-HTTP
>>>> is
>>>> what’s keeping us at $work from migrating to Scala 3 (plus other
>>>> annoyances, but this is the big one).
>>>>
>>>> However — I’d ask if we are allowed.
>>>>
>>>> I am not a lawyer. Does code in that PR represent code that’s
>>>> released
>>>> under APL-2.0? My hunch is that there may be issues with this.
>>>>
>>>> I think we should ask someone with legal expertise if we are
>>>> allowed.
>>>> Can ASF help?
>>>>
>>>> --
>>>> Alexandru Nedelcu
>>>> https://alexn.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>>> For additional commands, e-mail: dev-help@pekko.apache.org
>>>
>>>
>>
--
Alexandru Nedelcu
https://alexn.org
Re: Pekko-HTTP approach
Posted by Greg Methvin <gr...@apache.org>.
My understanding is that the Lightbend CLA only gives Lightbend a license
to use and redistribute the code; it doesn't transfer copyright. Where it
gets tricky is that many PRs can incorporate parts of the existing code in
various ways, so are effectively a derivative work rather than being
totally original, and you're on shaky ground unless you can prove that the
code it's based on is entirely ASL licensed. But like you said, the commit
it's based on is entirely ASL licensed code so there is no issue.
On Thu, Nov 3, 2022 at 10:50 AM Jean-Luc Deprez <Je...@gmail.com>
wrote:
> Fact that Johannes authored most of the work wouldn't matter much, as I'd
> guess copyright transfer would be in place.
>
> But what Johannes stated doing is the legal ground. A git commit is a copy
> of the source, if that copy contains the ASL license instead of the BSL,
> the ASL terms apply. So the last commit on branch before BSL merge is safe.
>
> Which is the legal ground for this whole endeavor anyway.
>
>
>
>
> On Thu, Nov 3, 2022, 12:44 PJ Fanning <fa...@gmail.com> wrote:
>
> > The original PR was created before the license was changed. I think it
> > should be safe to take into pekko-http, especially since Johannes who
> > wrote the original PR is and is offering to help with getting it into
> > pekko-http.
> >
> > On Thu, 3 Nov 2022 at 12:29, Alexandru Nedelcu <al...@apache.org>
> > wrote:
> > >
> > > Hi,
> > >
> > > I’m resending this message from the “right” email address 🙂
> > > sorry for the duplicate…
> > >
> > > On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
> > > > (Obviously, we should use the state of the scala-3 branch before the
> > > > license change. Afterwards, a merge from main was added containing
> the
> > > > license change.)
> > >
> > > It would be great to merge that scala-3 branch. I think Akka-HTTP is
> > > what’s keeping us at $work from migrating to Scala 3 (plus other
> > > annoyances, but this is the big one).
> > >
> > > However — I’d ask if we are allowed.
> > >
> > > I am not a lawyer. Does code in that PR represent code that’s released
> > > under APL-2.0? My hunch is that there may be issues with this.
> > >
> > > I think we should ask someone with legal expertise if we are allowed.
> > > Can ASF help?
> > >
> > > --
> > > Alexandru Nedelcu
> > > https://alexn.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
Re: Pekko-HTTP approach
Posted by Jean-Luc Deprez <Je...@gmail.com>.
Fact that Johannes authored most of the work wouldn't matter much, as I'd
guess copyright transfer would be in place.
But what Johannes stated doing is the legal ground. A git commit is a copy
of the source, if that copy contains the ASL license instead of the BSL,
the ASL terms apply. So the last commit on branch before BSL merge is safe.
Which is the legal ground for this whole endeavor anyway.
On Thu, Nov 3, 2022, 12:44 PJ Fanning <fa...@gmail.com> wrote:
> The original PR was created before the license was changed. I think it
> should be safe to take into pekko-http, especially since Johannes who
> wrote the original PR is and is offering to help with getting it into
> pekko-http.
>
> On Thu, 3 Nov 2022 at 12:29, Alexandru Nedelcu <al...@apache.org>
> wrote:
> >
> > Hi,
> >
> > I’m resending this message from the “right” email address 🙂
> > sorry for the duplicate…
> >
> > On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
> > > (Obviously, we should use the state of the scala-3 branch before the
> > > license change. Afterwards, a merge from main was added containing the
> > > license change.)
> >
> > It would be great to merge that scala-3 branch. I think Akka-HTTP is
> > what’s keeping us at $work from migrating to Scala 3 (plus other
> > annoyances, but this is the big one).
> >
> > However — I’d ask if we are allowed.
> >
> > I am not a lawyer. Does code in that PR represent code that’s released
> > under APL-2.0? My hunch is that there may be issues with this.
> >
> > I think we should ask someone with legal expertise if we are allowed.
> > Can ASF help?
> >
> > --
> > Alexandru Nedelcu
> > https://alexn.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
Re: Pekko-HTTP approach
Posted by Alexandru Nedelcu <ap...@a.alexn.org>.
On 3 Nov 2022, at 13:44, PJ Fanning wrote:
> The original PR was created before the license was changed. I think it
> should be safe to take into pekko-http, especially since Johannes who
> wrote the original PR is and is offering to help with getting it into
> pekko-http.
Ah, I missed that Johannes is the original author of that PR.
That’s awesome ❤️
--
Alexandru Nedelcu
https://alexn.org
Re: Pekko-HTTP approach
Posted by PJ Fanning <fa...@gmail.com>.
The original PR was created before the license was changed. I think it
should be safe to take into pekko-http, especially since Johannes who
wrote the original PR is and is offering to help with getting it into
pekko-http.
On Thu, 3 Nov 2022 at 12:29, Alexandru Nedelcu <al...@apache.org> wrote:
>
> Hi,
>
> I’m resending this message from the “right” email address 🙂
> sorry for the duplicate…
>
> On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
> > (Obviously, we should use the state of the scala-3 branch before the
> > license change. Afterwards, a merge from main was added containing the
> > license change.)
>
> It would be great to merge that scala-3 branch. I think Akka-HTTP is
> what’s keeping us at $work from migrating to Scala 3 (plus other
> annoyances, but this is the big one).
>
> However — I’d ask if we are allowed.
>
> I am not a lawyer. Does code in that PR represent code that’s released
> under APL-2.0? My hunch is that there may be issues with this.
>
> I think we should ask someone with legal expertise if we are allowed.
> Can ASF help?
>
> --
> Alexandru Nedelcu
> https://alexn.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: Pekko-HTTP approach
Posted by Alexandru Nedelcu <al...@apache.org>.
Hi,
I’m resending this message from the “right” email address 🙂
sorry for the duplicate…
On 3 Nov 2022, at 12:07, Johannes Rudolph wrote:
> (Obviously, we should use the state of the scala-3 branch before the
> license change. Afterwards, a merge from main was added containing the
> license change.)
It would be great to merge that scala-3 branch. I think Akka-HTTP is
what’s keeping us at $work from migrating to Scala 3 (plus other
annoyances, but this is the big one).
However — I’d ask if we are allowed.
I am not a lawyer. Does code in that PR represent code that’s released
under APL-2.0? My hunch is that there may be issues with this.
I think we should ask someone with legal expertise if we are allowed.
Can ASF help?
--
Alexandru Nedelcu
https://alexn.org
Re: Pekko-HTTP approach
Posted by Matthew Benedict de Detrich <ma...@aiven.io.INVALID>.
So I believe the general community agreement is that the first release of
Pekko and any of its modules is the minimum necessary changes to get it
released (ideally this is just change of packages but for the Pekko core
project this is not so trivial as we have seen).
Then there is going to be another release (with a bumped major version)
where changes go in as long as they don't break backwards compatibility. I
am not sure if the Scala3 changes for akka-http broke binary compatibility,
but if they didn't then even if the changes are disruptive to the source
code I don't see this being problematic for such a release.
On Thu, Nov 3, 2022 at 11:08 AM Johannes Rudolph <jo...@gmail.com>
wrote:
> Hi,
>
> for pekko-http, we need to think about how to approach the first few
> changes. We should do:
>
> * integrate the Scala 3 branch that was not yet released
> * move from scalariform to scalafmt
> * new package names
>
> Originally, the Scala 3 branch was not yet merged (and therefore
> missed 10.2.10) because it does not mix all to well with Scala 2.12
> support. It works but it requires some hacky patching of source files
> to remove some code that cannot be compiled on all targets (we tried
> to avoid version-dependent source files especially here since it
> touches the biggest source file, headers.scala, and we have had many
> bad experiences with bugs in versioned forks of source files).
>
> At this point I would probably just merge the existing Scala 3 branch
> to ensure this work is not lost even if it adds complexity to the
> build. The hope would be that we might be able to drop Scala 2.12 soon
> after the first release to clean things up.
>
> In general, it goes somewhat against the goal of not adding any
> changes in the first version of pekko but doing the merge later on
> will be quite painful.
>
> If you agree, we should try to do the changes in the order as shown above.
>
> (Obviously, we should use the state of the scala-3 branch before the
> license change. Afterwards, a merge from main was added containing the
> license change.)
>
> WDYT?
> 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