Zgodność licencji oprogramowania w umowach obronnych: COTS i DFARS

Zgodność licencji na oprogramowanie jest w większości organizacji traktowana jako formalność zakupowa. W kontraktach obronnych to coś bliższego obowiązkowi regulacyjnemu, z konsekwencjami finansowymi, prawnymi i bezpieczeństwa, które kumulują się w każdym programie realizowanym przez wykonawcę jednocześnie. Pojedyncza umowa korporacyjna błędnie zastosowana w sieci sklasyfikowanej i niesklasyfikowanej, biblioteka na licencji GPL osadzona w dostawie bez ujawnienia źródeł albo licencja serwerowa liczona według gniazd zamiast rdzeni — każde z nich może wygenerować żądania wyrównawcze rzędu sześcio- lub siedmiocyfrowego od dostawcy przeprowadzającego audyt, żądanie działań korygujących od DCSA albo niekorzystne orzeczenie o własności intelektualnej, które zeruje poziom uprawnień dostawy.

Złożoność jest strukturalna. Wykonawcy obronni działają w wielu domenach bezpieczeństwa, obsługują dziesiątki programów w ramach różnych kontraktów i wdrażają oprogramowanie COTS w konfiguracjach — klastry zwirtualizowane, enklawy chmury rządowej, systemy misji za granicą — których metryki liczenia u dostawców licencji nie zostały zaprojektowane do czystej obsługi. Ramy praw do oprogramowania DFARS nakładają warstwę obowiązków specyficznych dla rządu na standardowe warunki licencji komercyjnych. Włączenie otwartego źródła do dostaw uruchamia wymagania ujawniania, z którymi większość zespołów oprogramowania spotyka się dopiero wtedy, gdy oficer bezpieczeństwa programu zgłosi je przed dostawą.

Ten artykuł obejmuje pełny krajobraz techniczny i regulacyjny: wzorce ekspozycji licencyjnej unikalne dla programów obronnych, architekturę ewidencji COTS, klauzule praw DFARS, przygotowanie dowodów audytowych, narzędzia zgodności otwartego źródła, metody optymalizacji licencji oraz wymagania depozytu oprogramowania dla systemów krytycznych dla misji.

Ekspozycja licencyjna oprogramowania w programach obronnych

Wykonawcy obronni systematycznie niedoszacowują ekspozycji licencyjnej oprogramowania, ponieważ budżety programów uwzględniają koszt zakupu licencji, ale rzadko koszt zarządzania zgodnością z warunkami, na jakich te licencje są przyznawane. Luka między zakupem a zgodnością poszerza się z każdym programem, który ponownie wykorzystuje narzędzie COTS w nowym kontrakcie bez sprawdzenia, czy istniejąca licencja na to zezwala.

Wzorce niedoszacowania zakresu

Najczęstszy wzorzec niedoszacowania dotyczy metryk licencji serwerowych i procesorowych. Dostawcy oprogramowania korporacyjnego przeszli kolejno z licencjonowania na serwer, przez licencjonowanie na procesor, do licencjonowania na rdzeń w kolejnych generacjach produktów. Wykonawca, który kupił licencję na serwer bazy danych w 2018 roku i w 2024 roku przeniósł obciążenie na nowy serwer z wieloma gniazdami procesorów, może teraz być niezgodny bez jakiejkolwiek zmiany oprogramowania — zmiana sprzętu zwiększyła liczbę procesorów, co zmieniło obowiązek licencyjny według nowoczesnych reguł liczenia współczynnika rdzeni. Niewielu kierowników programów śledzi to powiązanie między cyklami odświeżania infrastruktury a zmianami metryk licencyjnych.

