[License Exception Request] [filepath-securejoin] [BSD and MPL-2.0] #1074
Description
For which CNCF project are you requesting exceptions?
Kubernetes
Are you an official maintainer of this project?
No
List of components requiring an exception
| Component | Upstream URL | License(s) | Purpose |
|---|---|---|---|
| filepath-securejoin | https://github.com/cyphar/filepath-securejoin | BSD-3-Clause and MPL-2.0 | Providing secure path construction functions |
Are all of the components mandatory dependencies for the project to function as intended?
Yes
If no, please explain
filepath-securejoin is already used in Kubernetes; the project intends to relicense parts of itself to MPL-2.0, see cyphar/filepath-securejoin#58 for details (some of the parts of the project that will be relicensed are used in Kubernetes).
There is a tracker to migrate some uses to Go 1.24+ os.Root, see kubernetes/kubernetes#131480; however it seems likely that some usage will remain. In particular Kubernetes will probably still end up with transitive dependencies on filepath-securejoin, and that means we don’t necessarily control the timeline of the version bump once the project is relicensed.
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
No response
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