[License Exception Request] [Hyperlight] [Older BSD like licenses]

[jsturtevant]

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
• Vendored component
• Build-time dependency
• 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 hyperlight-dev/hyperlight#831

Which of the following best describes how the components interact with the project's own code?

• 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

[jsturtevant]

Checking in on this request, what is the process for moving forward? Is there a meeting I can add this to an agenda? Thanks!

[joannalee333]

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

[jsturtevant]

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).

[jsturtevant]

Hi, just checking in on this request. How can I help move this forward?

[squillace]

Dear @joannalee333 you're right: it's a load of stuff! As we're well past Atlanta, what are the chances that we can pick this back up?

[joannalee333]

Hi there! This will be on the agenda for the next Legal Committee meeting in early March, followed by a Governing Board vote. I'll let you know soon if I have any questions as I continue reviewing the license file and scan results.

[jsturtevant]

Thank you for the update!

[joannalee333]

@jsturtevant and @squillace, our scans found the following strong copyleft files in the picolibc repository:

• https://github.com/picolibc/picolibc/blob/main/scripts/GeneratePicolibcCrossFile.sh (AGPL-3.0-or-later)
• https://github.com/picolibc/picolibc/blob/main/test/test-stdio/test-printf.c (GPL-2.0-or-later)
• https://github.com/picolibc/picolibc/blob/main/test/test-stdio/test-printf-testcases.h (GPL-2.0-or-later)

AGPL and GPL are not compatible Apache-2.0, so for the Legal Committee and Governing Board to consider granting an exception, there would need to be mechanism to ensure that the AGPL/GPL files are never ingested, executed, complied, or linked to by Hyperlight, its CI/CD pipelines, or downstream users.

One option is for Hyperlight to host its own modified fork of picolibc in which these AGPL/GPL files are deleted, then point to the modified fork instead of the upstream picolibc. I know it's more work to maintain a fork, but it's the most foolproof way to ensure that AGPL/GPL files never enter the Hyperlight environment. If this is too big a burden, there are other potential mechanisms we can explore and discuss, but I'm not sure to what extent the Legal Committee and Governing Board will be comfortable with those other mechanisms

[jprendes]

Hi @joannalee333 ,
Thank you for your answer.
A fork where we remove those 3 files is something we could do, as we could even automate the maintenance of it.
However, if the upstream project adds any new files that are not of the current licenses reviewed, are we expected to get an exception from you each time that happens?
Thanks!

[jsturtevant]

@joannalee333 Thanks. We are looking at options and will post back once we validate them. Those three files were explicitly called out by the project https://github.com/picolibc/picolibc?tab=readme-ov-file#license and we don't need them for our purposes.