If I use go-ethereum, as is, without any modification, as a library in another Go project, I’d assume that I can put that project under another open source license (e.g. we use Apache 2.0 in go-perun) or even use go-ethereum as a library in proprietary, closed-source software – because it is LGPL licensed.
However, strictly speaking, the LGPL states that this permissive use is only granted if linked _dynamically_, if I interpret the license correctly. Alas, Go links all dependencies _statically_, so wouldn’t this imply that I cannot use go-ethereum in any other non-GPL-compatible Go project if using Go’s usual build toolchain?
The only other brief discussion I found on this topic is at https://www.reddit.com/r/ethereum/comments/5kf9tb/why_ethereumgo_is_lgpl/ . There it sounds like the intention behind choosing LGPL as a license for the library parts was to actually give permission to other Go projects to use go-ethereum without forcing them to open-source under a GPL-compatible license themselves (given that modification of go-ethereum itself are, of course, open-sourced).
I guess part of the confusion comes from the fact that the LGPL was designed with the gcc toolchain for C/C++ programs in mind, where dynamic linking was and still is a more frequent mode of operation than for, say, Go, where static linking is the default (and very hard to change).