You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[...] 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:
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 .
The text was updated successfully, but these errors were encountered:
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.
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)
In this case,
gethrpc
code is used all throughout theclient/
andrpc/
modules (arguably the main part of this repository), including in core places likeclient/client.go
, the de-facto entrypoint for that part of the library, where gethrpc is used with no alternative in sight:go-substrate-rpc-client/client/client.go
Lines 45 to 46 in 4a65293
As such, the current Apache 2.0 license in
LICENSE
(and inclient.go
) is misleading (if not an outright violation of GPLv3), because no matter how one uses theclient
part of this library, they would end up having to comply with the provisions of GPLv3 fromgethrpc
Ideas:
If it is intended that the whole repository is a derivative work of
gethrpc
/go-ethereum
'srpc
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 thegethrpc.Client
interface without looking atgethrpc
code, since I'd prefer my project that usesgo-substrate-rpc-client
to remain non-GPLv3.)And finally, if it is intended that code inside
client/
andrpc/
is under the GPLv3 license while the rest of the library (likescale/
andregistry/
) 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 inREADME.md
.The text was updated successfully, but these errors were encountered: