go-ethereum license violation

[karalabe]

Hello,

This repository is violating our software licenses. The go-ethereum code is licensed under LGPLv3 and you have no permission to relicense it under MIT. Without such permission, you cannot include it in an MIT project. Please either delete all copyrighted material originating from our codebase or update the license of your entire project LGPLv3.

Thanks,
Peter

[karalabe]

Just as a followup clarification. LGPL allows you to dynamically link at runtime a project into a proprietary system, but it forbids static linking (which the Go builder does). Your third option is to do what ava-labs did with avalanchego and keep the go-ethereum codebase you need as a separate repository and make it into a Go plugin loaded on startup.

[stefantalpalaru]

LGPL allows you to dynamically link at runtime a project into a proprietary system, but it forbids static linking (which the Go builder does).

This is wrong. From https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic :

"If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application."

Always make sure you fully understand your license before accusing people of infringing it.

[zmanian]

Reverse engineering the intent of the go-ethereum authors from the license is difficult.

Go-ethereum chose the LPGL in 2015. Go-plugins were introduced in 2016. It's not plausible that the original intention of the go-ethereum authors was for the plugin system to be mechanism to use the go-ethereum code without invoking copy-left obligations.

The go-ethereum authors were also clearly aware of the go compilation model when they chose the LGPL. They could have chosen to GPL the entire code base.

This statement indicates that intent was to enable usage of go-ethereum as a dependency of other go programs.

[ligi]

from that statement:

... LGPL forces those that modify the code and use it to contribute back to original authors. For example if someone forks go-ethereum change it for the better they actually have to contribute back. ...

Copying LGPL code into your MIT codebase does not respect that intent and IMHO also violates the license (but IANAL)

[kool19822]

Well is it or is it not GNU or are we just changing things up to fit the bill at any given time that we deem fit? I think users here need a solid reply as to what is going on here and how or what to come to an agreement on this topic, but lets not go changing things up on a whim.

[kool19822]

Peter care to reply as its obviously unclear to most people here what you are raging about. Maybe the lawyer should take a look first before making said claims about license violations if your statement is found untrue then I think you may owe a public apology since you slammed this out in public, but if not then yes they should fix whatever the fuss is about that would sound fair to me or however, you two decide on how to deal with this. I will now C my way out of this topic but wanted to help maybe provide some clarity to people who are following this topic.

[kool19822]

I took the time to read LGPLV3 and I don't see a clear volition at all Peter this makes no sense because of the first reply

LGPL allows you to dynamically link at runtime a project into a proprietary system, but it forbids static linking (which the Go builder does).

This is wrong. From https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic :

That solves this issue and this ticket should be closed and Peter a public reply would be warranted if this for some reason or another is incorrect if not I would assume there is no issue.

There is no volition whatsoever that I can see anyways and feel that Peter has jumped the gun on this or put the cart before the horse.

Peter, I suggest you reread that information yourself and you too will clearly see no such volition is warranted.

[ebuchman]

Just a note, it seems this isn't just about statically linking an LGPL library, which in my understanding can be done legitimately under other open source licenses (though IANAL). The challenge here I believe is that Harmony copied and modified the LGPL code into this repo. They do preserve the original LGPL license on those files but the repo itself claims to be licensed MIT. 🤷

[kool19822]

Just a note, it seems this isn't just about statically linking an LGPL library, which in my understanding can be done legitimately under other open source licenses (though IANAL). The challenge here I believe is that Harmony copied and modified the LGPL code into this repo. They do preserve the original LGPL license on those files but the repo itself claims to be licensed MIT. 🤷

MIT License
A short and simple permissive license with conditions only requiring preservation of copyright and license notices. Licensed works, modifications, and larger works may be distributed under different terms and without source code

Even if so which I clearly do not see it couldn't different terms include different Licenses such as the LGPLV3 and keep somethings MIT without affecting it?

I guess it comes down to ones interpretation into what is correct and whats not because under Different terms is a broad statement and could very well include somethings being MIT and some things because the LGPL.

[kool19822]

I found this topic talked about here already and it looks like I'm right you can have the files LGPL and use MIT

https://opensource.stackexchange.com/questions/6405/lgpl-licensed-code-reuse-in-mit-licensed-project

Granted I'm not a lawyer or anything but I think this is simply a closed issue.

[ebuchman]

