Licencje open source w projektach UAV — od repozytorium do produktu

Licencja open source nie jest etykietą „wolno używać bez ograniczeń”. Jest zestawem uprawnień warunkowych: pozwala używać, kopiować, modyfikować i rozpowszechniać utwór w zakresie opisanym w tekście, pod warunkiem wykonania określonych obowiązków. W UAV obowiązki mogą powstać przy dostarczeniu firmware razem z flight controllerem, obrazu companion computera, aplikacji GCS, aktualizacji OTA albo plików produkcyjnych kontraktorowi.

Nie istnieje jedna „licencja projektu” obejmująca automatycznie wszystkie pliki. Repozytorium może zawierać kod GPL, permissive libraries, vendor headers, binary blobs, fonty, mapy, modele ML, pliki CAD i dokumentację na odrębnych warunkach. Analiza zaczyna się od dokładnej wersji i provenance każdego składnika konkretnego release.

Zastrzeżenie: to techniczny opis procesu zgodności licencyjnej, nie indywidualna porada prawna. Przy produkcie komercyjnym, zamkniętym module, spornej granicy utworu zależnego albo dystrybucji w wielu jurysdykcjach potrzebna jest analiza prawnika na podstawie dokładnych plików i sposobu dostarczenia.

Spis treści#

Najpierw zdarzenie, potem obowiązki
Mapa artefaktów UAV
Nie wystarczy nazwa licencji
Permissive: MIT i BSD
Apache License 2.0
MPL 2.0: copyleft na poziomie pliku
LGPL: biblioteka i możliwość modyfikacji
GPL: Corresponding Source
GPLv3 i Installation Information
Linking, IPC i granica programu
Firmware dostarczany ze sprzętem
SaaS, telemetria i AGPL
ArduPilot, PX4, Betaflight i INAV
Hardware, PCB i CAD
Dokumentacja, dane, mapy i modele
SDK, HAL, toolchain i binary blobs
Patenty, znaki i nazwy
Zgodność i kombinowanie licencji
SPDX i REUSE per file
SBOM i evidence wydania
Release gate
Pakiet Corresponding Source
Obsługa zmian i zapytań
Typowe błędy
Powiązane tematy
Przypisy

Najpierw zdarzenie, potem obowiązki#

Obowiązki licencyjne zależą od działania. Należy opisać scenariusz:

użycie i modyfikacja wewnątrz jednej organizacji;
przekazanie kodu lub binary osobie zewnętrznej;
dostarczenie urządzenia z preinstalowanym firmware;
aktualizacja wysłana klientowi;
aplikacja w sklepie;
udostępnienie obrazu kontenera;
usługa sieciowa bez przekazania kopii;
przekazanie kontraktorowi lub integratorowi;
opublikowanie fork/repozytorium;
sprzedaż prawie identycznego produktu przez OEM.

To samo źródło może nie tworzyć obowiązku publikacji podczas użycia prywatnego, a tworzyć go przy dystrybucji object code. Mozilla wyjaśnia dla MPL, że obowiązki dystrybucyjne powstają przy dostarczeniu kopii poza organizację; kod serwerowy niewysyłany użytkownikowi nie jest w tym sensie dystrybuowany, natomiast JavaScript wysłany do przeglądarki jest [1]. Dla GPL/AGPL trzeba czytać ich własne definicje i warunki.

Nie zakładamy, że kontraktor „jest wewnętrzny”. Status zależy od relacji prawnej i przepływu kopii. Umowa NDA nie anuluje praw odbiorcy wynikających z licencji, jeśli dodatkowe ograniczenie jest sprzeczne z jej warunkami.

Proces powinien rejestrować distribution event: kto dostarcza, komu, co dokładnie, w jakiej formie, pod jakimi dodatkowymi warunkami i w jakim kraju. Dopiero do tej konfiguracji buduje się obligations matrix.

Mapa artefaktów UAV#

Typowy system obejmuje:

bootloader
flight-control firmware
RTOS + drivers + protocol libraries
ESC / payload / radio firmware
companion-computer OS and containers
GCS desktop/mobile/web
cloud/backend
mobile SDKs and vendor blobs
ML models and datasets
PCB schematics/layout/gerbers
mechanical CAD and manufacturing files
documentation, diagrams, fonts and icons
configuration and parameter files

