Remove or relicense EPL-2.0 only dependencies

[TheButlah]

Describe the bug

the following crates that zenoh depends on are EPL-2.0, and not dual licensed like zenoh is. That means that consumers of zenoh will be forced to comply with the EPL-2.0 license, which is weakly copyleft and more importantly, is an uncommon license and has indemnity clauses that other licenses do not have. In particular, these indemnity clauses give additional legal burdens on users of zenoh, especially if they talk about how they use zenoh in their products. The odd nature of the license will prompt companies adopting zenoh to have tedious conversations with their legal teams, some of which will not be willing to take the risk.

Would zenoh consider either removing these dependencies or asking the authors to relicense under a permissive license?

Dependencies that are EPL-2.0 only:

• keyed-set
• ring-buffer-spsc
• token-cell
• validated_struct
• validated_struct_macros

[TheButlah]

For some transparency, the licensing did require a conversation with my company's legal team, whereas normally these things are entirely frictionless. However, here is what we determined:

• We can still talk about how we use zenoh due to zenoh's apache license, we just can't talk about zenoh's EPL-2.0 only transitive dependencies due to the indemnity clause in section 4 of the EPL-2.0. This is fine, for us the important part is that we could for example write a technical blogpost about zenoh.
• As we understand it, the copyleft provisions in these transitive dependencies would only apply if we modify the software, and EPL-2.0 explicitly says that linking to, binding by name, subclassing, these are not modification. So our first party code and third party vendor sdks don't trigger the copyleft parts of these transitive dependencies.
• The EPL-2.0 doesn't have much case law and is an uncommon license, so ultimately the legal team could not speak with certainty on any of this - to do that we would have needed external legal counsel to do research which is expensive. Ultimately we decided that we are pretty sure about what the license means when it comes to copyleft, and most of our first party code is FOSS anyway, so the risk is very low. I do think a more risk-adverse company with lots of closed source software might have more reluctance from their legal team though.
• After the deliberation, we have decided to allowlist EPL-2.0 in our license checks going forward, but only for zenoh's transitive dependencies and we can use and talk about zenoh.

I will leave this issue open because I still think it would help zenoh's adoption to remove or relicense these transitive dependencies, but feel free to close it if its not something the zenoh team is willing to do. Thank you for your patience with this issue, and thank you for zenoh! Its a very impressive piece of software.

[kydos]

Hello @TheButlah, you may want to reach out ZettaScale at [email protected] since more options are available for the commercial version of Zenoh.

[TheButlah]

Hi @kydos, my post is about issues in zenoh's licensing potentially limiting zenoh's adoption. Calls to subscribe to commercial versions is exactly the type of thing that I'm worried about :)

Regardless, my company is moving forward with the existing license of zenoh, as described above. We believe the licensing of its transitive dependencies is not ideal but also is low risk.