pfink
commented
5 years ago With EPL 2.0 you have a maximum of compatibility between the binding and openHAB / ESH while you'll keep the door open to integrate the source code of this project one day into openHAB or ESH (I know, the first try failed, but it doesn't have to be the end of the story ;-) ). Anyhow, with you current setup, I think you're not bound to EPL 2.0 as far as I can judge that. There is no problem to include Apache 2.0 binaries into an EPL-licensed project, in fact that is done very, very often (there are countless EPL-licensed projects using apache commons, e.g. also ESH is distributed with the apache commons binary. And ESH is under strong legal obversation by the Eclipse Foundation).
If you want to choose EPL 2.0, but you don't like Copyleft and also want to have the possibility to distribute your project under Apache 2.0 (additionally to EPL), you have 2 options:
- Dual License: When you dual-license this project, everybody can decide on his own whether he complies with Apache 2.0 license and/or EPL 2.0. This means, everybody can redistribute this project, it's source code and any derivative work either under EPL 2.0 or under Apache 2.0 or under both licenses. But with Apache 2.0, you completely loose Copyleft. So if somebody makes very big changes to this binding which are enough to create a so-called "derivative work", he is not obligued to publish it under the same license (in fact, he could sell it as a product without publishing his source code). Here an example how to dual-license.
- Secondary license: A Secondary License is, different than the first option, a specific concept by EPL 2.0. This is a "light" variant of the dual license. If you license this project under EPL 2.0 with Apache 2.0 as a secondary license, the following rules apply: EPL is the main license, but additionally, so can integrate the code or binary of this project as-is into another project licensed under Apache 2.0 and distribute the "overall" project (legally it's called a "combined work") under Apache 2.0 (or under EPL 2.0, of course). Anyhow, other than with dual-licensing, you're not allowed anymore to distribute this under Apache 2.0 or your license when you do big changes. So derivate works still have to be published under EPL 2.0 then, which means Copyleft is partially retained. Here an example how a secondary license can be specified (in this example, the secondary license is GPL 2.0)
As I'm a big fan of Copyleft, if I'd have to choose a license, I'd do EPL 2.0 with LGPL 3.0 as secondary license. This means you have full ESH/EPL-compatibility, Copyleft and also GPL-compatibility (even though GPL compatibility is probably not really relevant for this project. But as those decisions are extremely hard to revise as soon as you have a certain number of contributors, I always preventively ensure GPL-compatibility in case I need it one day in the distant future...). Important to remark: If you're commercially active with this binding and want to do a customer-specific fork of it, Copyleft will also force you and your customer to publish this fork under the same license. Btw, Apache 2.0 is also GPL-compatible, which means both options from above will also ensure GPL-compatibility.
My country forbids to give legal advices on concrete cases for non-lawyers, so I have to point out that this is just hypothetical and my personal opinion without any warranty (even though I know more about free software license compatibility than most lawyers :D).
I hope this helps you a bit with your decision. If you have questions, don't hesitate to ask.
vkolotov
what would be your recommendations? All bits and pieces are licensed with Apache v2.
Originally posted by @vkolotov in https://github.com/sputnikdev/eclipse-smarthome-bluetooth-binding/issues/73#issuecomment-446331550