Remove or relicense copyleft 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 copyleft. This is undesirable - many projects combine FOSS code and third party vendor SDKs, which are not FOSS and closed source. This would make it impossible to use zenoh with such third party SDKs, even when first-party code is itself FOSS.

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 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.