Każdy artefakt ma osobny dependency graph i kanał dystrybucji. Firmware może być GPL, GCS BSD, backend proprietary, a CAD bez żadnej udzielonej licencji. Fakt, że są w jednym produkcie, nie daje jednego prostego wyniku.

Granice techniczne trzeba mapować do artefaktów dostarczanych odbiorcy:

statycznie/dynamicznie linked executable;
osobny process komunikujący się przez standard protocol;
obraz filesystem zawierający wiele packages;
firmware blob ładowany do peryferium;
source generator i generated output;
header-only library;
patch set na upstream;
build container/toolchain.

Nie analizuje się wyłącznie top-level manifest. Submodules, vendored code, generated sources, package lockfiles i firmware blobs również trafiają do produktu.

Nie wystarczy nazwa licencji#

GPL bez wersji jest niepełne. Trzeba rozróżnić:

GPL-2.0-only;
GPL-2.0-or-later;
GPL-3.0-only;
GPL-3.0-or-later;
licencję z wyjątkiem;
dual license MIT OR Apache-2.0;
multi-license expression Apache-2.0 AND BSD-3-Clause.

Słowa or later muszą wynikać z notice właściciela praw, nie z domysłu. Tekst GPLv3 w repo nie zmienia automatycznie plików opisanych jako GPLv2-only.

Źródła identyfikacji w kolejności:

per-file copyright/license header;
LICENSES/ i machine-readable SPDX identifiers;
manifest package;
top-level LICENSE/COPYING;
dokumentacja projektu;
scan jako wskazówka do review.

Brak pliku LICENSE nie oznacza public domain. Domyślnie prawa autorskie pozostają, a pobranie kodu nie daje automatycznie prawa do redystrybucji. Taki składnik ma status NOASSERTION/unknown i blokuje release do czasu wyjaśnienia.

SPDX License List publikuje standardowy short identifier, pełną nazwę, tekst i canonical URL dla licencji oraz exceptions [2]. Użycie identyfikatora redukuje literówki, ale nie zastępuje odczytania tekstu.

Permissive: MIT i BSD#

Licencje permissive zwykle pozwalają używać, modyfikować i dystrybuować source/binary, także w produkcie proprietary, pod warunkiem zachowania notice, tekstu licencji i disclaimer zgodnie z konkretną licencją.

Nie należy mówić „bez obowiązków”. Release powinien:

zachować copyright notices;
dołączyć wymagany tekst licencji;
spełnić warunki dotyczące binary/documentation;
nie sugerować endorsement nazwiskiem autora, jeśli klauzula tego zabrania;
respektować osobne znaki towarowe i patenty;
zachować per-file notices przy redystrybucji source.

MIT i BSD-2-Clause/BSD-3-Clause nie są tym samym tekstem. BSD-3-Clause dodaje zakaz użycia nazw autorów/contributors do promowania derivative products bez zgody. Custom „BSD-like” może mieć dodatkową klauzulę ograniczającą zastosowanie i nie być open source.

Proprietary wrapper wokół permissive library może pozostać proprietary, ale kopia pierwotnego składnika nadal jest przekazywana na jego warunkach. Third-party notices muszą trafić do produktu, dokumentacji lub innego właściwego miejsca zgodnie z tekstem.

Apache License 2.0#

Apache-2.0 jest permissive, lecz ma więcej jawnych mechanizmów niż MIT/BSD. Oficjalny tekst wymaga przy redystrybucji m.in. kopii licencji, prominent notices w zmienionych plikach, zachowania właściwych copyright/patent/trademark/attribution notices i obsługi NOTICE, jeśli upstream go zawiera [3].

Licencja zawiera grant patentowy od contributors dla określonych claims oraz klauzulę zakończenia tego grantu przy wszczęciu określonego patent litigation dotyczącego Work/Contribution [3]. Nie jest to gwarancja, że produkt nie narusza patentów osób trzecich.

Compliance package:

LICENSE (Apache-2.0)
NOTICE upstream + dozwolone własne notices
lista zmodyfikowanych plików / prominent change notices
copyright/attribution retained
source/object distribution record

NOTICE nie jest miejscem na dowolne dodatkowe warunki ograniczające licencję. Oficjalny tekst wskazuje, że NOTICE ma charakter informacyjny i nie modyfikuje License [3].

