# Defining Openness

**URL:** <https://dev.unawatch.com/t/defining-openness/32>\
**Category:** Feedback\
**Created:** [August 20, 2026, 4:05pm UTC](https://dev.unawatch.com/t/defining-openness/32 "2026-08-20T16:05:00Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![shatter\_poetry](https://avatars.discourse-cdn.com/v4/letter/s/6de8d8/32.png) [@shatter\_poetry](https://dev.unawatch.com/u/shatter_poetry)\
**Post date:** [August 20, 2026, 5:11pm UTC](https://dev.unawatch.com/t/defining-openness/32/2 "2026-08-20T17:11:47Z")

</div>

I think there’s no arguing with supplier agreements, outside of picking different parts or suppliers changing their mind. The proprietary binary blob industry is alive and well in modern hardware.

Maybe worth addressing the mobile apps as well?

One thing that I would suggest separating: there are ~3 different things bundled together.

1. being able to read the kernel
2. being able to build and flash a modified kernel
3. accepting patches

Would you consider read-only source access of non-3rd-party-proprietary/NDA covered source? Or to registered developers + NDA if required? No PR queue or support burden, no commitment to accept anything upstream, only unlocking a developers ability to self-serve the, “is it me or the platform” without taking up UNA dev team time.

Or, with this being a FreeRTOS base, a cheaper but still helpful publication would be the `FreeRTOSConfig.h` and the HAL headers.

---

_[View the full topic](https://dev.unawatch.com/t/defining-openness/32)._