Draft: Clarify the Apertis Policy regarding statically linked packages in target
1 unresolved thread
Add an Apertis Policy regarding Rust (and Go) packages in target.
Because these packages are statically linked, we need to ensure their dependencies fit the Apertis license expectations.
https://phabricator.apertis.org/T8768
Signed-off-by: Dylan Aïssi dylan.aissi@collabora.com
Edited by Dylan Aïssi
Merge request reports
Activity
Filter activity
requested review from @wlozano
160 160 Those exceptions should be documented as 161 161 [license exceptions]({{< ref "license-exceptions.md" >}}). 162 162 163 Rust and Go packages are special cases in the sense that they are statically 164 linked as opposed to other Debian packages where dynamic linking is the 165 standard according to the Debian Policy. 166 In other words, the built binary will contain code from its build dependencies. 167 This statically linked code can, of course, be distributed under different 168 licenses. 169 Consequently, Rust and Go packages aiming to be shipped in the `target` 170 component, must have all of their dependencies in `target`. 171 This requirement ensures that all binary packages in `target` contain code 172 fitting the Apertis license expectations. - Comment on lines +169 to +172
All the build dependencies? Based on task definition and comments there might be both, build dependencies that are use only to build the package but which code is not included in the final binary.
I guess that there are two alternatives
- Move all the build dependencies (more packages, higher probability of licensing issues)
- Move all the build dependencies which are code to be included in target (how we will know which ones?)
added 342 commits
-
ba37e5ff...c49ccbce - 341 commits from branch
master - 870d96da - Clarify the Apertis Policy regarding statically linked packages in target
-
ba37e5ff...c49ccbce - 341 commits from branch
Please register or sign in to reply