Apache-2.0 ma istotne kwestie zgodności z wersjami GPL; nie wolno uogólniać „Apache pasuje do GPL”. Trzeba analizować dokładne wersje oraz kierunek połączenia, korzystając z oficjalnych wyjaśnień i review prawnego.

MPL 2.0: copyleft na poziomie pliku#

MPL 2.0 jest file-level copyleft. Mozilla opisuje, że modyfikacje plików objętych MPL pozostają dostępne pod MPL, natomiast nowe pliki bez kodu MPL mogą być częścią większego dzieła na innych warunkach [1].

Przy zewnętrznej dystrybucji executable z kodem MPL należy poinformować odbiorcę, gdzie uzyskać Source Code objętych części. Zmienione MPL files muszą być udostępnione w zakresie wymaganym licencją. Larger Work może mieć własną licencję, o ile nie ogranicza praw odbiorców do covered code.

Granica pliku daje praktyczną architekturę:

upstream_mpl_file.c     → MPL, zmiany udostępniane
new_proprietary_module.c → możliwy odrębny status
combined executable      → notices + source route dla MPL portions

Nie jest to zachęta do sztucznego przenoszenia kodu tylko dla uniknięcia obowiązków. Definicje Covered Software i Modifications z tekstu MPL rozstrzygają więcej niż rozszerzenie pliku.

Mozilla dopuszcza machine-readable SPDX header jako mechanizm notice zgodny z celami MPL w społecznościach używających takiej praktyki [1].

LGPL: biblioteka i możliwość modyfikacji#

LGPL jest projektowana dla libraries i pozwala w określonych warunkach łączyć bibliotekę z szerszym application. Dokładne obowiązki zależą od wersji LGPL i sposobu linkowania.

Typowe kwestie do sprawdzenia:

czy modyfikowano samą bibliotekę;
czy executable używa dynamic linking;
czy static linking wymaga dostarczenia relinkable object files lub innego mechanizmu;
czy użytkownik może zastąpić bibliotekę zmodyfikowaną wersją;
czy reverse engineering for debugging modifications nie jest kontraktowo zabronione w zakresie wymaganym licencją;
czy dołączono license/notices i source biblioteki;
czy użyto LGPLv2.1 czy LGPLv3.

Na embedded target dynamic linking może być niemożliwe. Nie znaczy to automatycznie, że LGPL library jest zabroniona, ale compliance design trzeba wykonać przed implementacją. Późniejsze wygenerowanie relinkable objects dla optymalizowanego firmware może być trudne lub niemożliwe bez odtworzenia toolchain.

Header-only/template code i inline functions wymagają dodatkowej analizy, bo kod może zostać włączony do executable. Nie zakładamy, że „to tylko header”.

GPL: Corresponding Source#

GPL jest silnym copyleft. Przy przekazywaniu object code covered work trzeba zapewnić Corresponding Source w jednej z form dozwolonych przez daną wersję i sposób dystrybucji. GPLv3 definiuje Corresponding Source szerzej niż pliki napisane przez integratora: obejmuje source potrzebny do generowania, instalowania i wykonywania object code oraz kontrolowania tych działań, z określonymi wyjątkami System Libraries i narzędzi ogólnego zastosowania [4].

Praktyczny pakiet może potrzebować:

dokładnego upstream source;
własnych modifications i patches;
submodules oraz vendored dependencies;
konfiguracji target/board;
build scripts i generatorów;
linker scripts;
interface definition files;
source do włączonych bibliotek objętych obowiązkiem;
instrukcji build/install;
informacji o użytej wersji toolchain;
odpowiednich notices i tekstu licencji.

Link do bieżącego upstream main nie wystarcza, jeśli urządzenie ma starszy commit, prywatne patches i inną konfigurację. Odbiorca ma otrzymać source odpowiadający binary, nie podobny projekt.

Nie trzeba publikować sekretów, które nie są Corresponding Source, lecz ich usunięcie nie może czynić źródła pozornym. Jeśli binary wymaga podpisu do instalacji na User Product, GPLv3 Installation Information może mieć znaczenie.

Written offer ma konkretne warunki i okres obowiązywania zależne od wersji GPL oraz formy dystrybucji. „Napisz e-mail, może kiedyś wyślemy” nie jest procesem zgodności. Bezpieczniejsza operacyjnie bywa jednoczesna, działająca dostępność source i archiwum release, ale trzeba spełnić dokładny tekst wybranej opcji.