Liczenie licencji opartych na użytkownikach przedstawia inny wzorzec niedoszacowania. Licencje na użytkowników nazwanych w środowiskach sklasyfikowanych są często nadmiernie wdrażane, ponieważ posiadacze klauzul dostępu rotują między programami. Użytkownik, który kończy pracę w Programie A i przechodzi do Programu B, nadal ma aktywne konto w systemach oprogramowania Programu A, dopóki ktoś go administracyjnie nie usunie. Narzędzia SAM, które liczą aktywne konta użytkowników, a nie uwierzytelnionych aktywnych użytkowników, zgłoszą więcej wdrożonych stanowisk, niż jest faktycznie używanych, co zawyża pozorną lukę zgodności — ale organizacje liczące wyłącznie sesje współbieżne mogą odkryć, że są niezgodne w okresach szczytu, gdy liczba użytkowników gwałtownie rośnie.

Licencjonowanie w chmurze rządowej

Licencjonowanie w środowiskach GovCloud (enklawy IL4, IL5, IL6) wprowadza kategorię ekspozycji licencyjnej, której większość zespołów zakupowych on-premise nie jest przygotowana zarządzać. Standardowe komercyjne licencje COTS często nie zezwalają na wdrożenie w środowisku hostowanym przez stronę trzecią bez aneksu chmurowego. Dostawcy, którzy wykryją wdrożenie w dzierżawie chmury rządowej — przez telemetrię IP, dzienniki użytkowania przekazane podczas audytu lub raporty resellerów — traktują takie wdrożenie jako odrębny wymóg licencyjny wobec uprawnienia lokalnego. Wykonawcy obronni, którzy przenosili obciążenia lokalne do środowisk chmurowych IL5 na istniejących licencjach wieczystych bez weryfikacji praw do wdrożenia w chmurze, ponoszą nieujawnioną ekspozycję zgodności w każdym dotkniętym programie.

Dla szerszego spojrzenia na to, jak kontrole łańcucha dostaw oprogramowania współgrają z licencjonowaniem, zobacz naszą analizę wymuszania SBOM w potokach obronnych, która obejmuje wymagania przejrzystości komponentów w dół łańcucha, wynikające z tej samej postawy zgodności.

Zarządzanie ewidencją licencji COTS

Ewidencja licencji COTS jest fundamentem każdego programu zgodności oprogramowania. Ma dwa składniki, które muszą być utrzymywane w synchronizacji: baza uprawnień (jakie licencje wykonawca zakupił) i baza wdrożeń (jakie oprogramowanie jest faktycznie zainstalowane i używane). Luka zgodności to różnica między nimi. Zarządzanie tą luką wymaga zarówno dokładnych danych, jak i procesu rozstrzygania rozbieżności.

Wybór narzędzia SAM dla środowisk obronnych

Narzędzia zarządzania zasobami oprogramowania muszą spełniać wymagania, które eliminują z rozważań większość produktów konsumenckich lub wyłącznie SaaS. Dla sieci sklasyfikowanych narzędzie SAM musi:

• Działać wyłącznie lokalnie (on-premise), bez telemetrii call-home do zewnętrznych punktów końcowych
• Obsługiwać wykrywanie agentowe na punktach końcowych Windows i Linux bez wymagania dostępu do internetu dla aktualizacji agentów
• Produkować wykrywalną ewidencję w formatach eksportowalnych (CSV, SPDX lub XML) bez pośredników chmurowych
• Utrzymywać osobne instancje wykrywania dla każdej domeny bezpieczeństwa (niesklasyfikowana, CUI, sklasyfikowana) bez wycieku danych między domenami
• Normalizować nazwy i wersje produktów wobec offline'owej biblioteki licencji, którą można aktualizować kontrolowanymi nośnikami

Narzędzia spełniające te wymagania to z reguły lokalne wdrożenia korporacyjnych platform SAM. Możliwość normalizacji biblioteki licencji jest szczególnie istotna: surowy wynik wykrywania zawiera setki wariantów produktów i ciągów wersji, które należy sprowadzić do kanonicznych tożsamości produktów, zanim porównanie z uprawnieniami stanie się sensowne.

Automatyczne wykrywanie wobec ewidencji ręcznej

