openHAB goes Eclipse?

[Kai Kreuzer]

All,

With some of you we already had discussions around the GPL license of openHAB and that this is quite restrictive. From the start we made sure to have the option to move to the less restrictive EPL license one day. Well, we think this day might have come - the main reason for the GPL license (the fact that the KNX Calimero library was only available under GPL without a classpath exception) is obsolete for a while and so we are considering moving openHAB to the EPL license and would like to have your feedback on this.

Actually, we have the opportunity to go even a step further than just switching the license - we have the chance to move the core framework of openHAB to the Eclipse Foundation altogether.

Eclipse is currently expanding in the IoT/M2M space (see http://www.eclipse.org/org/press-release/20130730_m2m_july.php) and we are in talks to propose a new "Eclipse Smart Home" project with the openHAB core as the initial contribution.

The idea is to have all core/framework things at Eclipse - things like the ItemRegistry, PersistenceManager, editors, etc. More or less what is part of the runtime and designer distribution files. Having a new home at Eclipse for these things would not only mean that they are under EPL, but also that there is a strict IP check on them and that they are "safe" to use open source code - for inclusion in products, research and whereever. We had many complaints that the current GPL prevents using (and thus contributing to) openHAB due to rules by many legal departments. Code hosted at the Eclipse Foundation in contrast can be generally considered to be safe to use. Besides these aspects, being part of the Eclipse Foundation will definitely bring a lot more publicity to the project.

openHAB would still continue to exist and it would host all addons (bindings, actions, persistence services, etc.) and provide a full distribution just as today. The code of a few strategic addons might also be moved to Eclipse, but many of them include third-party libraries that possible would never be possible to have in an Eclipse project, so openHAB is a much better place for them. The effect on openHAB would be that - similar as it currently makes use of the Eclipse Modelling Framework, Eclipse Xtext, Eclipse Jetty, etc -, it would make use of Eclipse Smart Home and thus have less code itself. Together with this refactoring we would still switch the openHAB (addons) code to EPL and possibly also change to GitHub or BitBucket and a Git repository (as this is another demand from many users).

All of this would happen AFTER the 1.3 release, which is planned for September.

I would be very interested in your opinion, if this is an interesting path to follow and if you all would support us with this approach!

Kind regards,

Kai

[Karel Goderis]

Hi Kai,

Just a few questions of the top my mind, not structured or in a particular order:

 - Is the goal to create a Eclipse Technology Project? Or really part of the Foundation? That is not clear to me

 - Will this move not interfere with any of the m2m.eclipse.org projects like Mihini, Poha,... or with the people driving this community with a clear commercial interest (e.g. AirVantage)?

 - How can we still contribute to the "core" OH? some things will still evolve (e.g. ComplexTypes or other Item needs/types), or are yet to be defined and of interest to our community (e.g. Location Based Services, Security/Authentication multi-user support,....)

 - Is this an opportunity to better structure the binding "repository", e.g. we have very protocol oriented bindings (KNX,...) as  well as very vendor or device specific bindings (Samsung, Novelean,...)

 - Will the (abstract) foundation classes of the bindings also move? 

 - Any impact on using other Eclipse foundations in bindings? in casu, the infamous usage of Xtext in the irTrans binding

 - Have some commercial entities (e.g. IBM, or other Eclipse sponsor) already expressed their interest to push the OH core ahead, or have committed resourced to do so? 

Kind Regards

K

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[davy vanherbergen]

Sounds like openHAB is growing up.

+1 on move to EPL

+1 on move to GIT

+1 on move to Eclipse, as long as it is still open and we can change things...

and if you would ever talk to IBM about dedicating resources, keep me in the loop please. I would gladly volunteer...

Kind regards,

Davy Vanherbergen

[Kai Kreuzer]

Hi Karel,

Let me try to briefly answer your questions:

 - Is the goal to create a Eclipse Technology Project? Or really part of the Foundation? That is not clear to me

Yes, goal is to create an Eclipse Project.

 - Will this move not interfere with any of the m2m.eclipse.org projects like Mihini, Poha,... or with the people driving this community with a clear commercial interest (e.g. AirVantage)?

No, as can rather have synergies with other projects like Kura or Ponte. The m2m stuff from Sierra Wireless is targetting a different domain and I do not see any interference there.

 - How can we still contribute to the "core" OH? some things will still evolve (e.g. ComplexTypes or other Item needs/types), or are yet to be defined and of interest to our community (e.g. Location Based Services, Security/Authentication multi-user support,….)

These kind of discussions would move towards the Eclipse discussion forums - just as with openHAB, it is perfectly possibly to contribute patches, and do pull requests for the Eclipse project.

 - Is this an opportunity to better structure the binding "repository", e.g. we have very protocol oriented bindings (KNX,...) as  well as very vendor or device specific bindings (Samsung, Novelean,…)

Yes, it is, let's see what we make of it :-)

 - Will the (abstract) foundation classes of the bindings also move? 

Yes.

 - Any impact on using other Eclipse foundations in bindings? in casu, the infamous usage of Xtext in the irTrans binding

No, the recommendations of how a binding should look like, won't change.

 - Have some commercial entities (e.g. IBM, or other Eclipse sponsor) already expressed their interest to push the OH core ahead, or have committed resourced to do so? 

No, but I think it is a chance that commercial entties involve themselves, if they have interest in using the project.

Regards,

Kai

[Kai Kreuzer]

Hi Davy,

+1 on move to Eclipse, as long as it is still open and we can change things…

Yes, it actually even is the guarantee that it will stay open and nobody comes around with IP claims one day.

The contribution process is a bit more formal (due to the more strict IP checks), but Eclipse is working on making it as easy as possible (see http://mmilinkov.wordpress.com/2013/06/20/embracing-social-coding-at-eclipse/)

and if you would ever talk to IBM about dedicating resources, keep me in the loop please. I would gladly volunteer…

Maybe you should talk directly to IBM to suggest that…?

Regards,

Kai

[Jonathan Giles]

My concern centers around the stricter contribution enforcement, and also the numerous libraries depended on by OpenHAB. In short, as the burden of contribution becomes higher, the likelihood of people contributing diminishes.

Regarding the licenses of dependencies, for example, the license of many of the libraries used by bindings is Apache or similar, and I'm not sure that is something that the Eclipse crowd likes to work with (although I may be wrong, I've not actually been involved in EPL-related projects before). If you keep the numerous bindings in the OpenHAB project (and out of the Eclipse project), I still think there are open questions around the licensing of any particular binding (based on its dependencies), and the licensing that this enforces onto any packaged release of OpenHAB. Once you start going down the Eclipse path are you going to regret opening up any cans of worms here?

-- Jonathan

[Jonathan Giles]

Oh, also, I would strongly vote for continuing to use mercurial as the code repo! :-) In my experience of bitbucket I am absolutely happy with the platform, and would recommend it as an hg frontend.

