Open Source Licences?

How does the cozify conform to the open source licences used on components used inside the box? 

- E.g openchain?

- Explains quite good busybox and u-boot

This is btw how one should communicate these with GNU.

Sorry for the late reply. We do not use any GPL licensed components.
There are only LGPL and MIT licensed libraries used without changes.

Best Regards,

Samppa / Cozify

And for the busybox, we will provide a link to download the sources of it.

br, Samppa / Cozify

1 person likes this

- Great response to busybox, do you intend to inform somewhere about it also as stated in

- U-Boot have also similar licences ( Actually quite many if one look at it with

- Many MIT aka permissive have this statement that one need to inform that one use it.

- I also assume you have dynamically linked to these components and not statically to prevent inheritance of the gpl licence to other code.

We do not use U-Boot or openchain.
The statements of usage of the LGPL and MIT licensed components will be provided too.

And yes, the components are dynamically linked/used.


Samppa / Cozify

Source codes for the busybox with patches can be downloaded from here:

MD5 checksum:

- Samppa / Cozify

So you say you aren't using "U-Boot 2015.01" to load and uncompress the linux kernel?

Actually you are right, we use it unchanged, and to our understanding that is "standalone normal use of the U-Boot services". The license states that:
'NOTE! This license does not cover the so-called "standalone" applications that use U-Boot services by means of the jump table provided by U-Boot exactly for this purpose - this is merely considered normal use of U-Boot, and does not fall under the heading of "derived work".'

If needed, we can of course provide the sources of it too.

Best Regards,

Samppa / Cozify 

The sources of U-Boot used can be downloaded from here:

MD5 checksum:


Samppa / Cozify

1) Good first steps in getting to compliance for licences. If you read the documents I added you need to inform somewhere what versions and componennts you use, and if one read the links i have included above simplest for you is perhaps add them to the android app. There is companies that help with how you should do this like validos/blackduck, ... ( I have no connection to them)

2) When working with open source and home antomation one come quickly into cyber security and comparing the files you contribted with the orginal, one can make conclusion that the cozify software platform is having a base from 2015 regarding kernels and deamons. And patching is not happening on these lower levels. Finding vulnabilities (CVE) from one find quite quickly what exist for holes. Using tools like shodan/metasploit or script kiddies like autospolit

Do I want to have devices in my network that have full knowledge on what I do and don't that haven't been patched for years?


If you claim that our firmware is from 2015 with no patch updates, this is certainly not the case. 

Looking at history, we update the hub software once in 1,5 months in average. This includes application updates (new features and bug fixes) and low-level firmware updates (kernel update patches, security patches, middleware updates) as needed.

We do take the security very seriously in general. The team has background in business-critical applications with strong security requirements, the architecture is verified together with external security experts and we pass 3rd party security audits once per year. We also embrace other means to keep up the level of security. As an example, we participated security hackaton arranged by Finnish Communications Regulatory Authority and were ranked as one of the most secure IoT devices at the time.

However, we are well aware that security is a continuous effort that never ends. If you (or someone else) believe you've found a true security risk in our product, we respectfully wish that you follow the white hat hacker ethics. In practice, first report to us directly via private channel so that we can react and if needed, fix the problem. 

Please do also bear in mind that vague and unprecise claims, comments and questions on our architecture or practices may in reality be phishing attempts. For the sake of security of the product and our clients, we always need to first treat them as such.

Regarding to requirements to open source licenses, we welcome your arguments and validate the means to better inform about them. Regarding different versions of the software and listing them remains to be best effort basis and unfortunately may not always be in sync.

Many thanks,
Kimmo Ruotoistenmäki
CEO, Cozify

I haven't done any hacking for this comment, I look on the files here provided by you busybox-1.24.1.tar.bz2 and compare the source code with one get from the original homepage of busybox and that version. Then looking up the software based on CVEE name and then one get's list of publicly known vulnerabilities. To this list vulnerabilities ends up after the grace period you talk about. So here one get known vulnerabilities like CVE-2016-6301  that can make the box dead, yes this one CVSS score not include remote execution bugs. As you state you have very good cyber security practices I assume you have report for these CVE's built in your build system and then maybe the only thing lacking is visibility of the mitigation done in regard to open source licences. 

Login or Signup to post a comment