Automatyczne wykrywanie jest dokładniejsze i bardziej spójne niż ewidencja ręczna dla oprogramowania na punktach końcowych, ale ma martwe strefy w środowiskach obronnych: oprogramowanie zainstalowane na systemach niepodłączonych do sieci (samodzielne stacje robocze sklasyfikowane, systemy wdrożone, sprzęt testowy), oprogramowanie osadzone w oprogramowaniu układowym lub dostarczane jako część integracji platformy oraz oprogramowanie uruchamiane wyłącznie w określonych fazach misji i nieaktywne podczas skanów wykrywania. Ewidencja ręczna uzupełnia automatyczne wykrywanie dla tych kategorii, z wykorzystaniem udokumentowanych procedur inspekcji i okresowych przeglądów fizycznych systemów niepodłączonych do sieci.

Architektura bazy uprawnień licencyjnych

Baza uprawnień musi przechowywać, dla każdego rekordu licencji:

• Nazwę i wersję produktu (znormalizowaną do postaci kanonicznej dostawcy)
• Metrykę licencji (na stanowisko, na rdzeń, na serwer, współbieżna, jednostka subskrypcji)
• Ilość uprawnień i jednostkę miary zgodną z metryką
• Dowód uprawnienia: numer zamówienia, numer faktury, numer seryjny certyfikatu licencyjnego, odniesienie do harmonogramu ELA
• Program i kontrakt, które licencja wspiera (dla alokacji kosztów i śledzenia audytowego)
• Ograniczenia zakresu wdrożenia (tylko lokalnie, z aneksem chmurowym, dopuszczona sieć sklasyfikowana)
• Datę odnowienia lub status wieczysty
• Wszelkie aneksy dotyczące użytku rządowego lub specjalne warunki aneksów federalnych

Zapytanie uzgadniające generujące raport luki zgodności musi łączyć bazę uprawnień z bazą wykrywania po znormalizowanej tożsamości produktu i sumować wdrożenia wobec uprawnień według jednostki metryki. Rozbieżności, w których wdrożenia przekraczają uprawnienia, wymagają natychmiastowej triage: potwierdź dokładność liczby wdrożeń, a następnie albo zakup dodatkowe uprawnienia, albo usuń nieautoryzowane instalacje.

Klauzule praw do oprogramowania DFARS

DFARS Part 227 ustala ramy, w których rząd Stanów Zjednoczonych nabywa prawa do oprogramowania opracowanego w ramach lub używanego przy realizacji kontraktów obronnych. Dla wykonawców obronnych stosowne klauzule różnią się w zależności od tego, czy oprogramowanie jest komercyjne (regulowane przez DFARS 227.7202), czy niekomercyjne (regulowane przez DFARS 227.7103 i związaną z nim klauzulę kontraktową DFARS 252.227-7014).

DFARS 252.227-7014: prawa do oprogramowania niekomercyjnego

DFARS 252.227-7014 ma zastosowanie do oprogramowania opracowanego specjalnie w ramach kontraktu obronnego z wykorzystaniem finansowania rządowego, w całości lub w części. Klauzula ustala cztery standardowe poziomy uprawnień:

• Prawa nieograniczone: Rząd może używać, reprodukować, modyfikować, ujawniać lub rozpowszechniać oprogramowanie bez ograniczeń. Dotyczy oprogramowania opracowanego w całości na koszt rządowy.
• Prawa do celów rządowych (GPR): Poziom przejściowy dla oprogramowania opracowanego z mieszanką finansowania. Rząd może używać oprogramowania do każdego celu rządowego, ale nie może go ujawniać stronom komercyjnym w okresie GPR (zwykle pięć lat). Po wygaśnięciu okresu GPR prawa przekształcają się w nieograniczone.
• Prawa ograniczone: Dotyczy oprogramowania opracowanego w całości na koszt prywatny. Rząd może używać oprogramowania wyłącznie do wewnętrznych celów rządowych i nie może go ujawniać osobom trzecim bez zgody wykonawcy.
• Prawa licencyjne specjalnie wynegocjowane: Każde uregulowanie praw wykraczające poza standardowe poziomy, ujęte w aneksie licencyjnym właściwym dla kontraktu. Stosowane w sytuacjach hybrydowych, których standardowe poziomy nie rozstrzygają czysto.

