Closed ruuda closed 3 years ago
As pointed out by Ruud in #105
IANAL, but if it’s a copy, or even an adaptation, we need to retain the copyright notice of the original code (SPL is Apache2):
You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works
But this is dealing with Lido, it’s not a copy of something in the Solana program library, is it?
Some of the Lido parts are copied/modified from the Stake Pool, We should take this into consideration when deciding which license to use for it
Checked in with P2P if Apache 2.0 is OK. They redirected me to LEGO Governance.
Pinged Florian (who's in LEGO Governance). He is going to check in with the LEGO group and get back (hopefully today).
Both P2P and Lego Governance prefer GPL.
Given that Apache 2 software can therefore be included in GPLv3 projects
( https://www.apache.org/licenses/GPL-compatibility.html ), I think it's OK to go ahead with GPL v3.
If anyone has counter-opinions - please lmk. Otherwise, I will close this with a GPL-license-included PR by Wednesday 13 July 2021 :).
We need to check that all dependencies in Cargo.lock
are compatible. There is probably some tool that can print the licenses of each and group them.
cargo license
Licenses of dependencies, excluding ones known to be GPL-3 compatible already:
$ cargo license | grep -vE '^[^:]*(Apache-2.0|BSD-3-Clause|BSD-2-Clause|MIT|ISC|MPL-2.0|CC0)[^:]*:'
N/A (5): lido, multisig, ring, solido-cli, webpki
There are our own crates, and then the following two:
ring
, whose license situation is “it’s complicated”.webpki
, which is ISC-style, which third-party code from Chromium, which is 3-clause BSD. This one should be fine.It seems that ring
is pretty deep in multiple places in our dependency tree, so it’s not easy to avoid. Further investigation is needed. (But that is the case regardless of what license we go with.)
The FSF lists the OpenSSL license, as GPL-incompatible. ring
is a fork of BoringSSL which is a fork of OpenSSL. I don’t know what this means for us. I also found this document that says:
Uses an Original BSD-style license with an announcement clause that makes it "incompatible" with GPL. You are not allowed to ship binaries that link with OpenSSL that includes GPL code (unless that specific GPL code includes an exception for OpenSSL - a habit that is growing more and more common).
In any case, these libraries should not be needed for the on-chain program, so I think we can at least go ahead and license the on-chain program as GPL-3.
For the solido
binary, things are more complex. This may also impact the container image, which is a form of redistribution. I am out of my depth here, we should obtain an expert opinion.
Before we make the repository public, we should put a license in place and add copyright headers to the source files.