The question is whether one can license software under MIT when it contains modified LGPL code. I don't know the answer, but I think not, and I wouldn't be so quick to doubt/dismiss @karalabe on the matter, especially given he is a major copyright holder of the work in question.

The link you reference actually seems to me to conclude similarly.

That said it may be as simple as the LICENSE file in the repo indicating that all files are licensed MIT unless otherwise noted, in which case the go-eth files do contain the LGPL license in the header already. But it sounds like at some point a lawyer should provide a definite opinion ...

[karalabe]

@stefantalpalaru You seem to have mixed up a few things though. The issue is not placing LGPL code into another codebase, the issue is releasing the derivative codebase under a more permissive license.

This repository is under the MIT license:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software [...] to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell [...], and to permit persons to whom the Software is furnished to do so

Per the license text, anyone can do whatever they want with code in this repository, which is false. The moment you include LGPL code in here, you are not allowed to have MIT on the repository, because anyone obtaining the code still has to adhere to the embedded LPGL, hence it's not MIT any more.

The problem is not embedding the code, the problem is relicensing it under MIT, per what this repository did.

[kool19822]

@stefantalpalaru You seem to have mixed up a few things though. The issue is not placing LGPL code into another codebase, the issue is releasing the derivative codebase under a more permissive license.

This repository is under the MIT license:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software [...] to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell [...], and to permit persons to whom the Software is furnished to do so

Per the license text, anyone can do whatever they want with code in this repository, which is false. The moment you include LGPL code in here, you are not allowed to have MIT on the repository, because anyone obtaining the code still has to adhere to the embedded LPGL, hence it's not MIT any more.

The problem is not embedding the code, the problem is relicensing it under MIT, per what this repository did.

So you are saying the license text is wrong but then why would it be written like that? Lots of questions here

Is there any case studies that you can link too showing that the description is false as you stated? I don't mean to be a pain about this but as far as I can see there is nothing wrong here.

[kool19822]

I think its best they work this out either with a lawyer or some other kind of resolution. Who are we to interpret the law. I'd just reach out to them and make a call and see what they say about it. I'm sure you big wigs got them on speed dial and pending on what they say either leave it or change it and let that be that.

[karalabe]

I'm not following. The MIT license allows you to do something the LGPL does not. Both licenses are fine, but they are incompatible (the former is laxer than the latter).

If you embed LGPL code into the repository, you can't release the entire repository any more under MIT, because you do not have the ownership right to change the license of the LGPL code.

MIT does not have a notion of "everything is permitted, except for these X files".

[karalabe]

@kool19822 Please stop spamming the issue, I'm not interested in your attempts to derail this discussion.

[ineffectualproperty]

I'm inclined to agree @karalabe here. There are a number of issues here but as he calls out, you have a blanket MIT license in the root directory implying that the library is MIT when it is clearly not. Furthermore, LGPL explicitly calls out that the LGPL license must be included in combined works - "Accompany the Combined Work with a copy of the GNU GPL and this license document.". If you would like to see how this is done you can take a look at these LICENSE and NOTICES files.

[kool19822]

@kool19822 Please stop spamming the issue, I'm not interested in your attempts to derail this discussion.

Hey cool it down man I'm just saying this could be one thing or another I think its best to have the lawyers sort it out or for you and harmony to work something out in a mutual benefit is all.

[karalabe]

@kool19822 You've lost your social credit with this comment (whether you deleted it afterwards or not):

Hey since you put this out in the open which is BS I can publicly say Peter you suck!

[kool19822]

@kool19822 You've lost your social credit with this comment (whether you deleted it afterwards or not):

Hey since you put this out in the open which is BS I can publicly say Peter you suck!

Haha come on Peter why didn't you reach out to them via other means though serisouly

[kool19822]

Either way you wont have to worry about me I hope you guys figure this out Im butting out of it.

[stefantalpalaru]

@stefantalpalaru You seem to have mixed up a few things though.

No, I'm not the one mixing things up.

The issue is not placing LGPL code into another codebase, the issue is releasing the derivative codebase under a more permissive license.

No argument there. There can be no relicensing by people other than the copyright owners.

This repository is under the MIT license

Not all of it. The README clearly states: "Harmony includes third-party open-source code. In general, a source subtree with a LICENSE or COPYRIGHT file is from a third party, and our modifications thereto are licensed under the same third-party open source license." - https://github.com/harmony-one/harmony#license