Ustalenie źródła finansowania — czy rozwój prowadzono na koszt rządowy, prywatny, czy mieszany — jest najbardziej spornym aspektem zgłoszeń praw. Wykonawcy muszą prowadzić szczegółowe zapisy finansowania dla każdego komponentu oprogramowania w chwili opracowania, aby wesprzeć swoje zgłoszenia praw podczas przeglądu praw do danych technicznych.

Przekazywanie licencji na oprogramowanie komercyjne

Dla oprogramowania COTS DFARS 227.7202-1 wymaga, aby rząd nabywał wyłącznie prawa dostępne w standardowej umowie licencyjnej dostawcy, pod warunkiem że warunki te są zgodne z prawem federalnym i nie są w inny sposób zakazane. Oznacza to, że umowa licencyjna dostawcy COTS przepływa do klienta rządowego bez zmian ze strony ram praw DFARS — rząd nie może powoływać się na postanowienia o prawach nieograniczonych wobec dostawcy COTS, którego standardowe warunki ograniczają użytko rządowe.

Dla wykonawców głównych tworzy to obowiązek przekazywania w dół łańcucha: gdy oprogramowanie COTS zostaje włączone do systemu dostarczanego, wykonawca główny musi zidentyfikować komponenty COTS, dołączyć lub odnieść ich komercyjne warunki licencyjne oraz upewnić się, że rząd rozumie, iż otrzymuje warunki dostawcy, a nie uprawnienie wyprowadzone z praw DFARS. Niezidentyfikowanie komponentów COTS i niezgłoszenie ich statusu licencji komercyjnej w trakcie realizacji kontraktu może skutkować późniejszym twierdzeniem rządu o prawach nieograniczonych w oparciu o domyślną regułę DFARS — sporem kosztownym w procesie.

Zrozumienie, jak prawa do oprogramowania współgrają z szerszymi ramami kompletnego przewodnika po zamówieniach obronnych, pomaga wykonawcom ustrukturyzować strategię własności intelektualnej przed udzieleniem kontraktu, gdy siła negocjacyjna jest najwyższa.

Gotowość do audytów dostawców i DCSA

Audyt licencji na oprogramowanie może zostać wszczęty przez dostawcę komercyjnego korzystającego z praw audytowych w korporacyjnej umowie licencyjnej albo przez DCSA w ramach przeglądu klauzuli dostępu do obiektu, obejmującego ocenę kontroli bezpieczeństwa informacji. Oba typy audytów różnią się zakresem i uprawnieniami, ale oba wymagają tego samego podstawowego pakietu dowodowego.

Przygotowanie pakietu dowodowego na audyt

Pakiet dowodowy na audyt musi być przygotowany z wyprzedzeniem i utrzymywany w stanie umożliwiającym jego wydanie w okresie wypowiedzenia określonym w umowie licencyjnej — często 30 dni, czasem zaledwie 10 dni roboczych. Pakiet musi obejmować:

• Certyfikaty uprawnień licencyjnych dla wszystkich produktów objętych zakresem audytu
• Zamówienia i faktury odsyłające do każdego produktu i wersji, obejmujące wszystkie zakupy licencji za okres wsteczny wskazany przez audytora (zwykle od trzech do pięciu lat)
• Harmonogramy korporacyjnej umowy licencyjnej (ELA) z datami obowiązywania, listami objętych produktów i liczbą upoważnionych użytkowników
• Raporty wykrywania narzędzia SAM datowane w ciągu 30 dni od żądania audytu, pokazujące wdrożone wersje produktów i ich liczby
• Arkusz uzgodnienia mapujący uprawnienia na wdrożenia dla każdego produktu w zakresie
• Aneksy dotyczące użytku rządowego lub suplementy federalne modyfikujące standardowe warunki komercyjne
• Zapisy wycofania oprogramowania usuniętego z eksploatacji w okresie objętym audytem

