Homeduino / openHAB integration

[martinvw]

Dear maintainers,

I used pimatic for some time but felt more comfortable with openHAB (also because I'm a fulltime java developer). However I still think that homeduino could be a great addition in combination with openHAB.

So a long time ago I started playing with the idea to make a binding to be able to connect the Homeduino to openHAB, to get some feeling of the process you can read along on the following thread: https://community.openhab.org/t/interest-in-a-homeduino-binding/8017

However to be able to parse the protocols as they are returned by the homeduino I used the source of rfcontroljs. I did not literally copy code because its not compatible but I definitely used ideas and of course the efforts of people to reverse engineer the protocols. Do you think that there are any objections to this given that I'll make sure that there is proper crediting to the Homeduino & RFControlJs projects?

Thank you very much for your time!

[mwittig]

Hi Martin,

I think there is a conflict. As far as I know openhab and openhab addons are published under the Eclipse Public License 1.0 which is a commercially-friendly copyleft license. In the context of openhab that make sense as the code is also used as a baseline for commercial products like Qivicon. On the contrary, pimatic and plugins are published under GPLv3 (partially also GPLv2) which also applies to any derivative work like your project. See also question 32 at https://eclipse.org/legal/eplfaq.php.

I am not a law expert but I think you'll be at risk if you publish the addon in the context of openhab. A solution may be to get a written consent by ALL authors of rfcontroljs to use/reuse the ocde under a permissive license. See also http://stackoverflow.com/questions/5393873/epl-eclipse-public-license-gpl-gnu-public-license-lgpl-lesser-gpl-and-lic

@sweetpi What is your opinion on this?

[kaikreuzer]

First: IANAL

I agree with @mwittig that it isn't possible to include GPL code within the EPL'ed openHAB - so asking ALL authors to additionally license their work under EPL would be the only option IF YOU USE any code for which they hold a copyright.

I did not literally copy code because its not compatible but I definitely used ideas and of course the efforts of people to reverse engineer the protocols.

If you indeed did not copy anything, you have not directly modified or redistributed any of their work, so I would claim that the license does not matter; just reading somebody else's code does not make your own work a derivative of it. It becomes difficult to judge though, if you copied any intellectual property wrt ideas, concepts, etc. I think this is legally a grey zone where there is no clear answer and it depends on the concrete case. If I understand it right, most "value" of the code are actually the reverse engineered protocols. The copyright for those might be rather claimed by the device manufacturers and not by the rfcontroljs code authors, so I would claim that this information is not under the GPL here (but legally also very greyish, but if you use it, you are in the same shade-of-grey situation as the rfcontroljs project currently is).

Just my 2 cents :-)

[mwittig]

One of the questions to answer is whether the code for the openhab/homeduino binding can be seen as a translation of the rfcontroljs code and other parts of the pimatic project (-> derivative work) or it has just been inspired by rfcontroljs ("reading somebody else's code" as Kai stated). @martinvw, maybe you can clarify on this?

Anyhow, I think we should come to a conclusion on this quickly. I'll discuss the matter with the pimatic team asap.

Needless to say that the homeduino code running on Arduino is licensed under GPLv3 which should not be a problem, however, as this can be seen as an independent/separate entity/device. However, I think it should be mentioned somewhere on the project page (README) of the openhab/homeduino binding.

[martinvw]

To be able to reuse the procols (as reverse engineered here) I used a very similar algorithm to group similar groups of pulses. Since coffeescript is not compatible with Java I worked more on getting the same output with the same input. Because without I had a different grouping for for example the rollershutters.

I will definitely mention it, people need to know with what device they can use it :)

[sweetpi]

Hi @martinvw, nice to see openHAB adopting rfcontroljs.

I personally have no problems with this and I have no problem to dual license it under EPL. However @mwittig is right, all authors have to agree with this.

The most valuable thing in rfcontroljs are the protocol definitions. It would be awesome if we could keep new or updated versions sharing between your and this version. Most people have difficulties with writing CoffeeScript and as you said, using CS from Java is not very comfortable. What about converting the protocols to a format, we can both include easily? So we could share the same protocol definition files and contribution would be easier. Any ideas about a format?

[mwittig]

What about converting the protocols to a format, we can both include easily? So we could share the same protocol definition files and contribution would be easier. Any ideas about a format?

I had similar thoughts. Maybe we can use a transpiler like JSweet which translate from one language (e.g. Java) to another (e.g. JS). Using a meta language yaml would be nice and it might be possible to use a customized swagger-codegen for that.

[martinvw]

I was about the suggest a JSON format, but transpiling from Java to both CS and JavaScript sounds also like a great idea.

[martinvw]

Sorry for falling silent, I was adopted as a maintainer for openHAB that consumes a lot of time now :-D

@sweetpi what are your opinions about the format? YAML, transpiling? For me it would be the easiest to just have a jar dependency or something so the cross-compiling could work out well. Maybe we could publish the build-result to both npm and mavencentral.

About the licensing we could maybe work out something hybrid (to start with) so first migrate the ones for which all authors agree quick and the later merge the others step-by-step on agreement. Maybe we could even change rfcontroljs to be able to load them both at the same time, so really migrating the protocols not just copying them.

wdyt?