[karalabe]

Harmony is licensed under the MIT License. See LICENSE file for the terms and conditions.

Since Harmony includes LGPL code, Harmony cannot be licensed under MIT. Also the linked LICENSE file for "terms and conditions" is blanket MIT without mention of exceptions. The project on GitHub is also marked as clean MIT.

[ineffectualproperty]

Harmony is licensed under the MIT License. See LICENSE file for the terms and conditions.

Since Harmony includes LGPL code, Harmony cannot be licensed under MIT. Also the linked LICENSE file for "terms and conditions" is blanket MIT without mention of exceptions. The project on GitHub is also marked as clean MIT.

IANAL but I don't think that is entirely true that it cannot be licensed under MIT, see section 4 of the LGPL license:

"You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work".

I have seen (whether correctly or incorrectly) Apache 2/MIT licensed projects that include GPL'd work e.g. under the 'classpath exception'.

That said, the LICENSE file absolutely should contain information about third party software that is licensed under different terms, and the LGPL license needs to be included in the source code as well. However, be aware that GitHub may still pick this as being a clean MIT license as this LICENSE is shown as Apache 2 even though it explicitly calls out other included libraries that are licensed under MIT.

Edit: I should clarify that if the files are modified they need to be released under LGPL, and the above is only referring to linking unmodified LGPL libraries.

[kool19822]

Until further understanding of the descriptions of what is correct by terms of law and what isn't then this is clearly hearsay and needs to be cleared up with an actual lawyer on either end until then this is nothing period. Why it was brought into public light before being discussed with actual law professionals on the license agreements (descriptions) of what is and what isn't to start with is subject to your own imagination. I think it's best for everyone to await an official response to these allegations backed by actual law professionals before making a final judgment but again for now it's just speculation.

[LeoHChen]

Thank everyone for your input and this is a good discussion here.
It helps us understand and clarify the misunderstanding of some open-source licenses.
I agree that we shouldn't relicense the LGPL code with a blanket MIT license in our repo without mentioning the LGPL'ed code.
As a small team, to simplify the change, we decided to adopt the LGPL license for the entire repo.

[kool19822]

Thank everyone for your input and this is a good discussion here.
It helps us understand and clarify the misunderstanding of some open-source licenses.
I agree that we shouldn't relicense the LGPL code with a blanket MIT license in our repo without mentioning the LGPL'ed code.
As a small team, to simplify the change, we will just adopt the LGPL license for the entire repo.

I guess that settles it then and everyone should be happy

[stefantalpalaru]

Since Harmony includes LGPL code, Harmony cannot be licensed under MIT.

The LGPL code is an external library, not part of Harmony itself.

As a small team, to simplify the change, we decided to adopt the LGPL license for the entire repo.

Unfortunately, this will help propagate the misconception that LGPL is "viral" like the GPL and will encourage those who ignore existing LGPL libraries only to rewrite them - poorly - under MIT or BSD licenses.

This kind of effort duplication and internal division is a plague on the free software community as a whole.

[ligi]

The LGPL code is an external library, not part of Harmony itself.

Nope - there is geth code (which is LGPL licensed) all over this repo.

So I think changing the license to LGPL is the correct move. That said: technically you would need to ask all contributors since your added the MIT license to approve this relicensing because they thought they contribute to MIT code (which they did not). If one of them does not agree you would need to remove their contributions (which is becoming a real pain the more changes are on top of it) They could still sue you. But I am happy this went without any lawyers involved and you now finally respect the license of geth.

[kool19822]

The LGPL code is an external library, not part of Harmony itself.

Nope - there is geth code (which is LGPL licensed) all over this repo.

So I think changing the license to LGPL is the correct move. That said: technically you would need to ask all contributors since your added the MIT license to approve this relicensing because they thought they contribute to MIT code (which they did not). If one of them does not agree you would need to remove their contributions (which is becoming a real pain the more changes are on top of it) They could still sue you. But I am happy this went without any lawyers involved and you now finally respect the license of geth.

Yeah me too this created a lot of unnecessary panic which could of been handled in private and Peter sorry about you suck comment hopefully we are all good and all is forgiven, but the Twitter post scared a lot of people over this very small issue and it was as your tweet in the heat of the moment why I deleted it later.

[karalabe]

@LeoHChen Thank you for your quick resolution. All the best to your project :)