[DNM] TSC: documentation if binary blobs are forbidden #41044
Conversation
mbolivar-nordic
requested review from
sylvioalves,
MaureenHelm,
carlescufi,
dleach02 and
galak
|
For those who need more context, please look at #38570 and the link to the https://docs.google.com/document/d/1heqcv7dzGvM5rA9xpTMW3kyKJLpZsl2Gjsmr5eqBje8/edit#heading=h.a4tmntn7vwmi for a vie for summary and options. At some point, there will be a vote for yes/no on binary blobs. And many thanks to @mbolivar-nordic for taking over this topic in the process working group. |
mbolivar-nordic
force-pushed
the
no-blobs
branch
from
f37814c to
91b22f4
Compare
| build system. | ||
|
|
||
| You are of course free to develop your own means of distributing blobs and | ||
| integrating them into the zephyr build system. |
There was a problem hiding this comment.
As discussed and requested at https://docs.google.com/document/d/16QU8OT4pnKuhszZHIYfsj1WInN-LRXjPdt87hxG5IRU/edit?disco=AAAATP9jSq0, please clarify whether direct links to optional blobs are allowed in git repositories hosted at https://github.com/zephyrproject-rtos In other words, can optional blobs hosted outside zephyrproject-rtos be not hosted but "version-controlled" inside zephyrproject-rtos for convenience.
I heard the espressif extension does something like this but for clearer documentation purposes there are much simpler examples like git submodules or opt-in west imports.
This reflects a policy decision requiring source code for any components distributed with the mainline zephyr repository and its modules. Describe how vendors may distribute their blobs via other means. Signed-off-by: Martí Bolívar <[email protected]>
mbolivar-nordic
force-pushed
the
no-blobs
branch
from
91b22f4 to
a7c4cff
Compare
| :zephyr_file:`zephyr/west.yml`. (This does not apply to situations such as open | ||
| source drivers communicating with proprietary firmware over well-defined | ||
| interfaces, e.g. a Bluetooth host implementation communicating over HCI with a | ||
| proprietary controller via UART.) |
There was a problem hiding this comment.
I think this still leaves room for interpretation, e.g.: what about a proprietary Bluetooth profile? Where Bluetooth is well-defined but the proprietary profile is not.
Also, how can there be a "hard" dependency when using only well-defined interfaces?
Would the "derivative work" concept help formalize this a bit?
|
@mbolivar-nordic close? :) |
This pull request formally documents a potential decision by the technical steering committee to forbid hard dependencies on binary blobs within mainline zephyr.
For details on the decision and other options, please see #38570.