tokio-postgres-rustls
tokio-postgres-rustls copied to clipboard
jbg
Dependency `x509-certificate` has copy-left MPL-2.0 license
This just came up in my automatic license check using cargo-deny and I wanted to raise awareness, because in my project and company this is a problem.
#14 brought in the crate x509-certificate, which has the copy-left MPL-2.0 license. tokio-postgres-rustls is pretty fundamental infrastructure: when a project uses Postgres and Rust, the chances are good, that this crate is used. Keeping the licenses permissive would allow it to be used in environments that ban the use of copy-left licenses.
Would this crate be open to exchanging that dependency?
In my naive view, rustls should have all the x509 infrastructure included, because rustls also needs certificate parsing. It would be great to work with the already existing dependencies. But I also read the docs and have not yet found how to get the required information.
One option would be to use x509-cert instead: https://docs.rs/x509-cert/0.2.5/x509_cert
MPL isn't viral, but I understand it's difficult to argue with company policy
rustls exposes a pretty low level interface: https://docs.rs/rustls-pki-types/latest/rustls_pki_types/struct.AlgorithmIdentifier.html but could make sense creating another crate which understands rustls::pki_types::AlgorithmIdentifier. Maybe that crate is oid_registry which is made by people behind x509-parser which has example use like this
The MPL 2.0 FAQ:
Q11: How 'viral' is the MPL? If I use MPL-licensed code in my proprietary application, will I have to give all the source code away?
No. The license requires that Modifications (as defined in Section 1.10 of the license) must be licensed under the MPL and made available to anyone to whom you distribute the Source Code. However, new files containing no MPL-licensed code are not Modifications, and therefore do not need to be distributed under the terms of the MPL, even if you create a Larger Work (as defined in Section 1.7) by using, compiling, or distributing the non-MPL files together with MPL-licensed files. This allows, for example, programs using MPL-licensed code to be statically linked to and distributed as part of a larger proprietary piece of software, which would not generally be possible under the terms of stronger copyleft licenses.
AFAICT MPL 2.0 was specifically designed in a way that allows it to be used in proprietary software as a library.
What is the actual concern with MPL 2.0? The use of it as a dependency in this crate doesn't prevent the use of this crate in commercial software; the MPL is very explicit about that. Is there another angle I'm missing?
Thanks a lot for working on this :heart: Just as an explanation: the concern in my environment was not about the actual content of the MPL, but the fact that is is categorized as copyleft.