cncf
[License Exception Request] [Hyperlight] [Older BSD like licenses]
For which CNCF project are you requesting exceptions?
https://github.com/hyperlight-dev/hyperlight
Are you an official maintainer of this project?
Yes
List of components requiring an exception
| Component | Upstream URL | License(s) | Purpose |
|---|---|---|---|
| picolibc | https://github.com/picolibc/picolibc | BSD-like and several others | provide libc functionality for writing c guests |
Are all of the components mandatory dependencies for the project to function as intended?
Yes
If no, please explain
Yes when building C based guests for hyperlight. It is possible to build guests without using libc. We currently have modified musl libc implementation which does not provide standard libc headers.
How will the components be included in or with the project's code and distributions?
- [ ] Incorporated code
- [x] Vendored component
- [x] Build-time dependency
- [x] Build and test tooling
- [ ] Install-time dependency
- [ ] Required upstream dependencies
- [ ] Other (please describe below)
If any of the above selections don't apply to all of the components listed in the table above, please explain
I wasn't 100% sure where this falls in the list above. We would use a git-submodule in the repo to enable users of our guest library (rust crate) to build c guest binaries that would incorporate piccolibc. We also would be using it during testing in our repo to build c guest binaries for testing. Proposed solution is https://github.com/hyperlight-dev/hyperlight/pull/831
Which of the following best describes how the components interact with the project's own code?
- [x] Static linking: e.g., compiled together with project code into a single binary
- [ ] Dynamic linking: e.g., compiled into a separate binary, running together with project code in a single address space at run-time
- [ ] Separate process: e.g., separate executable running in a different process space, interacting with project code only via mechanisms such as pipes, sockets, etc.
- [ ] Network interaction only: e.g., logically separated over a network and communicating only via mechanisms such as network API call, exchanging JSON data, etc.
- [ ] Other (please describe below)
If any of the above selections don't apply to all of the components listed in the table above, please explain
No response
Will any of the components be modified?
No
If yes, please specify which components will be modified, and briefly describe the purpose and nature of the modifications.
No response
Will the project be seeking to contribute the modifications back to the upstream project?
None
Checking in on this request, what is the process for moving forward? Is there a meeting I can add this to an agenda? Thanks!
Hi there. There are more than 2000 lines of license text that need to be reviewed and summarized before we can present this to the Legal Committee, so this is going to take some time. Realistically, we won't be able to present this to the Legal Committee until sometime after KubeCon Atlanta. After the Legal Committee reviews and votes, then it will be presented to the Governing Board for its approval.
As CNCF staff does its preliminary review, we'll reach out if we have any questions. Thanks
Thanks for the update and all makes sense! As additional information we found that the Zephyr project (Linux foundation) redistributes the library (https://docs.zephyrproject.org/latest/develop/languages/c/picolibc.html).