GPLv3 i Installation Information#

GPLv3 Section 6 wprowadza pojęcie Installation Information dla object code przekazywanego w, z lub specjalnie do użycia w User Product, gdy przekazanie następuje jako część transakcji przenoszącej possession/use na recipienta w sposób opisany licencją [4]. Ocena, czy konkretny UAV/flight controller jest User Product i czy warunki mają zastosowanie, wymaga analizy faktów.

Installation Information może obejmować metody, procedury, authorization keys lub inne informacje potrzebne do instalacji i uruchomienia zmodyfikowanego object code. Nie należy projektować secure boot i key management bez wcześniejszego ustalenia konsekwencji licencyjnych.

Należy rozdzielić:

key używany do weryfikacji oficjalnej aktualizacji;
mechanizm pozwalający użytkownikowi zainstalować własny build;
device identity/secrets niezwiązane z prawem instalacji;
safety restrictions dozwolone przez tekst licencji;
warranty/support po modyfikacji.

GPLv3 nie wymaga akceptowania odpowiedzialności za zmodyfikowany firmware. Projekt może oznaczać stan modyfikacji i odmówić warranty/support w granicach prawa i licencji. Nie może jednak nakładać dodatkowych ograniczeń odbierających prawa przyznane licencją.

Linking, IPC i granica programu#

Pytanie „czy linkowanie tworzy utwór objęty GPL” nie ma uniwersalnej odpowiedzi technicznej. Static linking, dynamic linking, plugins, shared memory, RPC, pipes, MAVLink i network API są faktami, ale kwalifikacja prawna zależy od projektu, zależności, komunikacji i wersji licencji.

Analiza boundary dokumentuje:

procesy i address spaces;
build/link dependencies;
headers i generated interfaces;
czy moduły są projektowane wyłącznie dla siebie;
semantykę i intimacy danych;
lifecycle i dystrybucję razem/osobno;
możliwość niezależnego użycia;
plugin contract;
stanowisko licencjodawcy i wyjątki.

Standardowy protocol może wspierać argument separacji, ale nie tworzy automatycznej „bezpiecznej granicy”. Proprietary companion app komunikująca się z autopilotem przez MAVLink jest inną sytuacją niż statycznie dołączony moduł w tym samym firmware.

Nie wolno projektować architektury na podstawie internetowego hasła „IPC zawsze bezpieczne” albo „każde API jest derivative”. Dla krytycznej granicy przygotowuje się diagram i dokładne artefakty do review prawnego.

Firmware dostarczany ze sprzętem#

Sprzedaż płytki lub kompletnego UAV z wgranym firmware przekazuje kopię object code. Brak osobnego downloadu nie usuwa obowiązków. Release record powinien wiązać serial/partię z hash firmware i compliance bundle.

Minimalny flow:

firmware build ID
→ SBOM/licence scan
→ exact source archive
→ notices/license bundle
→ installation/source instructions
→ device/packaging/documentation link
→ retained release evidence

Source URL powinien być stabilny tak długo, jak wymaga licencja i polityka produktu. QR na opakowaniu może być wygodny, ale usunięcie hostingu po roku może naruszyć zobowiązanie. Organizacja musi mieć ownera i retencję niezależną od pojedynczego konta dewelopera.

Firmware dostawcy komponentu jest osobnym składnikiem. Prawo do jego redystrybucji nie wynika z prawa zakupu hardware. Trzeba zachować EULA/redist terms i ograniczenia channel/target.

RMA i refurbished device również mogą być distribution events. Compliance nie jest jednorazowym zadaniem pierwszej partii.

SaaS, telemetria i AGPL#

Zwykła GPL zasadniczo wiąże istotne obowiązki z przekazywaniem kopii, a nie samym uruchamianiem zmodyfikowanego programu na własnym serwerze. AGPLv3 zawiera dodatkowy mechanizm dotyczący zdalnej interakcji użytkowników przez sieć z zmodyfikowanym programem. Nie wolno przenosić wniosków między GPL i AGPL.

System UAV może rozdzielać:

backend niewysyłany klientowi;
container przekazywany on-premise;
JavaScript/WASM wysyłany do przeglądarki;
mobile app;
edge/companion image na urządzeniu klienta;
server plugins i agents.

