lychee
lychee copied to clipboard
lycheeverse
Licensing issue: AGPL derivative
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.
Honestly, email features were one of the best parts of Lychee IMO. Would it be possible to switch to AGPL, or to do something similar to projects like ffmpeg and support optional copyleft features?
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.
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.
to prevent any license issues in the future, we should use https://lib.rs/crates/cargo-deny to check license compatibility in CI workflow.
You do not need permission to relicense from MIT/Apache to AGPL. You would need permission to do the reverse. MIT and Apache are AGPLv3-compatible, but AGPLv3 is not MIT/Apache-compatible.
@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.
changing license is nearly impossible unless you get agreement from ALL contributors.
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.
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.
Thanks for raising this @Seirdy. The email feature is currently not very reliable at the moment. We talked about disabling it by default in https://github.com/lycheeverse/lychee/issues/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?
@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.
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.
you are talking past each other @Seirdy @lebensterben
It's without a doubt possible to generally redistribute lychee under the AGPL without requesting permission from the contributors. The MIT license requires you to retain copyright notices and the permission notice from the MIT, but that does not mean you can change the main license of the entire project right now and license future changes to lychee under AGPL only.
Keep in mind that any license change always only ever applies to future versions of a piece of software. While it's possible to change the license for lychee 1.0, it's not possible to retroactively change the license for lychee 0.9. Even if all contributors would agree to that, the software is already out there under the MIT license. As a practical implication, a user can fork lychee 0.9 and continue that fork under the MIT.
This quote from @lebensterben is key:
Otherwise lychee must carries the original license and declare which portion of code was licensed under that.
That's exactly how to do the license change. You keep the original license around on top of the AGPL. Yes, changing the license is not "relicensing" depending on your definition of the word, but that's enough to get (future versions of) lychee out of the AGPL violation.
I also don't think it's a good idea to do any of that. It will impact use of lychee-lib in third-party software. reacherhq appears to have licensed check-if-email-exists under AGPL to prevent commercialization by a competitor who would not be willing to open-source their codebase. If lychee wants to pursue a similar business model eventually, it could do so, but it means it's not possible to build a proprietary service around the library anymore.
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.
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.
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.
Honestly, email features were one of the best parts of Lychee IMO. Would it be possible to switch to AGPL, or to do something similar to projects like ffmpeg and support optional copyleft features?
#1099 added an email-check feature 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-tls or --no-default-features --features rustls-tls to Cargo.
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.
I am thinking about disabling email-check by default. Email addresses lead to a lot of false positives at the moment (see https://github.com/lycheeverse/lychee/issues/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: https://github.com/lycheeverse/lychee/issues/1089
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.
