Closed npal-cy closed 1 year ago
https://github.com/Infineon/btstack-integration/blob/master/LICENSE.txt this does not look like the apache license to me.
https://github.com/Infineon/btstack-integration/blob/master/LICENSE.txt this does not look like the apache license to me.
Hi @thedjnK, The LICENSE.txt (from https://github.com/Infineon/btstack-integration/blob/master/LICENSE.txt) is Infineon EULA, which presents in all assets.
All blobs which we added in zephyr/module.yml has license-path: ./LICENSE.txt. This is path to apache license license hal_infinen/modules/LICENSE.txt.
Let me know if there are some problem here. Regards, Nazar
How does one gain access to understandable sources so that can audit/bugfix the Apache-licensed code? What benefit is Apache license if blob itself is a black box and hides all functionality?
Would an alternative be to host actual source code and a tool to convert this into the desired format during build process?
How does one gain access to understandable sources so that can audit/bugfix the Apache-licensed code? What benefit is Apache license if blob itself is a black box and hides all functionality?
Would an alternative be to host actual source code and a tool to convert this into the desired format during build process?
See subsequent comment, for updates. This post is no longer relevant, but I am keeping it for history.
@eanderlind, the code that is compiled into these binary blobs will not be released to the public. It is proprietary. Our only intent is to deliver the fw blobs to the Zephyr community so that such users can add connectivity (BLE/Wi-Fi) support to their MCU projects via the CYW43xxx connectivity co-processors.
We are open to any reasonable license for the blobs that doesn't require the actual source code to be made available. In Mbed OS we released these under the "Open Binary License", but that is not an OSI approved license at this time.
Thank you,
Ian
Additionally, we are attempting to follow the process documented here: https://docs.zephyrproject.org/latest/contribute/bin_blobs.html. As shown in that section, the west blobs capability is meant for our use case of proprietary binaries distributed for a coprocessor. Re-reading that documentation, I am now reminded that we should be pointing at our Cypress/Infineon EULA for these blobs, and not Apache 2.0.
I will work with @npal-cy to update that to correctly point at https://github.com/Infineon/btstack-integration/blob/master/LICENSE.txt, rather than the generic Apache 2.0 license in hal_infineon (and Zephyr in general).
Thanks again,
Ian
The point 2.d.ii (and the others as well) mention that the host application can only be redistributed in binary code form only, does that mean that this can't be used for open source application? There's other bit in that license that seems a bit fuzzy, who's "you" in that context? The project? The developer? How does the "non-transferable" bit works when the project is used by a vendor SDK?
That EULA feels intimidating, clearly it works when licensing directly to a company developing a closed source product but it does not seem to quite work here.
The RPi SDK in comparison has a way simpler license for this in their SDK (https://github.com/georgerobotics/cyw43-driver/blob/main/LICENSE.RP), would it be possible to have something like that for this effort as well?
The linux-firmware license also seems to make more sense than this: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.cypress
The definition of "Host Application" and "Firmware" is also confusing, seems like the same software may fall to either depending on whether it's build for a Cypress SoC or not, does not make much sense.
@fabiobaltieri, re-reading 2.d.ii, I realized that it is meant to apply to the "firmware in binary form". That is, if we give you binary images, you cannot de-compile them, ship that de-compiled source, nor can you use the binary on any non-Cypress/Infineon device. You can contrast this directly with section 2.d.i, which applies to "... Firmware provided in Source Code form ...".
Since this RFC is about distributing a binary file, section 2.d.ii is the appropriate clause, however it has no impact on other firmware provided as source.
Thanks,
Ian
Since this RFC is about distributing a binary file, section 2.d.ii is the appropriate clause, however it has no impact on other firmware provided as source.
I see, so the binary will use this, the rest of the code whatever license is already in the module. The EULA file would live in the module/
directory though, so I think having wording there that refers to "host application" etc would be very confusing (I'm looking at https://github.com/zephyrproject-rtos/hal_infineon/pull/7)). Thinking that at minimum the file name/location should indicate that it only applies to the blobs (example: https://github.com/zephyrproject-rtos/hal_espressif/blob/zephyr/zephyr/module.yml#L12), but it'd be ideal if also the text only covers what it applies for.
Clause 4(i) could be an issue: "Except as otherwise expressly provided in this Agreement, you may not: (i) modify, adapt, or create derivative works based upon the Software; "
I'm not a lawyer, but I've understood "derivative works" to broadly mean statically linking in a library, makes the larger program a derivative work of the library. I don't know how this applies for a binary blob that runs on a separate processing unit.
I agree with @fabiobaltieri, that the mix of licensing terms/rights for source code and the binary code is confusing.
@keith-zephyr, as per @fabiobaltieri 's suggestion, we moved the license to zephyr/blobs/license.txt and the blob yml points at that. I believe this should make the intent clear here. Thanks for the feedback.
@keith-zephyr, as per @fabiobaltieri 's suggestion, we moved the license to zephyr/blobs/license.txt and the blob yml points at that. I believe this should make the intent clear here. Thanks for the feedback.
Where is zephyr/blobs/license.txt
? I don't see that file i n the hal_infineon repo or as part of https://github.com/zephyrproject-rtos/zephyr/pull/55014.
@keith-zephyr, the license lives in the hal_infineon repo. You can see this change in hal_infineon/pull/7.
This has been approved by the TSC
Origin
I would like to add blobs which need to enable support of AIROC CYW43xx Bluetooth/Wi-Fi Connectivity SoCs: -- CYW43012 -- CYW4343W -- CYW43439 -- CYW4373
The origin of these binary blobs is the Infineon repository:
Type
Module
hal_infineon: https://github.com/zephyrproject-rtos/hal_infineon/.
Purpose
CYW43xx devices required following sort of blobs:
Pull Request
hal_infineon: https://github.com/zephyrproject-rtos/hal_infineon/pull/7 bt driver: https://github.com/zephyrproject-rtos/zephyr/pull/55014
License
cc: @ifyall