Każdy kanał ma inne artifacts. Backend może nie być distributed, ale frontend jest. Container dla klienta jest kopią, nawet jeśli marketing nazywa go „usługą”.

AGPL dependency w backendzie wymaga szczegółowej oceny network interaction i modified version. SaaS exception, dual commercial license albo odrębna implementacja mogą zmieniać wynik — dokładne grants muszą trafić do rejestru.

ArduPilot, PX4, Betaflight i INAV#

Stan repozytoriów sprawdzony 16 sierpnia 2026 r.:

Projekt	Top-level plik licencyjny	Znaczenie praktyczne
ArduPilot	`COPYING.txt` zawiera GPLv3	dystrybucja własnego firmware wymaga analizy GPLv3 i wszystkich składników
PX4-Autopilot	top-level `LICENSE` zawiera BSD 3-Clause	rdzeń ma permissive warunki top-level, ale każdy dependency/file nadal wymaga sprawdzenia
Betaflight	top-level `LICENSE` zawiera GPLv3	modyfikowany i dystrybuowany firmware wymaga procesu Corresponding Source
INAV	top-level `LICENSE` zawiera GPLv3	analogicznie trzeba archiwizować exact source/build dla wydania

Źródłem są oficjalne pliki repozytoriów [5][6][7][8]. Tabela nie jest zapewnieniem, że każdy plik lub submodule ma ten sam status. Licencje mogą się zmienić; release używa commit-specific snapshot.

Fork ArduPilot/Betaflight/INAV w urządzeniu nie staje się compliant przez podanie linku do upstream. Jeśli producent ma własne board files, drivers i patches w binary, odpowiadający source musi obejmować te zmiany w wymaganym zakresie.

PX4 pod BSD-3-Clause ułatwia integrację proprietary, ale nadal wymaga zachowania notices i disclaimer. Należy sprawdzić NuttX, submodules, third-party directories, board/vendor code i narzędzia osobno.

Hardware, PCB i CAD#

Licencja software nie obejmuje automatycznie schematu, PCB layout, Gerberów, modelu 3D ani rysunku mechanicznego. Pliki mogą być:

bez udzielonej licencji;
na Creative Commons;
na CERN Open Hardware Licence;
na Solderpad/TAPR OHL;
pod custom terms producenta EDA;
częściowo oparte na reference design z własnymi warunkami.

Open source firmware nie daje prawa kopiowania logotypu ani layoutu płytki. „Hardware is open” musi wskazywać dokładną licencję i preferred source form: native CAD, libraries, constraints, BOM i fabrication outputs.

Modele komponentów w EDA mogą mieć licencję inną niż projekt. Footprint pobrany z portalu producenta może pozwalać na użycie w design, ale nie na redystrybucję biblioteki. Compliance inventory rozdziela final fabrication file i bundled source library.

CERN-OHL ma warianty permissive, weakly reciprocal i strongly reciprocal; sam skrót CERN OHL jest niepełny. SPDX License List zawiera osobne identyfikatory tych wersji [2].

Dokumentacja, dane, mapy i modele#

Kod, dokumentacja, fotografia, diagram i dataset są osobnymi utworami. GPL dla firmware nie daje prawa do republiki datasheetu producenta. CC BY dla tekstu nie obejmuje znaku towarowego widocznego na grafice poza zakresem licencji.

Należy rejestrować:

documentation license;
image/media license i attribution;
database rights oraz terms API;
map tiles/data license i cache rules;
font license oraz embedding/subsetting;
dataset/model weights/code licenses osobno;
privacy/consent dla recorded data;
export/classification restrictions niezależne od copyright.

Model ML może mieć permissive code, research-only weights i dataset bez prawa redystrybucji. pip install nie pokazuje całej sytuacji.

Generated documentation ma source form, templates, fonts i diagrams. Apache-2.0 definiuje Object form szeroko, obejmując m.in. generated documentation i conversions, co wpływa na zachowanie notices [3].

SDK, HAL, toolchain i binary blobs#

Vendor SDK często zawiera miks:

permissive headers/examples;
redistributable libraries;
confidential material;
firmware blobs tylko dla określonych chips;
code generators;
device packs;
documentation bez prawa publikacji.

Top-level LICENSE vendor repository może mieć carve-outs. Każdy katalog third_party, CMSIS, Drivers, Middlewares, lib, firmware wymaga manifestu.