Metodyka uzgadniania licencji

Metodyka uzgadniania użyta do przygotowania dowodów audytowych musi być spójna i dająca się udokumentować. Dla licencji na stanowiska metodyka powinna używać liczby uwierzytelnionych aktywnych użytkowników w zdefiniowanym okresie pomiarowym (zwykle 90-dniowym szczycie użycia poprzedzającym audyt), a nie pomiaru z jednej daty. Dla licencji na rdzenie metodyka musi udokumentować liczbę rdzeni fizycznych każdego serwera lub klastra maszyn wirtualnych uruchamiającego oprogramowanie, stosując opublikowaną przez dostawcę tabelę współczynników rdzeni, gdzie ma to zastosowanie. Dla licencji subskrypcyjnych metodyka musi uwzględniać okres aktywnego użytkowania, a nie tylko bieżący zrzut, ponieważ wyrównania wsteczne dotyczą użycia historycznego, które przekraczało liczby uprawnień w okresie subskrypcji.

Typowe ustalenia audytowe w środowiskach obronnych

Audyty wykonawców obronnych konsekwentnie ujawniają zbiór powtarzających się ustaleń, które dobrze zaprojektowany program zgodności eliminuje proaktywnie:

• Instalacje bez licencji: Oprogramowanie wykryte na punktach końcowych bez odpowiadającego rekordu uprawnienia — zwykle instalowane przez poszczególnych użytkowników dla wygody, bez zatwierdzenia zakupu.
• Błędne zastosowanie metryki licencyjnej: Licencje na użytkownika używane w środowiskach na procesor albo licencje współbieżne liczone tak, jakby były licencjami na użytkowników nazwanych.
• Luki w aktualizacjach wersji: Oprogramowanie zaktualizowane do nowej wersji głównej bez zakupu praw do aktualizacji w ramach umowy utrzymaniowej, która wygasła.
• Wdrożenie w chmurze bez aneksu chmurowego: Licencje lokalne zastosowane do wdrożeń w chmurze rządowej, gdy warunki dostawcy wymagają odrębnego prawa do użytku w chmurze.
• Brak dokumentacji uprawnień: Licencje zakupione i zainstalowane lata temu bez zachowania certyfikatu licencyjnego lub zamówienia, przez co wykonawca nie jest w stanie udowodnić uprawnienia.

Wymiar łańcucha dostaw zgodności licencji na oprogramowanie łączy się bezpośrednio z szerszymi kontrolami zarządzania ryzykiem łańcucha dostaw w obronności, które programy obronne muszą wdrażać — nieautoryzowane oprogramowanie jest jednocześnie naruszeniem zgodności i ryzykiem bezpieczeństwa.

Zgodność licencji otwartego źródła

Oprogramowanie otwartego źródła (OSS) włączone do dostaw obronnych tworzy obowiązki zgodności, które różnią się rodzajem od obowiązków licencji COTS. Niezgodność COTS tworzy odpowiedzialność finansową wobec dostawcy. Niezgodność OSS — konkretnie naruszenie warunków licencji copyleft — może stworzyć obowiązek ujawnienia zastrzeżonego kodu źródłowego każdemu odbiorcy oprogramowania, w tym rządowi, który potem może nie być w stanie ograniczyć dalszego ujawniania.

Ryzyko copyleft GPL/LGPL w dostawach obronnych

Licencje GPL w wersji 2 i GPL w wersji 3 nakładają wymóg copyleft: każde dzieło pochodne lub dzieło łączone rozpowszechniane osobie trzeciej musi być licencjonowane na tych samych warunkach GPL i towarzyszyć mu musi (lub musi istnieć oferta dostarczenia) pełny odpowiadający kod źródłowy. Dla wykonawcy obronnego dostarczającego system oprogramowania rządowi dostawa jest zdarzeniem rozpowszechnienia, które uruchamia obowiązek ujawnienia GPL dla każdego komponentu na licencji GPL włączonego do dostawy.

