Consider relicensing to a permissive license

[TheButlah]

Hi! The EPL 2.0 is copyleft/viral. We mix our (MIT/Apache) source code with proprietary third party vendor SDKs. These vendor sdks are code that we don't have legal rights to open source, and which are incompatible with EGPL-2.0. This is quite common in firmware / code that deals with hardware unfortunately :(

Would you consider re-licensing to a permissive license, such as an MIT/Apache 2.0 license so that more projects can make use of this crate?

P.S. sorry for the spam, I opened these issues on any dependencies of zenoh that I saw were EPL-2.0 only

[p-avital]

Hi Ryan,

If you don't mind, I'll treat this thread as the global one for all other repos to avoid spam.

To my knowledge, EPL-2.0 should be permissive enough for your usage: it fully permits usage of three software in commercial products, only requiring that changes to the software itself be contributed back (not in the sense of a PR being mandatory, but in the sense that the modified fork must be public under the same license).

Unlike GPL, its definition of derivative works is much more narrow.

You are free to use and distribute the software however you see fit (possibly vendoring it, if you wish to control your supply chain). Only if your usage requires modification (to support additional platforms for example), would you then be required to open source your fork of the repo (and nothing more).

This notably means that if your usage of these libraries is simply "they're in our dependency tree", I expect you needn't do anything; and nor does the licensing need to change, as EPL-2.0 and MIT/Apache are essentially equivalent for that use case.

Are these terms really not agreeable to you?

[TheButlah]

You are correct I think, that distributing it unmodified does not trigger the copyleft permissions, that definitely helps. For example, my organization allows MPL licensed code which is similar in that unmodified source code does not trigger copyleft - in MPL, the virality is scoped to the file. We allow MPL on a case-by-case basis, although its frowned upon.

However, I think there are a few concerning provisions in the EPL that go a lot further than a license like the MPL:

• Section 4 broadens the notion of disclaimer of warranty. Most licenses disclaim warranty on behalf of the authors. But the EPL goes a lot further, and compels users of the software to further pay and defend such authors, if those authors can claim that the lawsuit against the author was because of the corporate user's advertisement. I think this is an unusual clause in a software license and could easily be abused. A much better approach is just leaving it at the disclaimer of warranty, or alternatively doing what BSD's no attribution clause does.
• The license is not clear what "Commercial" means, as far as I can tell it isn't defined at all. For example, is someone accepting donations for their work that uses an EPL dependency providing a commercial offering? Would they then be able to accidentally get themselves into a situation where they have to pay legal fees on behalf of a legal battle they ought not to be involved in to begin with? In other words, it subjects average devs (not just corporations) to possible embroilment in legal battles.
• The license takes an overly broad definition of "Contributor" . When we think of a "contributor" we typically mean someone that has modified covered source code. But the EPL defines "contributor" as anyone that distributes the program or source code. I think that this definition is overly broad and leads to confusion. Ultimately IANAL so any confusing language in the license, especially when the license is less well known, means that I will need to consult a lawyer or not use the software.

Because of these issues, I think most organizations would still need to consult with a legal team to explicitly approve this license, and many legal teams would not be willing to add the liability of defending third parties - which makes adoption harder.

I wonder, if the focus is specifically on ensuring that modifications but not use of the code triggers copyleft, maybe you could consider using MPL? I think that MPL, while not as permissive as MIT or Apache, would ensure modifications are shared back to the project, without having the additional problematic clauses from above.

If you also like EPL, a spdx identifier of EPL-2.0 OR MPL-2.0 would address these concerns I think.

[TheButlah]

See also: eclipse-zenoh/zenoh#1625 (comment)

TLDR:

• I was wrong about copyleft, EPL-2.0 is similar to MPL in that simply consuming code as a dependency and not modifying it doesn't trigger copyleft. This alleviates most of the concerns.
• The indemnity clause is still a bit problematic, but the risk is fairly low and we don't think we would ever run afoul of this, so for my particular company we were fine with it.

I will leave this issue and the others open, but feel free to close them if its something that is not planned.