Lizenzrichtlinie

Die Lizenzrichtlinie legt fest, was die Lizenz einer Abhängigkeit an zwei Stellen bedeutet:

Pull Requests. Der Lizenz-Scan bewertet die Lizenzen der Abhängigkeiten eines Pull Requests, und der Check fremforge/license-scan blockiert oder warnt.
Downloads. Die Paketrichtlinie bewertet die Lizenzen einer Datei in deiner Registry, bevor sie heruntergeladen werden darf.

Beide lesen dieselben Listen. Du öffnest sie unter Sicherheit › Richtlinien › Lizenzrichtlinie. Nur ein Owner der Organisation kann sie speichern.

Die Regeln

Einstellung	Pull Requests	Downloads
Erlaubte Lizenzen	Bestehen immer. Sie werden vom Schwellenwert nie blockiert oder markiert.	Bestehen.
Downloads: nur erlaubte Lizenzen	Keine Wirkung.	Jede Lizenz, die nicht auf der Erlaubt-Liste steht, wird abgewiesen. Erfordert mindestens eine erlaubte Lizenz.
Verbotene Lizenzen	Blockieren den Merge.	Abgewiesen.
Lizenzen mit Warnung	Befund mit Hinweischarakter.	Erlaubt, mit Warnung.
Unbekannte Lizenz	`allow`, `warn` oder `block` für eine Lizenz, die fehlt oder kein SPDX-Ausdruck ist.	Ebenso.
Mehrere Lizenzen	`all`: Jede Lizenz, die eine Komponente angibt, muss bestehen. `any`: Eine bestehende Lizenz genügt.	Ebenso, für einen Ausdruck wie `MIT OR GPL-3.0-only`.
Pull Requests: blockieren ab	Eine Lizenz, die auf keiner Liste steht, blockiert ab dieser Stufe und ist darunter nur ein Hinweis. Standard ist `restricted`.	Kein Schwellenwert.

Listeneinträge sind SPDX-Kennungen, eine pro Zeile, etwa MIT, LicenseRef-acme oder GPL-2.0-only WITH Classpath-exception-2.0. Groß- und Kleinschreibung spielt beim Abgleich keine Rolle. Eine Lizenz kann nur auf einer Liste stehen. Jede Liste fasst bis zu 100 Einträge. In einem Ausdruck wird jede Lizenz einzeln geprüft: Bei OR genügt eine bestehende Lizenz, bei AND muss jede Lizenz bestehen.

Wenn sich Pull Requests und Downloads noch unterscheiden

Bevor es diese Seite gab, hatte jeder Bereich eigene Listen, auf dem Tab Lizenzen und auf der Seite Paketrichtlinien. Migriert wurde nichts. Stimmen deine beiden Sätze bereits überein, zeigt die Seite sie als eine Richtlinie. Weichen sie voneinander ab, sagt die Seite das und füllt das Formular mit einem Vorschlag, bei dem für jeden Bereich die strengere Regel gewinnt:

die verbotenen Lizenzen beider Bereiche;
die Lizenzen mit Warnung beider Bereiche, ohne die verbotenen;
die strengere Aktion für unbekannte Lizenzen;
all für mehrere Lizenzen, wenn einer der beiden Bereiche all vorgab;
für Erlaubt-Listen: die Lizenzen, die auf beiden Listen stehen, oder die eine Liste, die Einträge hat. Eine Lizenz, die zugleich verboten ist oder warnt, fällt aus der Erlaubt-Liste.

Eine Erlaubt-Liste lässt sich nicht immer zusammenführen, ohne einen Bereich zu lockern. In solchen Fällen zeigt die Seite einen Hinweis. Beispiel: Eine Erlaubt-Liste für Downloads wird auch zur Erlaubt-Liste für Pull Requests, sodass diese Lizenzen danach auch in Pull Requests bestehen.

Bis du speicherst, ändert sich nichts.

Das Ergebnis vor dem Speichern sehen

Unter Was das Speichern ändert listet die Seite auf:

jede gespeicherte Einstellung, die sich ändert, für Pull Requests und für Downloads;
jede Lizenz, deren Ergebnis sich ändert, mit dem Ergebnis vorher und nachher in jedem Bereich. Geprüft werden gängige Lizenzen und jede Lizenz, die in deinen Pull Requests bereits vorkam.

Lizenzrichtlinie speichern wird nur für die Richtlinie angeboten, deren Änderungen gerade angezeigt werden. Wenn du das Formular bearbeitest, wähle zuerst Änderungen anzeigen. Ein Speichern, das nichts ändern würde, wird nicht angeboten.

Nicht Teil dieser Richtlinie

Ob Pull Requests gescannt werden. Lizenz-Scanning schaltest du unter Sicherheit › Richtlinien › Scanner ein oder aus.
Modus der Download-Sperre. Aus, Schatten oder Durchsetzen bleibt unter Paketrichtlinien.
Überschreibungen pro Repository für die Pull-Request-Regeln. Sie stehen unten auf dieser Seite, siehe Überschreibungen pro Repository.
Lizenzeinstellungen pro Pakettyp in einer Paketrichtlinie. Ein Pakettyp, der eigene Lizenzregeln setzt, behält sie. Die Seite listet diese Typen auf.
Ausnahmen für eine einzelne Komponente und Lizenz.

API

Endpunkt	Scope	Wirkung
`GET /orgs/{org}/licence-policy`	`policy:read`	Die Richtlinie (`unified: true`) oder `policy: null` mit dem Strenger-gewinnt-Vorschlag `proposal` und seinen `proposal_notes`. Außerdem die gespeicherten Felder jedes Bereichs und `package_policy_version`.
`POST /orgs/{org}/licence-policy/preview`	`policy:read`	Nur lesend. Die Änderungen pro Bereich und die Lizenzen, deren Ergebnis sich ändert.
`PUT /orgs/{org}/licence-policy`	`policy:write`	Speichert die Richtlinie in beiden Bereichen. Jedes Feld ist erforderlich. Sende die `package_policy_version`, die du gelesen hast.

curl -X PUT "https://frem.sh/_app/api/v1/orgs/acme/licence-policy" \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "allow": ["MIT", "Apache-2.0", "BSD-3-Clause"],
    "deny": ["AGPL-3.0-only", "SSPL-1.0"],
    "warn": ["MPL-2.0"],
    "allow_only_downloads": false,
    "unknown": "warn",
    "multiple": "all",
    "block_severity": "restricted",
    "package_policy_version": 7
  }'

Eine veraltete package_policy_version wird mit 409 policy-version-conflict abgewiesen. Eine Lizenz auf zwei Listen wird mit 400 licence-on-two-lists abgewiesen. Jedes Speichern wird als security.licence_policy.updated mit jedem geänderten Feld im Audit-Log erfasst. Die Download-Seite wird zusätzlich als package_policy.updated erfasst.

Die älteren Endpunkte funktionieren weiterhin und schreiben jeweils nur einen Bereich: PUT /orgs/{org}/code-security/licenses/settings und die Lizenzfelder von PUT /orgs/{org}/package-policy. Wenn du sie verwendest, zeigt die Seite die beiden Bereiche wieder als unterschiedlich an.

Lizenzrichtlinie

Die Regeln

Wenn sich Pull Requests und Downloads noch unterscheiden

Das Ergebnis vor dem Speichern sehen

Nicht Teil dieser Richtlinie

API

Verwandte Themen