-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support binary blobs / libraries and glue code in vanilla upstream Zephyr #7516
Comments
I think this is something we need to support in Zephyr. We probably need to figure out the rules and document them around what is considered an acceptable binary. For example:
|
I agree. Where do you think this document should live? Also, @galak I guess you are assuming option 3. and the multi-repo being there? |
This sounds somewhat similar to what is done here: https:/zephyrproject-rtos/zephyr/blob/master/ext/hal/esp/CMakeLists.txt |
I assume the doc would be part of our contributing guidelines, so something under doc/contribute/
Yes, I think something like option 3. |
Depends on #6770 |
Yes, indeed. I guess that flew under the radar. |
+1, I'm starting down this path right now to figure out how to integrate support for BLE on the NXP KW41 platforms. The BLE controller code is a binary blob that comes from NXP and won't be able to be hosted on the Zephyr repository due to legal restrictions. |
As an output of this ticket it would be nice to have a checklist that can be can be used to check easily if the component we want to introduced is compatible with zephyr policy and if not what is missing. |
this only applies if we actually are going to support that library as part of the project, in most cases I would say, no, we should not have any binaries included in the project itself, however we should enable this like with the ESP32 case. |
While I would personally argue that no binary objects should be included in the core repo, it's a lot more ambiguous how to handle additional repositories hosted under Ignoring the debate of open source or not, from a practical point of view it seems like this would place a significant legal burden on the Zephyr Project to validate that we can host and distribute said binary blob(s) and associated IP or files. The opinion of engineer X on Slack or over email saying "sure, it's fine to host blob Y" probably isn't sufficient for blobs that have EULA's associated with them, and would likely require written sign-off by appropriate IP owners. If IP owners are distributing binary blobs, there are almost certainly distribution terms attached. Some cases may be clear cut, but it seems like there would still need to be some sort of legal validation process or paper trail here to host binaries in |
Please retain the distinction between "Apache-2.0" and "OSS" in this discussion. They are very much not the same. I'm not clear on what "OSS" is intended to identify. It would perhaps be better to use the term OSI-approved license where open source beyond Apache-2.0 is being addressed. Note that GPL is OSI-approved. |
Repeating here the position I gave in TSC chat on 2019-06-12: Zephyr bills itself as Apache-2.0, which I believe to be true of the main repository. Through west it pulls in material from other repositories; at the moment these are hosted by zephyrproject-rtos, but in principle they could be external. It's not clear to me whether all material in those repositories is also Apache-2.0. As an open source developer I may need to protect against claims of potential IP theft by doing development on a clean system, where in theory I know the licensing of every bit on the machine. Question 0 does not appear in the description of this issue:
I personally prefer the default answer to this to be "Yes." Whether it is "yes" or "no", the answer (and its rationale) will inform the process leading to the remaining decisions, including whether/how non-Apache-2.0 content can be exposed as an opt-in post-installation step from the default installation, and how the licensing of any retrieved material is recorded and accessed. When I do |
+1 and I believe you've been considering only the default Examples: |
(Being a bit pedantic here, but I'd think we need to be much more precise in this discussion) @carlescufi would it be a good idea to rephrase the top comment, removing the "OSS" term, and stating clearly where it was meant to say "Apache-2 compatible" and where it refers to any other form of open source licensed SW? (if the intent was to include GPL or MPL in the discussion that would change things). |
No, I meant to say Apache-2.0. The The following command:
shows Zephyr, as of a recent master, has these licenses in its
I am informed by this. |
@pabigot ( sorry, I should have phrased my statement as "The main repo would contain Apache-2.0 compatible code" (irrespectively of the project overall being licensed as Apache2.0). It may have caused some confusion ) @pabigot Did you mean to say that you would like to restrict the main repo, and repos pulled by the default manifest, to contain only, Apache2.0 code?. And bar non-Apache2.0, but Apache2.0 compatible code? (Note, AFAIK, GPL are only some development scripts used, and some of the QEMU coverage code) |
I presented as a naive new user who assumed the Since Zephyr does not accurately describe the licensing of its contained material (at least in the place a naive user would expect to find it), perhaps that should be addressed. I am not a lawyer, but at least one previous employer would see those GPL scripts and say "No Zephyr on our networks", at least until somebody in upper management approved an exception, and I'd probably be in trouble if I'd gotten initial approval on the basis of claiming it to be Apache-2.0 (not "-compatible", since the company policy isn't concerned with somebody else's assessment of "compatible": they want a list of licenses). |
I am against it to host any binary objects or source code licensed under non-OSI approved (rather: "popular and widely-used or with strong communities") licenses in the zephyrproject-rtos GitHub organization, which could be compiled and linked to an Zephyr RTOS based application (firmware). I think it is up to vendor to host it, specially from legal perspective, and the project should not be easy-peasy-barrier-free regarding code licensed under non-OSI-"popular and widely-used or with strong communities" or incompatible license because of respect for those who bring and maintain their drivers mainline.
|
The TSC approved this and then a series of PRs have been bringing in support into the tree: |
Add the missing piece of documentation for binary blobs: the submission process. This follows the external source code process relatively close, but it is relatively simpler. The proposal includes a new issue template for requesting inclusion of blob(s) for a particular module. Fixes zephyrproject-rtos#7516. Signed-off-by: Carles Cufi <[email protected]>
Add the missing piece of documentation for binary blobs: the submission process. This follows the external source code process relatively close, but it is relatively simpler. The proposal includes a new issue template for requesting inclusion of blob(s) for a particular module. Fixes #7516. Signed-off-by: Carles Cufi <[email protected]>
This issue here is to describe what to do about Zephyr (i.e. the upstream vanilla distribution) containing either of the following:
CMakeLists.txt
custom-made for Zephyr and then any additional.c
and.h
files that are compiled when using the library)zephyr
repository (typically changes in existing in-tree code to accomodate for the binary blob and a new in-treeKconfig
file for the module)There are many types of binary blobs with different levels of integration requirements:
The following decisions have been found to be orthogonal to each other:
zephyrproject-rtos
GitHub organization?zephyrproject-rtos
GitHub organization?zephyr
repository?west config manifest.enable-blobs
)Proposals:
zephyrproject-rtos
GitHub organization, just like any other external project we host today, include the glue code (Apache v2) in thezephyr
repository and include the projects in the vanilla manifestzephyr
repository, and require users to pull binary blobs and accompanying build, headers and source code from a 3rd-party repository, not including any reference to it in the vanilla manifestThe text was updated successfully, but these errors were encountered: