docs: update LICENSE to GPL-2.0

[arxanas]

The GPL-2.0 license is so that we can use the code at https://github.com/quark-zju/gitrevset and its underlying implementation.

@waych Since you are the only other contributor to the project so far, I would need you to agree to license your contributions under the GPL-2.0 license as well. Is this okay with you?

[waych]

I'm definitely okay with you re-licensing, especially considering you wrote the bulk.

That said, I don't know if it makes sense to dual license apache-2.0 and gpl-2.0, does it? Shouldn't it be sufficient to license core as apache-2.0 and license the modules in question as gpl-2.0?

This part:

The entirety of the source code for `git-branchless` is additionally available
under the GPL-2 license. Executables compiled from that source code are also
licensed under GPL-2.

seems to imply that it isn't possible to use git-branchless under apache-2.0 terms ("that source code"?). Maybe it is clearer if you s/additionally/alternatively/?

Either way, to make it easier for you, consider this message a transfer of copyright ownership for the patches I've submitted so far, as if under CLA terms: ⭐🎁⭐

[arxanas]

Thank you for your sign-off :). Again, I appreciate your contributions to the project!

In this case, I want to swap out the mergebase module and some of the graph for an implementation based on the GPL'ed library. These are fairly critical components, and git-branchless couldn't function without them.

As a result, I'm pretty sure the aggregate work and its resulting executables must be licensed under the GPL, according the terms of the GPL. So yes, I think it won't be possible to use git-branchless as a whole under Apache 2.0. In practice, I don't think having a GPL executable is a problem for end-users, the same as how GCC is fine for end-users.

Maybe it would be clearer to say that the whole work is licensed under the GPL, and additionally, most of the modules are licensed under Apache 2.0?

The point of retaining the Apache 2.0 license is in case somebody wants to either 1) use some of the unrelated modules standalone (i.e. the implementation of commit evolution), or 2) create a non-GPL version by only swapping out the GPL-ed modules, rather than having to reimplement the entire thing.

I personally don't want to maintain a non-GPL implementation of the libraries in question, because some of the operations are actually pretty tricky to implement by hand, especially in a performant way. My implementations are slow in some cases, and probably buggy. I know for certain that they don't handle multi-parent commits well.

[waych]

On Sun, Aug 1, 2021 at 5:35 PM Waleed Khan ***@***.***> wrote: Thank you for your sign-off :). Again, I appreciate your contributions to the project! In this case, I want to swap out the mergebase module and some of the graph for an implementation based on the GPL'ed library. These are fairly critical components, and git-branchless couldn't function without them. As a result, I'm pretty sure the aggregate work and its resulting executables must be licensed under the GPL, according the terms of the GPL. So yes, I think it won't be possible to use git-branchless as a whole under Apache 2.0. In practice, I don't think having a GPL executable is a problem for end-users, the same as how GCC is fine for end-users. Maybe it would be clearer to say that the whole work is licensed under the GPL, and additionally, most of the modules are licensed under Apache 2.0?

If "modules" here refers to rust `mod` and `.rs` files, I don't think that is a good mode of operation, as you really want to define a clear interface separation that delineates which parts are licensed how, on either side of the interface. This makes issues like refactors less of a problem and also proposes the interface that allows the backend library to be easily replaced with a perhap differently licensed codebase. In Rust I think that is better described at the crate boundary. It makes more sense to say: this crate is apache-2.0 licensed, and currently has gpl-2.0 dependencies, hence binary derivatives requiring to be promoted to GPL 2.0 requirements if distributed assuming those dependencies are still there. That assumes the dependency is kept seperate. If you intend to fold in the external dependency into this crate I think that makes the crate gpl-2.0 tainted, restricting the ability to distribute the source as apache-2.0.

The point of retaining the Apache 2.0 license is in case somebody wants to either 1) use some of the unrelated modules standalone (i.e. the implementation of commit evolution), or 2) create a non-GPL version by only swapping out the GPL-ed modules, rather than having to reimplement the entire thing.

To achieve #2 I think all code that uses or incorporates the GPL code needs to live in its own GPL-2.0 licensed crate, and you make the main project depend on that optionally.

I personally don't want to maintain a non-GPL implementation of the libraries in question, because some of the operations are actually pretty tricky to implement by hand, especially in a performant way. My implementations are slow in some cases, and probably buggy. I know for certain that they don't handle multi-parent commits well.

It would still be worthwhile to chuck your existing code into the "alternative" backend that is apache-2.0 licensed, even if it doesn't work. Someone will be bound to take a stab at it if the "there is value in keeping git-branchless apache-2.0 distributable" argument holds. It also lends credence to the fact whether git-branchless is derivative or just taking on a build time dependency. Again, IANAL.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC4ZY5DNAS3SB6AWM2NJOLT2XR5VANCNFSM5BLP44MA> .

[arxanas]

Thanks for your comment. I think you're probably right, and I would have to separate the code into two crates, which seems like a headache. Looking through the codebase, I think it's unlikely that one would want to extract some functionality into a library. Besides that, it's probably more in the spirit of Mercurial and its descendant technologies to license it under the GPL. I think I'll just use the GPL license.