Praktyczne ryzyko nie polega na ujawnieniu nieszkodliwego kodu narzędziowego — polega na ujawnieniu zastrzeżonych implementacji algorytmicznych, które przypadkowo są statycznie połączone z biblioteką GPL. Jeśli moduł algorytmu celowania wykonawcy jest skompilowany do tego samego binarium co biblioteka przetwarzania danych na licencji GPL, postanowienia copyleft GPL mogą wymagać ujawnienia całego dzieła łączonego, w tym algorytmu celowania, w chwili dostawy binarium. Czy ten skutek jest wymagany, zależy od konkretnej wersji GPL, metody integracji (łączenie statyczne wobec dynamicznego) oraz faktów użycia komponentu GPL — ale ryzyko należy ocenić przed dostawą, a nie odkryć podczas późniejszego przeglądu bezpieczeństwa.

LGPL (Lesser GPL) stosuje słabszą regułę copyleft, która pozwala oprogramowaniu zastrzeżonemu łączyć dynamicznie z biblioteką LGPL bez uruchamiania copyleft na kodzie zastrzeżonym. Statyczne łączenie z biblioteką LGPL nadal niesie ryzyko. Granicę między bezpiecznym użyciem dynamicznym a ryzykownym włączeniem statycznym należy oceniać na poziomie konfiguracji budowania, a nie na poziomie kodu źródłowego.

Integracja skanera licencji

Skanery licencji — FOSSA, Black Duck (Synopsys), SCANOSS i porównywalne narzędzia lokalne — automatyzują identyfikację OSS i wykrywanie licencji w repozytoriach kodu, artefaktach budowania i obrazach kontenerów. Integracja z potokiem CI/CD wymusza politykę licencyjną w momencie wprowadzania OSS: gdy deweloper dodaje nową zależność, skaner identyfikuje licencję, sprawdza ją wobec zatwierdzonej polityki licencyjnej i blokuje kompilację, jeśli licencja jest sklasyfikowana jako wysokiego ryzyka bez udokumentowanego wyjątku.

Dla repozytoriów sklasyfikowanych skaner musi działać w trybie odizolowanym od sieci wobec lokalnie utrzymywanej bazy komponentów — chmurowe API wyszukiwania licencji nie są dostępne w sieciach sklasyfikowanych. Lokalna baza musi być aktualizowana w kontrolowanym cyklu utrzymaniowym i oznaczana wersją, aby wyniki skanowania były odtwarzalne i audytowalne. Wynik skanera dla każdej dostawy musi być archiwizowany jako część bazy technicznej programu, ponieważ obowiązki ujawniania OSS są oceniane wobec komponentów zawartych w konkretnej dostawie, a nie wobec bieżącego stanu bazy kodu.

Obowiązki ujawniania OSS

Gdy kontrakt obronny wymaga dostawy SBOM (Software Bill of Materials), ewidencja OSS wytworzona przez skaner licencji zasila bezpośrednio wynik SBOM. Format minimalnych elementów NTIA i specyfikacja SPDX wymagają identyfikacji licencji na poziomie komponentu, którą zapewnia skaner. Ale SBOM jest dokumentem ujawniającym, nie certyfikatem zgodności — wykonawca musi dodatkowo dopilnować, by wszystkie obowiązki ujawniania copyleft zostały spełnione jako odrębny krok od wytworzenia SBOM. Wytworzenie dokładnego SBOM wymieniającego komponent GPL bez ujawnienia źródeł spełnia wymóg przejrzystości, ale nie obowiązek licencyjny.

Strategie optymalizacji licencji