Toolchain użyty wyłącznie do kompilacji nie zawsze jest częścią dystrybuowanego produktu, ale jego runtime libraries mogą być linked. GCC/newlib/compiler-rt mają własne exceptions i notices. Build container może być przekazywany jako część Corresponding Source i zawierać setki packages.

Binary-only blob w GPL project może być legalnie dystrybuowany na osobnych warunkach albo stanowić problem — nie rozstrzyga tego rozszerzenie .bin. Potrzebne są origin, license grant, sposób połączenia i upstream policy.

Generated code dziedziczy warunki generatora tylko wtedy, gdy licencja tak stanowi lub output zawiera chroniony materiał. Nie zakładamy ani „zawsze proprietary”, ani „zawsze taki jak generator”.

Patenty, znaki i nazwy#

Copyright license nie zawsze udziela patent license. Apache-2.0 robi to jawnie w określonym zakresie contributions [3]; MIT/BSD zwykle nie mają tak szczegółowego tekstu patentowego. Brak patent clause nie oznacza automatycznie braku jakichkolwiek praw, ale zwiększa potrzebę analizy.

Open source license zwykle nie udziela prawa do użycia trademark, product name lub logo poza opisowym wskazaniem pochodzenia/notices. Fork nie powinien sugerować oficjalnego statusu.

Checklist marki:

nazwa produktu i domena;
logo na splash screen/obudowie;
compatibility claims;
użycie nazwy upstream w marketingu;
certification marks;
zdjęcia producenta.

Patent retaliation clause może wpłynąć na strategię sporu. Compliance review i freedom-to-operate są osobnymi procesami.

Zgodność i kombinowanie licencji#

License compatibility pyta, czy można spełnić wszystkie warunki jednocześnie dla planowanej kombinacji i dystrybucji. Nie jest cechą pojedynczej pary nazw niezależną od wersji.

Macierz dependency zawiera:

component + version/commit
license expression
link/interaction type
modified?
distributed artifact
recipient/channel
obligations
compatibility decision + counsel/reference

Szczególnie wymagają review:

GPLv2-only z Apache-2.0;
GPL z proprietary linked code;
LGPL static linking na embedded;
MPL files w Larger Work;
OpenSSL/crypto exceptions;
kernel modules/drivers;
plugins z project-specific exception;
code na kilku licencjach OR/AND;
custom non-commercial/no-military terms.

Licencja zabraniająca zastosowań wojskowych, komercyjnych albo określonych branż nie spełnia klasycznej definicji open source, nawet jeśli source jest publiczny. W półmilitarnym portalu to krytyczne: source available nie znaczy open source ani prawo użycia w każdym celu.

Dual license GPL OR commercial daje wybór tylko pod warunkami właściciela praw. Zakup licencji komercyjnej powinien być powiązany z wersją, entity, products, field of use, sublicensing i okresem wsparcia.

SPDX i REUSE per file#

Machine-readable header:

// SPDX-FileCopyrightText: 2026 Example Robotics
// SPDX-License-Identifier: Apache-2.0

Złożone expression:

SPDX-License-Identifier: MIT OR Apache-2.0
SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note

Nie tworzy się własnego identyfikatora GPL3. Używa się SPDX License List i poprawnej składni [2]. LicenseRef-... służy własnym/niezidentyfikowanym tekstom, które również trzeba przechować.

REUSE Specification opisuje maszynowo czytelne copyright/licensing information per file i katalog LICENSES/ z tekstami [9]. To pomaga w repo mieszanym, gdzie top-level LICENSE jest za mało precyzyjny.

Praktyczna struktura:

LICENSES/
  Apache-2.0.txt
  GPL-3.0-only.txt
  BSD-3-Clause.txt
REUSE.toml
src/...
third_party/...

CI uruchamia linter REUSE/SPDX oraz scanner dependencies. Wynik scanner nie jest decyzją prawną; unknown trafia do kolejki review, a false positives są dokumentowane.

Per-file provenance zawiera upstream URL, commit, original path, imported_at, local modifications i reviewer. git blame nie zastępuje danych o licencji.

SBOM i evidence wydania#

SBOM identyfikuje komponenty i zależności; license manifest dodaje declared/concluded licenses oraz obligations. NTIA minimum elements obejmują supplier, component name, version, identifiers, dependency relationship, SBOM author i timestamp [10].

Dla każdego release przechowujemy:

