Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

License violation / incorrect license? #362

Open
bojidar-bg opened this issue Oct 11, 2023 · 1 comment
Open

License violation / incorrect license? #362

bojidar-bg opened this issue Oct 11, 2023 · 1 comment

Comments

@bojidar-bg
Copy link

Background:

Code in gethrpc/ is licensed under the GPLv3 license, both here in this repository, and in the go-ethereum repository where it was taken from.

However, the rest of the code in this repository is licensed under the Apache 2.0 License, ever since 5175567.

Problem:

I'm not a lawyer, but this seems to be legally in the wrong. Quoting Apache Foundation's page about the Apache 2.0 License's compatibility with the GPL: (emphasis mine)

[...] However, GPLv3 software cannot be included in Apache projects. [...] This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0.
We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. [...]

In this case, gethrpc code is used all throughout the client/ and rpc/ modules (arguably the main part of this repository), including in core places like client/client.go, the de-facto entrypoint for that part of the library, where gethrpc is used with no alternative in sight:

type client struct {
gethrpc.Client

As such, the current Apache 2.0 license in LICENSE (and in client.go) is misleading (if not an outright violation of GPLv3), because no matter how one uses the client part of this library, they would end up having to comply with the provisions of GPLv3 from gethrpc

Ideas:

If it is intended that the whole repository is a derivative work of gethrpc / go-ethereum's rpc module, 5175567 should be reverted, and the GPLv3 license reinstated.

If it instead intended that the whole repository is under the Apache 2.0 license, the gethrpc implementation used should be replaced with an appropriately-licensed alternative. (If it would help, I'd be willing to contribute a reimplementation of the gethrpc.Client interface without looking at gethrpc code, since I'd prefer my project that uses go-substrate-rpc-client to remain non-GPLv3.)

And finally, if it is intended that code inside client/ and rpc/ is under the GPLv3 license while the rest of the library (like scale/ and registry/) remain under the Apache 2.0 license, this should be clarified with an extra LICENSE/COPYING file, fixing the headers of the impacted files, and probably a note about it in README.md .

@cdamian
Copy link
Contributor

cdamian commented Oct 12, 2023

Thank you for pointing this out - it seems that most of this was caused by bad dependency management when the geth-related logic was added. We'll have an internal discussion on how we will address this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants