Update license expectations document and move license docs to policies

The license expectations document is a little out of date. Tweak it a bit
and move it along with the license-exceptions document to policies.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

content/policies/images.md

@@ -132,9 +132,11 @@ each image type:
 | Type       | amd64 | armhf | arm64 | APT | OSTree | 
 | ---------- | ----- | ----- | ----- | --- | ------ |
 | Minimal    | ✅    | ✅    | ✅    | ✅  | ✅     |
-| Target     | ✅    | ✅    | ✅    | ✅  | ✅     |
+| Target     | ✅    | ✅ \* |       | ✅  | ✅     |
 | Base SDK   | ✅    |       |       | ✅  |        |
 | SDK        | ✅    |       |       | ✅  |        |
 | Sysroot    | ✅    | ✅    | ✅    |     |        |
 | Devroot    | ✅    | ✅    | ✅    | ✅  |        |
 | NFS        | ✅    | ✅    | ✅    | ✅  |        |
+
+\* Since v2020

content/designs/license-expectations.md → content/policies/license-expectations.md

 +++
-title = "Open source License expectations"
+title = "Open Source License Expectations"
 short-description = "Document license obligations for projects in Apertis"
 weight = 100
 aliases = [
@@ -12,10 +12,6 @@ outputs = [ "html", "pdf-in",]
 date = "2019-04-16"
 +++
 
-# License expectations
-
-## Introduction
-
 The license is an important element in open source projects as the license
 define acceptable use cases, user rights, and contribution guidelines. There
 are different ways to identify the license from the project source code such
@@ -23,7 +19,7 @@ as SPDX headers, the LICENSE file, and the COPYING file. However an open source
 project may contain files from other projects and may use different licenses
 for different files.
 
-### Apertis goals
+# Apertis goals
 
 Apertis aims to accomplish the following goals:
 
@@ -35,21 +31,22 @@ are not subject to licensing constraints that may conflict with the regulatory
 requirements of some intended use cases.
 
 In order to reach these goals, the below assumptions are made:
-- *licenses declared by open source projects are correct:* The software
+- **Licenses declared by open source projects are correct:** The software
   authors correctly document the licensing of their released software sources and
   that they have all the rights to distribute it under the documented terms.
-- *licenses verified by the Debian project are correct:* The package
+- **Licenses verified by the Debian project are correct:** The package
   distributors (that is, Debian maintainers and the FTP Masters team) check that
   the licensing terms provided by the software authors are open source using the
-  definitions in the [Debian Free Software Guidelines][DFSG] and ensure those
-  terms are documented in a canonical location (debian/copyright in the package
-  sources).
+  definitions in the
+  [Debian Free Software Guidelines](https://www.debian.org/social_contract#guidelines)
+  and ensure those terms are documented in a canonical location
+  (debian/copyright in the package sources).
 
-### Licensing constraints
+# Licensing constraints
 
 The version 3 of the GPL license was created to address the concern of users
 who were prevented from running modified code on their device, when the
-device was shipped with OSS.
+device was shipped with open source software.
 A common method for preventing users to run their
 own code is by using signature verification.  This practice is known as
 [Tivoization](https://en.wikipedia.org/wiki/Tivoization).
@@ -57,7 +54,7 @@ Those licensing rules are a
 constraint because in some application domains, it is a regulatory (or safety)
 requirement to ensure that the hardware runs verified software.
 
-## Ensuring continuous maintenance of open source licence documentation
+# Ensuring continuous maintenance of open source licence documentation
 
 Maintaining the open source licenses documentation is an incremental process:
 
@@ -82,28 +79,32 @@ save some work on those releases.
 In an ideal situation, regular checks of the whole archive would be automated to
 ensure nothing escaped the manual checks. While the Apertis maintainers are
 already manually checking packages, the automated whole-archive checks are not
-currently implemented. [Future improvements] presents a possible solution.
+currently implemented. [Future improvements]( {{< ref "#future-improvements" >}} )
+presents a possible solution.
 
-## Apertis Licensing expectations
+# Apertis Licensing expectations
 
-### General rules of the Apertis project and their specific constraints
+## General rules of the Apertis project and their specific constraints
 
-The [Debian Free Software Guidelines][DFSG] defines expectations for the
-licenses of the projects that are integrated in Debian. They serve as a base
-for Apertis policy. The DFSG can be read in the [Appendix] section of this
-document.
+The
+[Debian Free Software Guidelines](https://www.debian.org/social_contract#guidelines)
+defines expectations for the licenses of the projects that are integrated in
+Debian. They serve as a base for Apertis policy. The DFSG can be read in the
+[Appendix]({{< ref "#appendix" >}}) section of this document.
 
 On top of the DFSG expectations, Apertis defines additional rules for specific sections of its
-package repository which are described in [Apertis specific
-rules]. In particular, the sections in the Apertis package repository are meant
-to group the packages that are installed on images for target devices and should
-thus be free of [licensing constraints].
+package repository which are described in
+[Apertis specific rules]({{< ref "#apertis-repository-component-specific-rules" >}}).
+In particular, the sections in the Apertis package repository are meant
+to group the packages that are installed on images for target devices and
+should thus be free of
+[licensing constraints]({{< ref "#licensing-constraints" >}}).
 
 Debian packages in a repository are organized in components.
 A component is a group of packages sharing a common policy.
 A single image can incorporate packages from different components.
 
-### Apertis Repository component specific rules
+## Apertis Repository component specific rules
 
 The canonical source of Licensing information is this document. Each
 repository is listed here, with the rules that apply.
@@ -121,9 +122,10 @@ For current apertis releases, the following components exist:
 - development: contains packages useful for developers
 
 The license expectations for each of those components are defined below.
-Any package outside these expectations should be documented.
+Any package outside these expectations should be documented as
+[license exceptions]({{< ref "license-exceptions.md" >}}).
 
-#### target
+### target
 
 This component ships source packages producing binary packages used in images
 deployable on target devices. For a file in a binary package to be considered
@@ -145,20 +147,21 @@ unrestricted:
   exceptions.
   The [GCC Runtime Library Exception](https://www.gnu.org/licenses/gcc-exception-3.1-faq.html)
   covering `libgcc` is the main example.
-  Those exceptions should be documented.
+  Those exceptions should be documented as
+  [license exceptions]({{< ref "license-exceptions.md" >}}).
 
-#### hmi
+### hmi
 
 This component has the same usage and constraints as the target component.
 
-#### sdk
+### sdk
 
 This component ships source packages producing binary packages suitable for
 images deployable on SDK images. Since the packages hosted in this component
 are only meant for development purposes, no further requirement is imposed
 other than the DFSG ones.
 
-#### development
+### development
 
 This component provides the packages needed to build the packages in the
 `target` repository component but that are not meant to be installed on target
@@ -181,7 +184,7 @@ Since those packages are exclusively intended for a development purpose within
 the Apertis development team no further requirement is imposed other than the
 DFSG ones.
 
-## Auditing the license of a project
+# Auditing the license of a project
 
 Auditing the license of an imported package depends of the type of the project.
 
@@ -201,7 +204,7 @@ Some projects may not be packaged by Debian. In this case, the project source
 code should contain a document stating the license. Any project that do not
 provide license information should not be redistributed.
 
-## Documenting exceptions
+# Documenting exceptions
 
 For Apertis, the list of exceptions should mention:
 - The project location in Apertis mainly gitlab or OBS.
@@ -212,32 +215,26 @@ For Apertis, the list of exceptions should mention:
 - The date at which the exception was made
 - The name of the person who validated the exception
 
-The canonical source of Licensing exceptions is the [license exceptions]
-document.
+The canonical source of Licensing exceptions is the
+[license exceptions]({{< ref "license-exceptions.md" >}}) document.
 
 Apertis derived projects should provide an equivalent location for their
 specific exceptions.
 
-## Future improvements
+# Future improvements
 
 Manually checking licenses will not scale and may not be done in a deterministic
 way. Introducing automation is a key.
 
-FOSSology is a license reporting tool. It is described in the [License validation]
-document. Although we trust the developer to check license. The use of FOSSology could
-help ensure correct identification.
-
-An Apertis-specific FOSSology instance could be setup to scan on each commit.
-Upload of packages sources to GitLab could trigger a FOSSology scan in order to
-scan them before sources reaches the OBS repositories. The CI could then
-integrate the DEP-5 machine readable copyright information from FOSSology
-into the built package. This information could then be extracted and a
-bill-of-materials list generated for each artifact (images, container
-images, etc.).
+FOSSology is a license reporting tool. It is described in the
+[Automated License Compliance]({{< ref "automated-license-compliance.md" >}})
+document along with an approach to enable end-to-end tracking of licensing
+information. Although we trust the developer to check license, the use of
+FOSSology could help ensure correct identification.
 
-## Appendix
+# Appendix
 
-### The Debian Free Software Guidelines (DFSG)
+## The Debian Free Software Guidelines (DFSG)
 
 1. Free Redistribution
 
@@ -301,6 +298,3 @@ all other programs distributed on the same medium must be free software.
 The "GPL", "BSD", and "Artistic" licenses are examples of licenses that we
 consider "free".
 
-[DFSG]: https://www.debian.org/social_contract#guidelines
-[License validation]: license-validation.md
-[license exceptions]:  {{< ref "license-exceptions.md" >}}