Repository navigation
Licensing issue: drop check-if-email-exists dependency #594
Description
Just noticed that Lychee uses code from https://github.com/reacherhq/check-if-email-exists, which is licensed under the copyleft GNU AGPLv3 for open source projects and a commercial license for proprietary software. Lychee therefore would need to use a GNU AGPLv3 license to remain compliant, or drop the dependency.
Thought you should know.
Activity
lebensterben commentedon Apr 17, 2022
let's drop email capability.
Seirdy commentedon Apr 17, 2022
lebensterben commentedon Apr 17, 2022
it's possible but requires some changes.
lychee-lib can be licensed under MIT/Apache 2.0 without email feature.
The email feature can be moved to a new crate lychee-email under AGPL 3.0 license.
Then lychee-bin can be licensed under one of these licenses depending on whether the email feature is enabled.
lebensterben commentedon Apr 17, 2022
also need to mention that, we cannot easily change the license.
when people contributed their work to the codebase, their intent was to license their code under MIT/Apache 2.0.
you'll need everyone to agree to change the license.
lebensterben commentedon Apr 17, 2022
to prevent any license issues in the future, we should use https://lib.rs/crates/cargo-deny to check license compatibility in CI workflow.
Seirdy commentedon Apr 17, 2022
lebensterben commentedon Apr 17, 2022
@Seirdy
Nope. that's a misunderstanding.
As for license compatibility: MIT/Apache 2.0 code can be used in AGPL 3.0 project and the reverse is not true.
But what I'm saying is that you cannot change the license of this project without the agreement from the authors. This is not about license compatibility.
lebensterben commentedon Apr 17, 2022
changing license is nearly impossible unless you get agreement from ALL contributors.
Seirdy commentedon Apr 18, 2022
If I were to fork an MIT project and make my fork AGPLv3, that would be allowed. I'd be re-using contributors' code that was licensed under the MIT license, because using MIT code in an AGPLv3 project is allowed.
If a project were to switch from MIT to AGPLv3, that would be allowed for the exact same reason: using contributors' MIT code in an AGPLv3 project is allowed.
If a project were to switch from AGPLv3 to MIT, that would require permission from all contributors because you can't use AGPLv3 code in an MIT project and keep the license.
Contributors do not sign a legal agreement stating that their contribution is contingent upon a project never changing a license; they simply agree to the terms set forth by the existing license. If the existing license is AGPLv3, that means that it cannot be re-licensed to MIT without permission from all authors. The reverse is not true.
lebensterben commentedon Apr 18, 2022
that's not correct.
license cannot be changed retroactively, so all current code are always MIT/Apache 2.0.
Suppose lychee became licensed under AGPL, for any significant contribution (> 10 loc), the copyright holder must gives the permission. Otherwise lychee must carries the original license and declare which portion of code was licensed under that.
mre commentedon Apr 25, 2022
Thanks for raising this @Seirdy.
The email feature is currently not very reliable at the moment. We talked about disabling it by default in #575. I would not mind dropping it entirely, but it seems like you think it's useful. Didn't you encounter a lot of false positives?
We could create a separate lychee-email crate and it could be moved to a separate plugin, which could be helpful anyway at some point. I'm struggling to find a great plugin system, though. Considered Webassembly, but I don't know of any existing solution for Rust or any other tool we could look at for inspiration. @lebensterben any thoughts?
lebensterben commentedon Apr 25, 2022
@mre
We can drop it from lychee-lib and lychee-bin.
And use a standalone check-if-email-exists binary in lychee-action. We don't even need to disclose the source code because we are not distributing the binary.
mre commentedon Apr 25, 2022
Sounds like @Seirdy meant the binary, not the action, though? In any case it would be nice to have the ability to check emails from the cli as well.
3 remaining items
untitaker commentedon Jun 18, 2022
A third, probably not very useful, option not mentioned: it'd be possible to put lychee's usage of check-if-email-exists behind a compile-time feature. If that feature is disabled, the resulting binaries do not contain AGPL code.
mre commentedon Jun 20, 2022
I was hoping to look into the wasm plugin system that zellij provides to see if we could use that somehow. Then e-mail support could be moved there. Alternatively, can't we simply move it to a sub-crate and isolate it this way? When it gets published, it will have the correct license.
untitaker commentedon Jun 25, 2022
if it's in a subcrate but you still have that subcrate as dependency, the AGPL violation just becomes less direct. I would recommend to drop this functionality.
Seirdy commentedon Oct 11, 2022
Add optional Rustls support (#1099)
stefankreutz commentedon Jun 16, 2023
#1099 added an
email-checkfeature flag for the AGPL-licensed check-if-email-exists crate. This was necessary because the crate doesn't support Rustls yet. However, you can disable email checks at compile time now by passing--no-default-features --features native-tlsor--no-default-features --features rustls-tlsto Cargo.untitaker commentedon Jun 16, 2023
If the end result is that all the binaries distributed by lychee still contain GPL code by default while Lychee at surface-level still claims to be MIT-licensed, that's a massive footgun for people who are trying to use lychee in their codebase.
mre commentedon Jun 16, 2023
I am thinking about disabling
email-checkby default. Email addresses lead to a lot of false positives at the moment (see #1111). If people need the feature, they would have to compile lychee themselves from the sources. Maybe there's also a way to distribute the "full" lychee CLI with email support as a binary under a different license?Related: #1089
Kurt-von-Laven commentedon Aug 9, 2023
There are a lot of differing opinions regarding the rules for re-licensing. I am not so confident that the answer would even be the same in every jurisdiction after seeing the lack of consensus. Given this, it seems at least courteous to solicit contributor approval for re-licensing.
As someone who encountered a lot of false positives from
email-check, I am also a fan of removing this feature in light of the licensing concerns.[-]Licensing issue: AGPL derivative[/-][+]Licensing issue: remove check-if-email-exists[/+][-]Licensing issue: remove check-if-email-exists[/-][+]Licensing issue: drop check-if-email-exists dependency[/+]thomas-zahner commentedon Feb 3, 2026
I've written a new crate to replace check-if-email-exists, resolving both the licensing compatibility issues as well as improving functionality & UX, as described in #1985. So mail checking with lychee should now be more reliable than before.
Feedback on the new mail check functionality is welcome.