Zgodność licencyjna to podłoga. Optymalizacja licencji to sufit — systematyczny wysiłek zmierzający do obniżenia kosztów licencji przez eliminację marnotrawstwa, wydajniejszą realokację uprawnień oraz zastępowanie tańszymi alternatywami tam, gdzie pozwalają na to wymagania techniczne. W środowiskach kontraktów obronnych z dużymi, długotrwałymi programami i wolnymi cyklami zakupowymi znaczne oszczędności kumulują się z optymalizacji, której nigdy nie widać w ujęciu jednego programu.

Odzyskiwanie nieużywanych licencji

Odzyskiwanie licencji to proces odbierania licencji przypisanych do użytkowników lub systemów, które nie są już aktywnymi konsumentami. Narzędzia SAM śledzące częstotliwość użycia — a nie tylko liczbę instalacji — identyfikują licencje przypisane, ale niewykorzystywane w zdefiniowanym okresie (zwykle od 60 do 90 dni). Licencje te są kandydatami do odzyskania i realokacji na aktywnych użytkowników, którzy ich potrzebują. W dużych środowiskach wykonawców obronnych ćwiczenia odzyskiwania konsekwentnie odzyskują od 15 do 25 procent wdrożonych licencji na stanowiska w kategoriach narzędzi produktywności korporacyjnej i inżynierskich, co stanowi istotne uniknięcie kosztu przy odnowieniu.

Implikacje licencyjne wirtualizacji

Wirtualizacja tworzy jednocześnie okazje optymalizacji licencji i ryzyka. Okazja: konsolidacja serwerów fizycznych zmniejsza liczbę rdzeni fizycznych, wobec których należy stosować licencje na rdzenie, potencjalnie zmniejszając obowiązek licencyjny. Ryzyko: funkcje migracji maszyn wirtualnych (migracja na żywo, klastrowanie wysokiej dostępności) mogą spowodować, że maszyna wirtualna uruchamiająca licencjonowane oprogramowanie przeniesie się na host z większą liczbą rdzeni fizycznych, zwiększając obowiązek licencyjny bez udziału człowieka. Zarządzanie tym ryzykiem wymaga albo konfiguracji polityk migracji maszyn wirtualnych z ograniczeniem ruchu do wstępnie licencjonowanych pul hostów, albo zakupu wystarczającej liczby licencji na pokrycie całej domeny migracji — podejścia, które dostawcy preferują, ponieważ eliminuje ono obciążenie zarządzania polityką migracji.

Analiza substytucji hybrydowej komercyjnej/otwartego źródła

Dla kategorii narzędzi niesklasyfikowanych i niekrytycznych dla misji — środowiska deweloperskie, narzędzia dokumentacji, systemy śledzenia projektów, platformy analityki danych — alternatywy otwartego źródła dla produktów komercyjnych często spełniają wymagania funkcjonalne przy znacznie niższym koszcie. Analiza substytucji porównuje całkowity koszt posiadania obecnej licencji COTS (opłaty licencyjne, koszty wsparcia, koszty szkoleń, koszty integracji) z całkowitym kosztem posiadania alternatywy OSS (koszt wdrożenia, umowa wsparcia jeśli potrzebna, szkolenia, integracja). Analiza musi również ocenić warunki licencji alternatywy OSS, aby potwierdzić, że substytucja nie wprowadza nowego obowiązku zgodności copyleft.

Decyzje o substytucji w środowiskach obronnych wymagają dodatkowej oceny bezpieczeństwa: produkty OSS używane w środowiskach sklasyfikowanych muszą być zatwierdzone do użytku na systemach sklasyfikowanych przez właściwy proces akredytacji, co dodaje czas realizacji i koszt do projektu substytucji, których czyste porównanie kosztów licencji nie ujmuje.

Depozyt oprogramowania i ciągłość

