Venus: [bug] LGPL code included in liberally licensed repo

[ebuchman]

Thanks for open sourcing this, looks awesome.

But I noticed the crypto pkg copied over from go-ethereum is LGPL licensed, which in my understanding is incompatible with Apache/MIT.

[mishmosh]

@ianjdarrow can you take a look?

[whyrusleeping]

I was under the assumption we were using @karalabe's extracted package: https://github.com/ipsn/go-secp256k1

Did that switchover not happen yet? (Cc @frrist)

[whyrusleeping]

Ah yeah, that didn't happen for some reason. Let's make that change asap

[ZenGround0]

After looking into this it looks like we are using the extracted secp256k1 library (https://github.com/filecoin-project/go-filecoin/pull/936/files#diff-9e715c769ee8686029c3443430f66d3a) but some of the calling code is taken from geth.

[karalabe]

Hmm, we've only relicensed secp256k1 (or rather sanitized the license to match the C code). I can ask the team on Monday how they feel about pushing the boilerplate too to BSD-3.

[dignifiedquire]

thanks @karalabe!

otherwise I think we need to get rid of that code for now and write our own independent version of it

[phritz]

@ZenGround0 is out until next week, will follow up then

[fjl]

Is there any problem with simply keeping the LGPLv3 code (with proper license notice)? It is totally fine to ship a binary containing LGPLv3 library code under a different license as long as the user's right to modify/debug that library code isn't affected.

[fjl]

We cannot relicense go-ethereum or parts of go-ethereum at will because the set of copyright holders is very large. Your options at this point include reimplementing those parts yourself or complying with LGPLv3. Compliance might not be as difficult as you think actually.

[fjl]

See very bottom of this page for explanation of LGPLv3 compliance. Related paragraph is

If you choose to statically link or otherwise combine your program with an LGPLv3’d work via mechanisms other than a shared library, you may choose your own license for the work provided the license terms limitations for user modification, reverse engineering and debugging are met, and given that the LGPL’d components are still governed by LGPL’s terms. You must offer or provide CCS for the LGPL’d components. The source code material provided must be sufficient to regenerate the combined work with a user-modified version of the LGPL’d components.

[ianjdarrow]

We should reimplement the LGPLv3 portions.

It'd be no problem for go-filecoin itself to comply with LGPLv3, but downstream users that fork the codebase, extract parts, etc, would inherit the requirement to make their code available for modification and debugging. Unfortunately, this is incompatible with our permissive non-copyleft project licensing.

[fjl]

They don't need to make their own code available, just the LGPL parts. I understand you might find such restrictions stupid, but ask yourself: would you like to use an app containing crypto code you can't debug? :)

[whyrusleeping]

@ianjdarrow @fjl given that reading of the license, compliance doesnt seem to require we license our codebase as LGPLv3, it just seems like that particular piece of code must always be kept open and be licensed as LGPLv3.

If downstream users pull pieces of go-filecoin, they could pull and do whatever they want with every piece except that one, which they can still use, they just have to make it possible for their users to change the crypto libs. which, now that i think about it, would be kindof annoying (accomplishable via making it a linked library).

would you like to use an app containing crypto code you can't debug? :)

heh, do i trust myself to debug crypto code? maybe.

All that said, since the code in question isnt actually the crypto code, its just some wrappers around it, which barely amount to much. I think its going to be much less work overall to just rewrite those five or so functions.

[karalabe]

Note, you crypto utils package is also copy pasted from various packsges
from our codebase. You'd need to rewrite those too.

On Sat, Feb 23, 2019, 01:31 Whyrusleeping [e-mail] wrote:

@ianjdarrow https://github.com/ianjdarrow @fjl https://github.com/fjl
given that reading of the license, compliance doesnt seem to require we
license our codebase as LGPLv3, it just seems like that particular piece of
code must always be kept open and be licensed as LGPLv3.

If downstream users pull pieces of go-filecoin, they could pull and do
whatever they want with every piece except that one, which they can still
use, they just have to make it possible for their users to change the
crypto libs. which, now that i think about it, would be kindof annoying
(accomplishable via making it a linked library).

would you like to use an app containing crypto code you can't debug? :)

heh, do i trust myself to debug crypto code? maybe.

All that said, since the code in question isnt actually the crypto code,
its just some wrappers around it, which barely amount to much. I think its
going to be much less work overall to just rewrite those five or so
functions.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/filecoin-project/go-filecoin/issues/1991#issuecomment-466584727,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH6GeX-U0ehuNe7-uAY-yaDSAOIRkgrks5vQH3pgaJpZM4a9M02
.

[whyrusleeping]

yeah, it looks like we only actually use one function from that, which pads a bytes array to a given length. pretty sure that can just be pulled from the go stdlib instead. Then the keys file is pulled from btcd, which is ISC (BSD-2 / MIT). Seems pretty straightforward.