Draft: Clarify the Apertis Policy regarding statically linked packages in target

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

content/policies/license-expectations.md

@@ -161,6 +161,17 @@ unrestricted:
   Those exceptions should be documented as
   [license exceptions]({{< ref "license-exceptions.md" >}}).
 
+Rust and Go packages are special cases in the sense that they are statically
+linked as opposed to other Debian packages where dynamic linking is the
+standard according to the Debian Policy.
+In other words, the built binary will contain code from its build dependencies.
+This statically linked code can, of course, be distributed under different
+licenses.
+Consequently, Rust and Go packages aiming to be shipped in the `target`
+component, must have all of their dependencies in `target`.
+This requirement ensures that all binary packages in `target` contain code
+fitting the Apertis license expectations.
+
 ### hmi
 
 This component has the same usage and constraints as the target component.

[Walter Lozano]

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