@kaikreuzer, sorry for comment the but I’m really keen about OH2.
I’m looking for good system for SmartHome, and OH2 seems to be the ideal.
… then I found no BLE support.
“No way … in the end of 2017?”
I found bunch of hacks and promising two promising branches 1, 2
I read threads like good literature. This leads me to a merging two branch efford.
I grab a coffee and continue my reading. I weren’t in a hurry, I know that there will be happy ending - merging on master, so I keep my reading on.
No dear colegues there no happy end (yet, I hope).
Image about EclipseFoundation to bring down “professional open source project management frame” pathos.
Not entirely correct. To be distributed as an “official” add-on it must use an Eclipse License and be managed in the ESH or openhab2-addons repo. But for those add-ons that are unable or unwilling to do that the IoT Marketplace was developed where you can develop and own the add-on how you desire and users can access it through the IoT Marketplace.
Try to think about this problem broader. OH (ESH) is a home automation server, where lots of devices are supported by enthusiasts. The devices are made/designed not only for OH, therefore can be used somewhere else. The ESH rules put some serious restriction on where the code must be managed (read it as where the crucial device integration part is hosted) which leads to almost impossible use of the developed code for other projects (loosing crucial part of opensource approach - contribution to OH)! Furthermore, the other way around, already developed integration code which is hosted somewhere else cannot be used because of the same restrictions. This vastly will slow down OH evolvement from my perspective (or even objectively) and forces people to reinvent the wheel. Would I support this you ask? - Definitely not. The binding (low level integration part) I develop will not be as greedy/selfish as this and will be available to use by any other system.
All licenses have requirements one must follow in order to use the code. I’ve tons of code I use at home that I cannot release because I prefer an Apache/BSD style license but I have to use some library that uses a GPL v3 license. To release my code I would have to change the license for ALL of my program to the more restrictive GPL v3. So if I needed to release that code I would have to reimplement the libraries I’m using myself so I can apply a compatible license.
This is a problem across ALL open source projects.
Given that OH was originally built upon Eclipse OSGi container and ESH is an official Eclipse project, I don’t see how they could choose anything but the Eclipse License. And changing to some other license that does allow the inclusion of third-party APIs like discussed on that issue will take a TON of work, potentially rewrites of a significant amount of code if a license completely incompatible with the Eclipse license is chosen, and all of this would result in zero new functionality or bug fixes.
Therefore, the IoT Marketplace was created to support those who want to build and maintain their add-ons without those restrictions.
But at the end of the day, IMHO, if one feels so strongly about needing to drop Eclipse from the project, they may as well go off and start something new from scratch because I suspect that is what it would take.
People like to think that “oh, its open source I can use anything open source with it” but that simply is not the case.
I’m not saying what to do or giving any recommendations. I am just highlighting the issue which I have faced recently. OH is a great product created by good people. I’m just expressing my humble concern.
Does EPL license put any restrictions on the use of external libraries which are distributed under Apache v2? Afaik, EPL is compatible with Apache v2. Why can’t OH use Apache v2 (or any other compatible licenses) external libs?
I’m not a lawyer so I can’t really say. I think it is the Eclipse IP Policy that will be the actual governing document more so than the license. And unfortunately one of the first thing it says on page tree:
The EPL shall serve as the primary license under which the Eclipse Foundation shall
accept Content from contributors including, but not limited to, Members and Committers.
The full document is well worth reading but it seems to be pretty clear that if it is going to be distributed by Eclipse, it has to be Eclipse Licensed.
It can, so long as the license involved isn’t viral (e.g. GPL). Karaf is licensed under Apache license I think.
But I think the concern is that because the library in question was going to be directly exposed as an ESH API which I am guessing is a bridge too far as far as the EMO is concerned. I didn’t read that full thread but it really seemed like Kai really did try to find a way to make it work and still fall within the restrictions of the policy document.
I’m not the expert on any of this stuff. I’m just a user and have spent years reading reporting and white papers on open source licenses and the problems that can arise. I’m also an observer of organizations and I firmly believe that whenever you see something that seems ridiculous there is almost always a reason why and I then I start to did to find out. With just a little digging I almost always come up with a reason that was perfectly reasonable at the time. Decisions and restrictions like these seem arbitrary and stupid but they almost always have a reason they exist and a problem they are trying to solve.
I have proposed lots of options here (including an API bridge). None of them were considered.
In the end, it just sounds a bit ridiculous when contributors are “begging” to include their work (more than 6th months worth of coding) into an opensource project I thought it should be the other way around… e.g. opensource projects should be grateful to accept any meaningful contributions. But because of some governance rules, this is not happening.
Well that’s ESH decision, it is not for me to judge this. Eclipse Marketplace it is.
All I’ll add is “some governance rules” is how organizations like Eclipse stay on the right side of the law and avoid being sued. They are not decided upon arbitrarily nor lightly.
I thought it should be the other way around… e.g. opensource projects should be grateful to accept any meaningful contributions. But because of some governance rules, this is not happening.