-- Jonathan

[Lars Bretschneider]

Hi Kai,

can you more explain (Pro´s nad Con's) of moving to Eclipse ? I´m not know to much about to be on eclipse ...

[Kai Kreuzer]

Hi Jonathan,

My concern centers around the stricter contribution enforcement, and also the numerous libraries depended on by OpenHAB. In short, as the burden of contribution becomes higher, the likelihood of people contributing diminishes.

I think the barrier has been lowered a lot by Eclipse this year (e.g. allowing GitHub pull requests) and anyhow > 90% of our contributions are made as addons (i.e. bindings) and thus would still be part of openHAB, so nothing will change here for people.

Regarding the licenses of dependencies, for example, the license of many of the libraries used by bindings is Apache or similar, and I'm not sure that is something that the Eclipse crowd likes to work with (although I may be wrong, I've not actually been involved in EPL-related projects before).

Actually Apache licensed projects are no problem to depend on - see Eclipse Orbit (http://download.eclipse.org/tools/orbit/downloads/drops/R20130517111416/) which is full of them (and from where we already take most of our non-Eclipse dependencies)

If you keep the numerous bindings in the OpenHAB project (and out of the Eclipse project), I still think there are open questions around the licensing of any particular binding (based on its dependencies), and the licensing that this enforces onto any packaged release of OpenHAB. Once you start going down the Eclipse path are you going to regret opening up any cans of worms here?

Well, the situation will simply be the same as today. openHAB distribution has a big amount of very cool and useful bindings, but I would not recommend anybody to take them and include them in a commercial product as there might be legal risks.

Oh, also, I would strongly vote for continuing to use mercurial as the code repo! :-) In my experience of bitbucket I am absolutely happy with the platform, and would recommend it as an hg frontend.

Hm, I am pretty happy with Mercurial myself, but I somehow feel, we are almost alone with this few. I see many people asking for Git as this is simply much more popular and thus known to people.

Regards,

Kai

[Kai Kreuzer]

Hi Lars,

Well, pros and cons are always subjective, but here's my view:

Pros:

- Besides Apache is Eclipse a renowned place for open source software. Projects have a more "serious" and grown-up touch than other small hobby projects

- openHAB is anyhow very closely linked to Eclipse technologies, i.e. we already make use of Equinox, EMF, Xtext, Jetty, RCP etc. Being an Eclipse project might more easily lead to synergies with other projects as well.

- Eclipse provides the code a legally stable foundation. This makes it more interesting for companies to adopt the technology and to involve themselves in it. And I think this is the biggest chance - to become a place to collaborate for industry players, not just for individuals like us.

- At the same time, Eclipse guarantees that the code stays true open source that the community can rely on (i.e. there cannot be any hidden(?) commercial agenda as it is e.g. the case with OpenRemote).

- We can benefit from the marketing of the Eclipse Foundation and will hopefully gain even more momentum.

Cons:

- The project will be split into two parts, we will have to find a good separation not to confuse our users. My plan is to have framework refactoring / architecture discussions rather in the Eclipse project, while all "how to implement and use bindings" etc. should rather stay at openHAB.

- Moving code (refactoring namespaces, doing IP checks, setting up a project website) will mean quite a lot of work.

Just my two cents.

@Thomas: Anything more to add from your side?

Regards,

Kai

Am Aug 5, 2013 um 9:04 AM schrieb Lars Bretschneider <ope...@lb-automation.de>:

Hi Kai,

can you more explain (Pro´s nad Con's) of moving to Eclipse ? I´m not know to much about to be on eclipse ...

[Thomas Letsch]

Hi,

I can also only give my +1 to EPL, GIT (although I almost got used to hg :-) and the move to Eclipse foundation. Such a big umbrella means safety and publicity. 

Somehow we should get a clearer understanding what the move to EPL means for bindings that can not move to EPL (and stay e.g. at GPL). 

Luckily the one I work with (Homematic, EnOcean) are fine :-)

R.,

Thomas

[Kai Kreuzer]

Hi Thomas,

Somehow we should get a clearer understanding what the move to EPL means for bindings that can not move to EPL (and stay e.g. at GPL). 

Here's my suggestion: All code of openHAB (thus also these bindings) should move from GPL to EPL. I am currently not aware of any binding that includes a pure GPL library (i.e. one without a classpath exception like Calimero).

Regards,

Kai