SBOM SPDX/CycloneDX;
exact dependency lock/commit;
license scan raw output;
reviewed component inventory;
per-file license data;
notices bundle;
source archive hash;
binary hash;
build provenance;
distribution channels;
approvals i exceptions;
source publication URL oraz retention deadline.

NOASSERTION jest uczciwsze niż zgadnięta licencja, ale zwykle blokuje zewnętrzny release. SBOM bez transitive dependencies daje fałszywą kompletność.

Licencja jest zależna od wersji. library X = MIT nie wystarcza, jeśli release używa fork z plikami GPL. Component ID powinien wskazać commit/package checksum.

Release gate#

Release compliance nie jest dokumentem tworzonym po produkcji. Gate przed wydaniem:

zamrożony manifest artefaktów i binary hashes;
wygenerowany SBOM ze wszystkich build ecosystems;
brak nierozstrzygniętych unknown/custom licenses;
review license expressions i compatibility;
zidentyfikowane modifications;
gotowy Corresponding Source, jeśli wymagany;
notices/LICENSE/NOTICE bundle;
sprawdzony mechanizm source offer/download;
Installation Information assessment;
hardware/data/font/model license review;
trademark i patent issues przekazane właściwym ownerom;
test dostępu z perspektywy recipienta;
retention owner i deadline;
approval z zapisanym rationale.

Automatyzacja może porównać release z approved allowlist, ale nowa wersja dependency wymaga ponownej oceny. License metadata package może się zmienić nawet bez zmiany nazwy.

Gate powinien być częścią definicji done dla firmware/product release. Wykrycie problemu po zapisaniu tysięcy urządzeń oznacza kosztowną aktualizację, wysyłkę notices lub redesign.

Pakiet Corresponding Source#

Najlepszy test praktyczny: niezależny inżynier na czystej maszynie próbuje odtworzyć binary i zainstalować je zgodnie z dostarczoną instrukcją, w zakresie wymaganym licencją.

Pakiet:

README-COMPLIANCE
LICENSES/ and notices
upstream sources at exact commits
local patches/full modified sources
submodules/vendor dependencies
board/target configuration
toolchain identity or reproducible environment
build scripts and generator inputs
installation instructions/information
SBOM
binary/source hashes

Source jako jeden vendor tarball może być poprawny, ale musi być rzeczywiście preferred form for modification. Obfuscated, minified albo generated-only output zwykle nie spełnia tej roli, jeśli normalnie modyfikuje się inne źródła.

Sekrety produkcyjne i prywatne CI endpoints usuwa się bez niszczenia build. Jeśli skrypt wymaga niedostępnego proprietary compiler, trzeba sprawdzić System Library/tool exception i realną możliwość compliance.

Reproducible byte-identical build jest silnym evidence, ale nie zawsze obowiązkiem licencji. Jeśli build nie jest bit-identical z powodu timestamp, raportuje się kontrolowane różnice i potwierdza funkcjonalną zgodność source.

Obsługa zmian i zapytań#

Compliance trwa po wydaniu. Organizacja utrzymuje:

publiczny kontakt;
procedurę request triage;
mapę serial/release → compliance bundle;
SLA odpowiedzi;
hosting/physical-media process;
archiwum source i notices;
log dostarczeń;
correction process przy brakującym pliku;
monitoring nowych versions/licenses.

Zapytanie o source nie powinno trafiać do przypadkowego supportu, który odpowie „to własność firmy”. Gotowy runbook wskazuje release ID, URL i sposób eskalacji.

Jeśli upstream zmienia licencję, historyczny release nadal podlega grantowi otrzymanemu dla użytej wersji. Nie nadpisuje się manifestu. Nowy release ocenia nową licencję.

Contributions do upstream mają własny proces: DCO/CLA, employer ownership, third-party code i license of contribution. Pracownik nie powinien wysyłać fragmentu proprietary vendor SDK do publicznego PR.

Typowe błędy#