Depozyt oprogramowania (escrow) to mechanizm ciągłości, który chroni zdolność rządu — i wykonawcy — do utrzymywania i modyfikowania niestandardowego oprogramowania, jeśli pierwotny deweloper przestanie móc je wspierać. Dla programów obronnych o długiej żywotności operacyjnej (od 15 do 30 lat dla wielu programów platformowych) prawdopodobieństwo, że pierwotny deweloper oprogramowania pozostanie dostępny i skłonny wspierać oprogramowanie przez cały cykl programu, nie jest wysokie. Depozyt adresuje to ryzyko, zapewniając dostęp do kodu źródłowego i materiałów budowania, gdy wystąpią zdefiniowane zdarzenia wyzwalające.

Wymagania depozytu dla niestandardowego oprogramowania obronnego

Kontrakty obronne na niestandardowe oprogramowanie krytyczne dla misji coraz częściej zawierają klauzule depozytu, które określają:

• Agent depozytu (wskazany komercyjny dostawca usługi escrow, a nie obiekt rządowy)
• Harmonogram deponowania — zwykle przy udzieleniu kontraktu dla depozytu początkowego, następnie aktualizowany przy każdym kamieniu milowym głównego wydania i corocznie potem
• Wymagania dotyczące zawartości depozytu: kod źródłowy wszystkich komponentów niestandardowych, skrypty budowania, specyfikacje zależności zewnętrznych, dokumentacja środowiska budowania (wersje kompilatorów, wersje narzędzi budowania, pliki konfiguracyjne)
• Wymagania testów weryfikacyjnych — prawo beneficjenta do przetestowania depozytu w celu potwierdzenia, że jest kompletny i zdatny do zbudowania
• Zdarzenia wyzwalające wydanie depozytu: niewypłacalność dostawcy, zaprzestanie wsparcia oprogramowania, istotne naruszenie umowy utrzymaniowej albo niewykonanie zobowiązania przez wykonawcę

Testy weryfikacyjne depozytów escrow

Depozyt escrow, który nigdy nie był testowany, jest dokumentem prawnym, a nie użytecznym zasobem. Testy weryfikacyjne potwierdzają, że zdeponowane materiały są kompletne i wystarczające do przebudowania oprogramowania bez odwoływania się do wewnętrznych systemów dewelopera. Sensowny test weryfikacyjny rekonstruuje środowisko budowania ze zdeponowanych specyfikacji, instaluje zdeponowane zależności, uruchamia skrypty budowania wobec zdeponowanego kodu źródłowego i wykonuje zestaw testów funkcjonalnych wobec powstałego artefaktu budowania. Każda luka w depozycie — brakująca zależność, nieudokumentowana wersja narzędzia budowania, zakodowana na sztywno ścieżka do wewnętrznego systemu dewelopera — ujawnia się podczas testów weryfikacyjnych i może zostać usunięta przez depozyt uzupełniający, zanim depozyt będzie potrzebny w rzeczywistym scenariuszu ciągłości.

Zdarzenia wyzwalające wydanie depozytu

Wydanie depozytu regulują definicje zdarzeń wyzwalających w umowie depozytu i musi zostać wszczęte w formalnym procesie żądania. Najczęstsze zdarzenia wyzwalające w umowach depozytu oprogramowania obronnego to niewypłacalność dostawcy (zgłoszenie upadłości lub ustanowienie syndyka), przejęcie dostawcę przez konkurenta, który wycofuje produkt, zaprzestanie wsparcia utrzymaniowego oraz istotne naruszenie umowy utrzymaniowej oprogramowania pozostające nienaprawione po okresie wypowiedzenia i naprawy. Proces żądania wydania zazwyczaj obejmuje pisemne zawiadomienie agenta depozytu wskazujące zdarzenie wyzwalające, okres oczekiwania, w którym deweloper może zakwestionować wydanie, oraz neutralne rozstrzygnięcie, jeśli wydanie jest sporne. Wykonawcy powinni przeglądać swoje umowy depozytu, aby potwierdzić, że definicje zdarzeń wyzwalających są na tyle konkretne, by dało się je wywołać bez procesu sądowego — niejasne definicje tworzą niejednoznaczność, która spowalnia dostęp do zdeponowanych materiałów dokładnie wtedy, gdy liczy się szybkość.