„Jest na GitHubie, więc jest open source.” Publiczny odczyt nie jest grantem redystrybucji.
„GPL wymaga publikacji wszystkiego zawsze.” Obowiązki zależą od działania i scope; nie należy ani rozszerzać, ani zawężać bez analizy.
„Nie sprzedajemy firmware osobno.” Binary w urządzeniu nadal jest przekazywane.
„Damy link do upstream.” Nie obejmuje własnych patches, exact commit i build files.
„To tylko biblioteka.” Wersja LGPL/GPL/MPL i sposób linkowania są kluczowe.
„Top-level LICENSE obejmuje repo.” Per-file notices i third_party mogą się różnić.
„Open firmware oznacza open hardware.” CAD/PCB/docs mają osobne prawa.
„NOTICE to marketing credits.” Zawartość i miejsce wynikają z licencji.
„Scanner powiedział MIT.” Automatyczny wynik wymaga provenance i review.
„SBOM zbudujemy po release.” Wtedy brakuje starych dependencies, source i toolchain.
„Unknown można opisać jako proprietary.” Bez grantu również proprietary redystrybucja może być niedozwolona.
„No-military source license jest open source.” Ograniczenie field of use zmienia charakter licencji i może uniemożliwić planowany produkt.

Najskuteczniejsza kontrola jest prosta: żadnego zewnętrznego binary bez mapy exact source, licencji, notices, obowiązków i właściciela retencji.

Powiązane tematy#

Jak prowadzić BOM UAV — SBOM, release configuration i hardware–software mapping.
ArduPilot — architektura — moduły i granice firmware.
PX4 — architektura — permissive top-level i dependency graph.
Betaflight — architektura — firmware distribution i konfiguracja targetu.
Własny flight controller — dobór komponentów software od początku projektu.

Przypisy#

Mozilla Public License 2.0 FAQ — file-level copyleft, source availability, distribution i Larger Work; pomocnicze wobec tekstu MPL.
SPDX License List — standardowe identyfikatory, wersje, teksty i exceptions.
Apache License, Version 2.0 — redistribution, modified-file notices, NOTICE, patent grant i trademarks.
GNU General Public License, version 3 — Corresponding Source, object code conveyance i Installation Information.
ArduPilot: COPYING.txt — top-level GPLv3 text w oficjalnym repozytorium.
PX4-Autopilot: LICENSE — top-level BSD 3-Clause w oficjalnym repozytorium.
Betaflight: LICENSE — top-level GPLv3 w oficjalnym repozytorium.
INAV: LICENSE — top-level GPLv3 w oficjalnym repozytorium.
REUSE Specification 3.3 — machine-readable copyright/licence per file i katalog LICENSES.
NTIA: The Minimum Elements for a Software Bill of Materials — minimalne pola, zależności, autor i timestamp SBOM.
GNU GPL Frequently Asked Questions — oficjalne objaśnienia FSF; pomocnicze wobec tekstu licencji.

Źródła z centralnego rejestru

GNU General Public License, version 3 [oficjalny tekst GPLv3 definiujący prawa i obowiązki przy kopiowaniu, modyfikowaniu oraz przekazywaniu programu]
GNU GPL Frequently Asked Questions [oficjalne objaśnienia FSF dotyczące GPL, source, dystrybucji, linkowania i zgodności; pomocnicze wobec tekstu licencji]
Apache License, Version 2.0 [oficjalny tekst licencji permissive z warunkami redystrybucji, NOTICE i grantem patentowym]
Mozilla Public License 2.0 FAQ [oficjalne objaśnienia file-level copyleft, dystrybucji source i Larger Work; pomocnicze wobec tekstu MPL 2.0]
SPDX License List [oficjalna lista standardowych identyfikatorów, nazw, tekstów i wyjątków licencyjnych SPDX]
SPDX Specifications [oficjalna strona specyfikacji SPDX do wymiany danych o komponentach, zależnościach, licencjach i bezpieczeństwie software]
REUSE Specification 3.3 [specyfikacja maszynowo czytelnych informacji copyright/licence per file i katalogu LICENSES]
NTIA: The Minimum Elements for a Software Bill of Materials [oficjalny raport definiujący minimalne pola, praktyki i formaty automatyzacji SBOM]
ArduPilot: COPYING.txt [oficjalny plik licencyjny repozytorium ArduPilot; stan sprawdzony 2026-08-16]
PX4-Autopilot: LICENSE [oficjalny plik licencyjny repozytorium PX4-Autopilot; stan sprawdzony 2026-08-16]
Betaflight: LICENSE [oficjalny plik licencyjny repozytorium Betaflight; stan sprawdzony 2026-08-16]
INAV: LICENSE [oficjalny plik licencyjny repozytorium INAV; stan sprawdzony 2026-08-16]