Zamknięcie otwartego kodu ATAK/TAK w 2025

Słowem wstępu

Tactical Assault Kit (TAK) – znany też jako Android Team Awareness Kit (ATAK) w wersji na Android – to zaawansowany system geolokalizacyjny i świadomości sytuacyjnej opracowany pierwotnie przez Laboratorium Badawcze Sił Powietrznych USA (AFRL) Umożliwia on tworzenie wspólnego obrazu operacyjnego (COP) na poziomie taktycznym: użytkownicy mogą śledzić się nawzajem (tzw. Blue Force Tracking), udostępniać mapy, znaczniki, wideo i inne dane w czasie rzeczywistym, poprawiając koordynację działań. System jest modułowy – architektura wtyczek pozwala dodawać nowe funkcje i integracje.

Przez lata część ekosystemu TAK była udostępniana publicznie jako open-source. W szczególności ATAK-CIV (cywilna wersja), przeznaczony do użytku przez instytucje cywilne i komercyjne, był dostępny na licencji open source – Departament Obrony (DoD) sklasyfikował ATAK-CIV jako produkt EAR99 i opublikował kod na GitHub. Dzięki temu wiele państw oraz społeczności użytkowników mogło samodzielnie rozwijać i dostosowywać narzędzie do własnych potrzeb.

W roku 2025 nastąpiła jednak istotna zmiana polityki – zamknięto publiczny dostęp do kodu źródłowego kluczowych komponentów rodziny TAK, w tym ATAK (Android) i prawdopodobnie nowych rozszerzeń (określanych potocznie jako ATAK-X / TAKX). Niniejszy dokument (white paper) analizuje to wydarzenie i jego konsekwencje dla wojskowych analityków oraz decydentów politycznych. 

W kolejnych rozdziałach omówiono:

• Faktyczne zamknięcie kodu źródłowego – co zaszło, z odwołaniem do repozytorium GitHub i jego obecnego statusu.

• Analizę wersji 5.1 ATAK – wskazanie nowych funkcjonalności od tej wersji, w szczególności możliwości raportowania pozycji i znaczników (markerów) do systemów DoD.

• Reperkusje dla państw korzystających z ATAK – wpływ na suwerenność informacyjną, interoperacyjność, cyberbezpieczeństwo oraz zdolności adaptacji i rozwoju niezależnego.

• Możliwe alternatywy dla użytkowników zagranicznych, którzy utracili dostęp do otwartego kodu.

• Potencjalne scenariusze geopolityczne wynikające z utraty dostępu lub kontroli nad tego typu oprogramowaniem.

Dokument kończą zalecenia strategiczne, które mogą pomóc decydentom w reagowaniu na zaistniałą sytuację. Analiza opiera się na dostępnych źródłach, w tym oficjalnych informacjach DoD oraz komentarzach społeczności użytkowników ATAK.

Zamknięcie kodu źródłowego systemu ATAK (2025)

2 maja 2025 roku publiczne repozytorium z kodem źródłowym ATAK-CIV zostało oficjalnie zarchiwizowane przez właściciela (TAK Product Center, DoD) github.com. Oznacza to, że od tego dnia kod nie jest już rozwijany w trybie open-source i pozostaje dostępny wyłącznie w trybie do odczytu. Na stronie GitHub projektu pojawił się komunikat: „This repository was archived by the owner on May 2, 2025. It is now read-only.”. W praktyce zamknięcie repozytorium wstrzymało publikację nowych wersji kodu – najnowszy dostępny publicznie release to ATAK-CIV v.4.6.0.5 z października 2024, podczas gdy aplikacja w sklepach i u oficjalnych użytkowników rządowych osiągnęła już wersje z serii 5.x (np. 5.1, 5.2, 5.3).

Decyzja ta nie została szeroko uzasadniona publicznie, co wywołało spekulacje w społeczności użytkowników. Na forum Reddit poświęconym ATAK zauważono, że repozytorium GitHub prawdopodobnie pełniło jedynie rolę mirrora, a deweloperzy przenieśli rozwój wewnętrznie na instancję GitLab (tak.gov) już kilka lat wcześniej. Faktem jest, że kod udostępniany na GitHub od dłuższego czasu nie nadążał za wersjami binarnymi – np. w momencie archiwizacji oficjalna wersja ATAK w Google Play (5.3) znacznie przewyższała ostatni opublikowany kod (4.6). To sugeruje, że od wersji 5.0 wzwyż rozwój odbywał się za zamkniętymi drzwiami, a otwarte repozytorium nie było już aktualizowane. Archiwizacja w 2025 roku potwierdziła ten stan – project zmierza w kierunku oprogramowania zamkniętoźródłowego.

W ramach rodziny TAK różne komponenty podlegały odmiennym restrykcjom dostępu już wcześniej. DoD formalnie dzieli dystrybucję na wersje: ATAK-MIL (militarna, zastrzeżona dla Sił Zbrojnych USA i udostępniana sojusznikom tylko przez program Foreign Military Sales), ATAK-GOV (dla instytucji rządowych USA) oraz ATAK-CIV (cywilna, eksportowa). Według oficjalnego oświadczenia: „TAK-MIL is a restricted use product for USG military use only. NO distribution is authorized outside this forum except through properly vetted Program Management Offices. [...] ATAK-CIV is EAR99 [...] and has been released by the Department of Defense as open source available here: github.com/deptofdefense/AndroidTacticalAssaultKit-CIV”. Innymi słowy, militarna wersja ATAK jest kontrolowana i nie może być dowolnie rozpowszechniana poza kanałami rządowymi, zaś cywilna wersja miała być otwartym odpowiednikiem dostępnym szeroko (EAR99). Zamknięcie kodu ATAK-CIV w 2025 roku de facto zniosło ten ostatni element otwartości – choć binarki ATAK-CIV wciąż są dostępne (np. w sklepie Google Play), to źródła nie są już aktualnie udostępniane.

Warto podkreślić, że brak dostępu do kodu źródłowego nie oznacza całkowitego odcięcia od narzędzia. DoD nadal umożliwia pobranie gotowych aplikacji i SDK (Software Development Kit) przez oficjalny portal tak.gov dla zarejestrowanych użytkowników. Jednakże jest to już model „tylko binarny” – użytkownicy otrzymują pliki wykonywalne i biblioteki, bez wglądu w implementację. Dla społeczności open-source i państw, które polegały na własnych modyfikacjach ATAK, jest to zasadnicza zmiana ograniczająca przejrzystość i kontrolę nad używanym oprogramowaniem.

Poniżej przedstawiono podsumowanie sytuacji przed i po zamknięciu kodu:

Nowe funkcje od wersji 5.1 – raportowanie pozycji do DoD

Wraz z przejściem ATAK do gałęzi 5.x (której kod nie został upubliczniony) pojawiły się istotne zmiany funkcjonalne. ATAK w wersji 5.1 (i późniejszych) wprowadził mechanizmy ułatwiające raportowanie pozycji użytkownika oraz znaczników taktycznych (markerów) do scentralizowanych serwerów TAK należących lub zarządzanych przez DoD. Innymi słowy, od tej wersji aplikacja jest przygotowana do natywnej współpracy z infrastrukturą sieciową DoD, umożliwiając automatyczne udostępnianie danych sytuacyjnych do centralnego punktu zbiorczego.

Choć oficjalna dokumentacja ATAK 5.1 nie jest publicznie dostępna, wskazówki co do tych możliwości można wywnioskować z kilku źródeł:

• Opis aplikacji ATAK-CIV (Google Play) podkreśla pełną zgodność z „standardami Departamentu Obrony” w zakresie silnika geoprzestrzennego i komponentu komunikacyjnego. Oznacza to, że aplikacja potrafi komunikować się w sposób zgodny z protokołami używanymi w sieciach DoD i może przesyłać dane w standardowym formacie (np. format CoT – Cursor on Target, stosowany w TAK).

• ATAK jest pomyślany do działania w architekturze klient-serwer. TAK Server, oficjalny serwer pośredniczący, odpowiada za zbieranie i dystrybucję danych z klientów (np. położenia GPS wszystkich użytkowników, wiadomości, plików). Jeżeli urządzenia nie działają wyłącznie w trybie ad-hoc (peer-to-peer), wymagane jest użycie TAK Servera, który zapewnia szyfrowanie, magazynowanie i federację danych między sieciami. W wersjach 5.x  zwiększono integrację ATAK z TAK Serverem, m.in. poprzez łatwiejszą konfigurację połączenia z serwerami DoD. Pojawiły się np. kreatory konfiguracji sieci (na tak.gov) umożliwiające automatyczne uzyskanie certyfikatów i połączenie aplikacji z serwerem.

Z punktu widzenia użytkowników zagranicznych istota zmian w v5.1 polega na tym, że ATAK staje się bardziej powiązany z infrastrukturą DoD. Włączenie mechanizmów raportowania oznacza, że dane operacyjne (własna pozycja GPS, znaczniki wprowadzone na mapie, itp.) mogą być łatwo przekazywane do centralnych węzłów amerykańskiego DoD. Jeśli zagraniczny użytkownik (np. siły zbrojne innego kraju) korzystałby z “gołej” aplikacji ATAK 5.1 i połączył ją z serwerem dostępnym w domenie DoD (np. w chmurze tak.gov), to istnieje potencjalne ryzyko udostępniania wrażliwych danych operacyjnych bez pełnej kontroli. Nawet jeżeli taka komunikacja wymaga celowej konfiguracji, sam fakt istnienia „wbudowanej” opcji współdzielenia danych z systemami DoD rodzi pytania o suwerenność informacji – kto faktycznie ma dostęp do danych sytuacyjnych generowanych przez aplikację?

Warto zaznaczyć, że ATAK od początku projektowano z myślą o koalicyjności i wymianie danych. W założeniach, dane trafiają na wspólny serwer do którego dostęp mają uprawnione podmioty. Dla użytkowników amerykańskich to zaleta – różne służby czy oddziały mogą widzieć wspólny obraz sytuacji. Jednak dla państwa A korzystającego z ATAK, posiadanie danych na serwerach kontrolowanych przez państwo B (USA) może być nieakceptowalne bez odpowiednich umów. Wersja 5.1 sprawia wrażenie jeszcze silniej scentralizowanej – co z jednej strony zwiększa efektywność dowodzenia (większy przepływ informacji do centrali), a z drugiej tworzy zależność od infrastruktury i zaufania do operatora tej infrastruktury (DoD).

Podsumowując, od ATAK 5.1 wzwyż aplikacja stała się narzędziem jeszcze ściślej zintegrowanym z sieciowymi systemami dowodzenia USA, oferując funkcje automatycznego raportowania pozycji i udostępniania danych taktycznych. Dla twórców (DoD) to naturalny kierunek rozwoju – ujednolicenie obrazu pola walki w czasie rzeczywistym. Dla niezależnych użytkowników spoza USA – potencjalne źródło obaw, jeśli nie dysponują własną, odseparowaną infrastrukturą TAK.

Reperkusje dla państw korzystających z ATAK

Zamknięcie kodu ATAK oraz zmiany architektoniczne w nowszych wersjach mają szerokie implikacje dla państw i organizacji, które dotąd wykorzystywały ATAK lub planowały to robić. Poniżej omawiamy kluczowe obszary, na które wpływa ta sytuacja:

Suwerenność informacyjna

Suwerenność nad danymi i oprogramowaniem jest kluczowa dla państw wykorzystujących technologie wrażliwe, zwłaszcza w obszarze obronności. Do czasu zamknięcia kodu, państwa mogły pobierać otwarty ATAK-CIV, audytować go i modyfikować pod własne potrzeby – miały więc względną kontrolę nad narzędziem. Teraz, jeśli pozostaną przy oficjalnych wydaniach:

• Brak dostępu do kodu źródłowego oznacza brak pełnej wiedzy, co dokładnie robi aplikacja. Trzeba ufać, że nie ma ona ukrytych funkcjonalności ani podatności. W kontekście raportowania pozycji pojawia się pytanie: czy aplikacja nawiązuje połączenia z serwerami poza kontrolą lokalną? Bez audytu kodu trudno to stwierdzić ze 100% pewnością.

• Zależność od dostawcy (DoD): Suwerenność informacyjna jest naruszona, gdy państwo musi polegać na obcym podmiocie w zakresie aktualizacji i wsparcia. Jeśli DoD jutro zdecyduje o zmianie funkcji ATAK czy wprowadzeniu ograniczeń dla wersji eksportowej, użytkownik zagraniczny nie ma możliwości przeciwstawienia się – nie może “samemu” zaktualizować czy zmienić kodu. 

• Kontrola USA nad rozwojem TAK może przełożyć się na kontrolę przepływu informacji operacyjnej u sojuszników.

• Obawy o przekaz danych: Nawet jeżeli państwo używa własnego serwera TAK (co byłoby rekomendowane), nadal istnieje potencjalne ryzyko, że fragmenty danych mogłyby trafiać np. do usług telemetrii kontrolowanych przez dostawcę. W wypadku technologii amerykańskiej, analogią może być dyskusja o sprzęcie telekomunikacyjnym – użycie cudzej technologii rodzi pytania, czy nie ma w niej “backdoora”. Dla decydentów politycznych jest to istotne – czy np. pozycje naszych oddziałów mogłyby być widoczne dla operatora systemu? 

• W scenariuszu skrajnym, utrata suwerenności informacyjnej mogłaby oznaczać uzależnienie własnego obrazu sytuacji od filtrów i decyzji cudzych instytucji.

Interoperacyjność i zależność sojusznicza

ATAK zdobył popularność wśród sojuszników USA – przykładowo Wielka Brytania wybrała TAK jako podstawę systemu DSA (Dismounted Situational Awareness) dla swojej armii. Brytyjczycy uzyskali dostęp do militarnej wersji ATAK (ATAK-MIL) potwierdzony kanałami oficjalnymi. Taka sytuacja stwarza wysoki stopień interoperacyjności z siłami USA – wszyscy korzystają z tego samego narzędzia, mogą współdzielić dane, używać kompatybilnych formatów i serwerów. To plus w działaniach koalicyjnych.

Jednak gdy kod źródłowy jest zamknięty, interoperacyjność odbywa się na zasadach dyktowanych przez jedną stronę. Konsekwencje:

• Zależność od USA w zakresie wsparcia: Sojusznik używający ATAK-MIL czy ATAK-CIV staje się klientem amerykańskiego produktu. W razie problemów technicznych, potrzeb rozwojowych, czy dostosowania do lokalnych warunków – musi polegać na amerykańskim wsparciu (lub licencjonowanym wykonawcy). Jeśli wsparcie to zostanie ograniczone (np. z powodów geopolitycznych lub priorytetów USA), państwo użytkownik może znaleźć się w trudnej sytuacji.

• Dyktat wersji: Sojusznicy otrzymują zapewne skompilowane wersje ATAK, być może z pewnym opóźnieniem i ograniczeniami (ATAK-CIV jest pozbawiony niektórych funkcji z ATAK-MIL). Nie mogą samodzielnie rozwijać nowych modułów poza to, co przewiduje SDK. Gdyby np. dany kraj potrzebował specjalnej funkcjonalności (np. integracji z krajowym systemem rozpoznania), musi prosić o taką funkcję twórców ATAK lub tworzyć plugin w ramach udostępnionych API. Ale jeśli API nie pozwala, droga rozwoju jest zamknięta. To ogranicza swobodę budowania własnej architektury dowodzenia.

• Scenariusz „odcięcia od aktualizacji”: W skrajnym przypadku pogorszenia relacji politycznych, dostęp do nowych wersji lub poprawek bezpieczeństwa mógłby zostać wstrzymany (analogicznie do np. sankcji technologicznych). Kraj, który zintegrował ATAK w swoich strukturach dowodzenia, stałby się zakładnikiem – musiałby zostać na starej wersji z wszelkimi jej lukami albo nagle szukać alternatywy.

Z drugiej strony, zamknięcie kodu może skłonić niektórych sojuszników do szukania innych rozwiązań, co paradoksalnie zmniejszy interoperacyjność wewnątrz koalicji. Jeśli np. państwo stwierdzi, że nie chce ryzykować dalszej zależności, może próbować rozwinąć własny system BMS (Battlefield Management System). Jednak jego system może nie być w pełni kompatybilny z ATAK – co oznacza utratę wspólnego COP i konieczność budowy mostów integracyjnych. Fragmentacja technologiczna wśród sojuszników to przeciwieństwo interoperacyjności, co z punktu widzenia NATO lub koalicji wojskowych jest niekorzystne.

Cyberbezpieczeństwo i audytowalność

Dostęp do kodu źródłowego ma istotny wymiar bezpieczeństwa:

• Audyt bezpieczeństwa: Gdy kod był otwarty, eksperci z różnych krajów mogli analizować go pod kątem podatności lub niepożądanych funkcji. Zamknięcie kodu oznacza, że jedynie twórcy (DoD/TAK Product Center) oraz ewentualnie wybrane podmioty mają wgląd. Dla użytkowników końcowych tworzy to “czarną skrzynkę” – nie wiadomo, czy np. nie istnieją niezałatane luki lub celowo pozostawione furtki. W systemie wykorzystywanym operacyjnie, taka niepewność jest poważnym problemem. Przykładowo, czy obcy aktor (cyberprzeciwnik) mógłby znaleźć exploita i przejąć kontrolę nad systemem? Społeczność open-source jest często szybka w wykrywaniu i łataniu luk – tutaj zdajemy się na tempo i priorytety DoD.

• Integracja z infrastrukturą teleinformatyczną: ATAK to nie tylko aplikacja – to cała komunikacja (radiowa, sieciowa) między urządzeniami a serwerem. Cyberbezpieczeństwo obejmuje więc również protokoły transmisji i szyfrowanie. W ATAK standardowo używa się szyfrowanej komunikacji (TLS) z serwerem, certyfikatów itp. Jednak jeśli państwo nie ma pełnej wiedzy o implementacji, trudniej jest ocenić ryzyko podatności (np. czy generatory kluczy są bezpieczne, czy protokół nie ma słabych punktów). Zależność od zamkniętego rozwiązania utrudnia też certyfikację – lokalne organy bezpieczeństwa mogą mieć problem z dopuszczeniem narzędzia, którego nie mogą zweryfikować.

• Potencjalne luki typu zero-day: W globalnej społeczności open-source informacje o lukach szybciej wypływają (czasem to minus – bo i przeciwnik może je zobaczyć – ale i plus, bo więcej oczu je znajduje). Gdy ATAK jest rozwijany zamknięcie, istnieje ryzyko, że luka zostanie wykryta i wykorzystana zanim zostanie oficjalnie załatana, a użytkownicy nawet się o niej nie dowiedzą (o ile DoD nie poinformuje). To zagrożenie szczególnie dla tych, którzy używają ATAK w środowiskach o wysokim ryzyku (np. działania wojenne, gdzie przeciwnik może próbować zakłócić system dowodzenia elektronicznego).

Zdolność do adaptacji i niezależnego rozwoju

Wiele państw i organizacji ceniło ATAK-CIV za to, że mogły go dostosować do własnych potrzeb. Przykładowo:

• Tworzenie wtyczek (pluginów) specyficznych dla danego kraju (np. integracja z krajowym systemem meldunkowym, własnymi sensorami, dronami, tłumaczenie interfejsu na język lokalny itp.). Nadal można pisać pluginy korzystając z SDK, ale plugin ma ograniczony zakres – jeśli potrzebna modyfikacja sięga głębiej (np. zmiana sposobu szyfrowania, obsługa nowych protokołów radiowych), to bez kodu źródłowego może to być niemożliwe.

• Szkolenie i budowanie kompetencji lokalnych: Mając kod, lokalne instytuty czy firmy mogły szkolić programistów w zakresie systemów TAK, analizować algorytmy (np. wyświetlania map, obliczania stref rażenia itp.) i przez to rozwijać krajową myśl technologiczną w sferze C2 (dowodzenia i kontroli). Teraz ten aspekt znika – rozwój odbywa się za oceanem, a lokalnie pozostaje jedynie użytkowanie. Może to prowadzić do stagnacji kompetencyjnej: "know-how" pozostaje w rękach USA.

• Elastyczność adaptacji pola walki: W konfliktach nowego typu (np. hybrydowych) szybka adaptacja narzędzi może dawać przewagę. Gdyby np. państwo X zauważyło potrzebę wprowadzenia nowego rodzaju znaczników czy logiki w ATAK do walki z dronami – posiadając kod mogło to zrobić natychmiast we własnym zakresie. Bez kodu – musi prosić dostawcę o funkcjonalność i czekać. Czas reakcji znacznie się wydłuża. W dynamicznym środowisku operacyjnym, ta zależność od obcego cyklu wydawniczego bywa krytyczna.

Podsumowując, kraje korzystające z ATAK tracą pewną dozę niezależności technologicznej. Muszą zważyć korzyści (sprawdzony, zaawansowany system o dużych możliwościach) z kosztami (utrata kontroli, ryzyka bezpieczeństwa, polityczne uwarunkowania). 

Każda z powyższych opcji ma swoje plusy i minusy. Wybór zależeć będzie od priorytetów danego kraju: czy ważniejsza jest integracja z USA i natychmiastowy dostęp do  technologii (wtedy pozostaną przy ATAK pomimo ryzyk), czy też niezależność i bezpieczeństwo informacji (wtedy będą szukać własnych rozwiązań). 

Być może pojawi się hybrydowe podejście, gdzie np. część sił (siły specjalne) używa odseparowanego, własnego systemu, a reszta (wojska regularne) – standardowego ATAK dla kompatybilności z sojuszem.

Potencjalne scenariusze geopolityczne

Zmiany wokół systemu ATAK/TAK mogą wywołać szereg długofalowych skutków geopolitycznych. Systemy dowodzenia i łączności mają strategiczne znaczenie – decydują o zdolności do prowadzenia nowoczesnych, połączonych operacji. Poniżej kilka scenariuszy, które decydenci powinni brać pod uwagę:

• Scenariusz 1: Utrwalenie przewagi technologicznej USA w koalicjach – Zamknięcie kodu i scentralizowanie kontroli nad TAK może oznaczać, że USA stanie się niekwestionowanym dostawcą technologii C2 dla sojuszników. Kraje, które przy ATAK pozostaną, będą de facto korzystać z rozwiązania amerykańskiego na amerykańskich warunkach. W efekcie USA zyskuje miękką władzę: decyduje, jakie funkcje dostaną partnerzy, kiedy dostaną aktualizacje, a także może wglądać (przynajmniej potencjalnie) w architekturę systemu używanego przez innych. To wzmacnia zależność sojuszników od USA w sferze wojskowej – podobnie jak np. uzależnienie od dostaw amunicji czy komponentów uzbrojenia, uzależnienie od krytycznego oprogramowania to narzędzie nacisku i wpływu politycznego. Dla USA korzystny, ten scenariusz może budzić dyskomfort wśród sojuszników, ale wielu z nich może uznać, że „nie ma alternatywy, a korzyści przeważają”. Konsekwencją może być zacieśnienie formalnych ram współpracy (np. programy FMS, wspólne ćwiczenia w oparciu o ATAK, itp.) i standaryzacja doktryn pod amerykańskie C2.

• Scenariusz 2: Fragmentacja – powstanie konkurencyjnych systemów – Alternatywnie, niektóre państwa lub bloki (np. Unia Europejska) mogą potraktować zamknięcie ATAK jako sygnał ostrzegawczy i przyspieszyć prace nad własnymi systemami świadomości sytuacyjnej. Jeśli taka decyzja zapadnie, za kilka lat możemy mieć do czynienia z podziałem technologicznym: np. kraje Five Eyes i najbliżsi sojusznicy używają ATAK/TAK, podczas gdy inne kraje NATO (lub spoza NATO) używają innego systemu (nazwijmy go EU-TAK czy NATO-TAK). Może to iść dalej – Chiny czy Rosja zapewne rozwijają swoje odpowiedniki (Rosja od lat inwestuje w systemy ESU TZ i inne do sieciocentryczności). W skali globalnej mogłyby wyłonić się dwa-trzy standardy konkurencyjne. To utrudni współpracę międzynarodową w różnych koalicjach (np. państwo spoza kręgu USA może nie chcieć udostępniać swojego obrazu sytuacji przez amerykański system, i odwrotnie). Taki podział analogiczny jest do np. systemów łączności (NATO vs rosyjskie) – prowadzi do powstania „technologicznych sfer wpływów”. Z geopolitycznego punktu widzenia, technologia ATAK stałaby się wtedy jednym z atrybutów przynależności do konkretnego bloku sojuszniczego.

• Scenariusz 3: Wykorzystanie luki przez rywali – Jeśli niektóre kraje zrażone zamknięciem ATAK zaczną szukać alternatyw, może to zostać wykorzystane przez mocarstwa konkurencyjne. Np. Chiny mogłyby zaoferować krajom rozwijającym się swój system świadomości sytuacyjnej jako część pakietu wyposażenia (podobnie jak oferują drony czy systemy łączności). Chińska filozofia technologiczna często podkreślała kontrolę i suwerenność cyfrową – być może w kontrze do rozwiązań amerykańskich, Chiny mogłyby promować coś “open-source’owego” (przynajmniej z nazwy) lub po prostu atrakcyjnego cenowo i pod kontrolą lokalnego rządu (choć w praktyce kontrolowanego przez Chiny). To rozszerza ich wpływy i może podkopywać pozycję USA w niektórych regionach. Przykład: jeśli państwa Bliskiego Wschodu czy Azji Południowo-Wschodniej uznają, że ATAK jest dla nich teraz mniej dostępny, a pojawi się alternatywa z Chin, może nastąpić technologiczne zbliżenie z Chinami kosztem relacji z USA.

• Scenariusz 4: Ograniczenie transferu danych w misjach międzynarodowych – Nawet w ramach istniejących sojuszy (np. operacje ONZ, UE, NATO), kwestia kto kontroluje infrastrukturę informacyjną jest drażliwa. Jeśli np. w misji pokojowej biorą udział kontyngenty z różnych państw, a system dowodzenia oparty jest na ATAK dostarczonym przez USA, może pojawić się opór niektórych uczestników co do pełnego udostępniania danych. W praktyce może to skutkować zmniejszonym poziomem dzielenia się informacją – np. pewne dane będą trzymane “offline” lub przekazywane tradycyjnymi kanałami zamiast w systemie, co zredukuje efektywność wspólnego obrazu sytuacji. To subtelny efekt, ale realny: brak zaufania do systemu informatycznego przekłada się na niepełne jego wykorzystanie. Decydenci muszą być świadomi, że technologia działa optymalnie tylko w środowisku zaufania – a tutaj to zaufanie mogło zostać nadwyrężone.

• Scenariusz 5: Rozwój inicjatyw open-source obronnych – Zamknięcie tak szeroko używanego projektu open-source może zjednoczyć społeczność i pewne instytucje wokół idei otwartych standardów w obronności. Być może NATO lub UE zainicjują projekty na zasadzie open-source, aby uniknąć powtórki sytuacji. Już dziś istnieją zalążki (FreeTAKServer, OpenTAK Conference). W przyszłości możemy zobaczyć więcej konferencji, hackathonów i funduszy przeznaczonych na otwarte technologie wojskowe, jako przeciwwagę dla uzależnienia od pojedynczego dostawcy. To oczywiście będzie się działo w niszy (ze względów bezpieczeństwa państwa niechętnie otwierają wszystko), ale np. otwarte API czy formaty danych mogą stać się wymogiem w przetargach wojskowych. Geopolitycznie, promowanie otwartości mogłoby być kartą przetargową np. UE: “nasze rozwiązania – w przeciwieństwie do amerykańskich czy chińskich – dają wam kod i kontrolę”.

Wszystkie powyższe scenariusze nie są wzajemnie wykluczające się – możliwa jest ich kombinacja w różnych częściach świata. Dla decydentów kluczowe jest rozumienie, że technologiczna decyzja o zamknięciu kodu ATAK niesie ze sobą skutki wykraczające poza sferę czysto informatyczną – dotyka zaufania sojuszniczego, potencjału operacyjnego oraz rywalizacji o wpływy.

Zalecenia strategiczne

Biorąc pod uwagę powyższą analizę, przedstawiamy następujące zalecenia dla wojskowych analityków i decydentów politycznych:

1. Dokonanie przeglądu zależności od ATAK/TAK: Każde państwo korzystające z ATAK powinno przeprowadzić kompleksowy audyt: które jednostki i w jakim stopniu są uzależnione od tego systemu? Jakie dane przez niego przepływają? Czy istnieją procedury awaryjne na wypadek utraty dostępu lub kompromitacji systemu? Taki przegląd pozwoli oszacować ryzyko na poziomie strategicznym.

2. Wzmocnienie kontroli nad infrastrukturą: Jeżeli decyzją władz jest dalsze korzystanie z ATAK, należy zainwestować w własną infrastrukturę towarzyszącą. Oznacza to uruchomienie i utrzymywanie własnych serwerów TAK (czy to oficjalnych przez licencję, czy open-source FreeTAKServer) w kraju, pod nadzorem wojskowych służb łączności. Dane z sieci operacyjnych nie powinny domyślnie trafiać na serwery poza kontrolą kraju. Warto też regularnie monitorować ruch sieciowy aplikacji i stosować zapory sieciowe, aby zapewnić, że komunikacja odbywa się tylko z autoryzowanymi węzłami.

3. Domaganie się przejrzystości od dostawcy: W ramach relacji sojuszniczych, można oficjalnie zapytać stronę amerykańską o powody zamknięcia kodu i ewentualne mechanizmy weryfikacji bezpieczeństwa. Być może DoD mógłby, dla najbardziej zaufanych partnerów, udostępnić kod źródłowy do wglądu (bez prawa modyfikacji) w celach audytu. Nawet jeśli jest to mało prawdopodobne, samo zgłoszenie takiej potrzeby sygnalizuje, że temat nie pozostaje niezauważony.

4. Rozwój własnych kadr i kompetencji: Niezależnie od losów ATAK, warto inwestować w krajowych ekspertów od systemów C2 i oprogramowania GIS. Można np. uruchomić programy w uczelniach wojskowych lub technicznych skupione na tworzeniu aplikacji taktycznych. Kadra, która poznała ATAK 4.x (dostępny kod), może posłużyć jako zalążek zespołów rozwijających autorskie modyfikacje lub całkiem nowe projekty. Chodzi o to, by nie przerwać ciągłości wiedzy – gdy ludzie przestaną zaglądać w kod (bo go nie ma), łatwo zatracić umiejętności. W razie potrzeby szybkiego stworzenia alternatywy, własne kadry będą nieocenione.

5. Ocena alternatyw w ramach sojuszy: Na forum np. Europejskiej Agencji Obrony (EDA) lub NATO STO (Science and Technology Organization) warto podnieść temat otwartych standardów dla systemów świadomości sytuacyjnej. Można rozważyć międzynarodowy projekt (np. w ramach NATO) stworzenia interfejsu wymiany danych, który umożliwi współdziałanie różnych systemów (ATAK i potencjalnych innych) w ramach ćwiczeń czy operacji. Taki ruch zmniejszyłby negatywny efekt ewentualnej fragmentacji – nawet jeśli powstaną różne systemy, to przy wspólnych standardach komunikacji nadal będą mogły współpracować. NATO już teraz korzysta z formatu CoT (Cursor on Target) w ATAK, ale formalizacja i rozszerzenie tej standaryzacji (by obejmowała np. pełne API do zarządzania zdarzeniami, nie tylko prosty format) byłaby korzystna.

6. Śledzenie inicjatyw open-source: Rekomenduje się trzymać rękę na pulsie społeczności. Jeśli powstanie fork ATAK lub nowy projekt open-source o zbliżonej funkcjonalności, warto go obserwować, a nawet wesprzeć (finansowo lub kontrybucją kodu). Dla decydentów wojskowych może to brzmieć nietypowo – wspierać oddolny projekt – ale w dłuższej perspektywie może on stać się planem B. Jego istnienie może też wywierać presję konkurencyjną na dostawcę oryginalnego ATAK, by utrzymywał pewne otwarte elementy.

7. Analiza prawna licencji i możliwości działania: Trzeba sprawdzić, pod jaką licencją był publikowany ATAK-CIV (prawdopodobnie domena publiczna w USA lub zbliżona). Jeśli to domena publiczna, to nic nie stoi na przeszkodzie, by brać ten kod i z nim pracować dalej, co czyni forki legalnymi. Jeśli jednak były tam komponenty GPL, to być może DoD nadal ma obowiązek udostępniać kod na żądanie dla tych części (GPL wymaga udostępnienia kodu źródłowego odbiorcom binariów). Jeden z dyskutantów na forum zauważył, że „Under the GPL, the source should be available somewhere for free download.”. To sygnał, że mogą istnieć podstawy prawne domagania się kodu (przynajmniej wybranych segmentów) – kwestia warta zbadania przez prawników.

8. Scenariusze ćwiczeń na wypadek utraty systemu: Wreszcie, służby planistyczne powinny włączyć do gier wojennych i ćwiczeń symulacje sytuacji, w których ATAK przestaje być dostępny lub zostaje skompromitowany. Jak wtedy dowódcy radzą sobie z sytuacją? Czy istnieją zapasowe procedury (fallback) do przekazywania informacji? Takie ćwiczenia uświadomią, jak krytyczny stał się ten element i gdzie są największe luki. Pozwoli to zawczasu przygotować plany awaryjne.

Podsumowanie

Zamknięcie dostępu do kodu źródłowego systemów z rodziny TAK (ATAK/ATAK-CIV i prawdopodobnie TAKX) w 2025 roku jest wydarzeniem o dużym znaczeniu. Z jednej strony podkreśla dążenie USA do ochrony swoich przewag technologicznych i kontroli nad dystrybucją zaawansowanych narzędzi dowodzenia. Z drugiej – stawia użytkowników z innych krajów przed dylematem: czy zaufać w pełni rozwiązaniu pozostającemu pod cudzą jurysdykcją, czy szukać dróg do większej niezależności?.

Wersja 5.1 ATAK z funkcjami raportowania danych do DoD symbolicznie pokazuje kierunek – centralizacja i sieciocentryczność kontrolowana przez dostawcę. Dla USA i wielu sojuszników może to oznaczać lepszą integrację operacyjną. Ale dla tych, którzy cenią autonomię informacyjną, rodzi się potrzeba planów alternatywnych.

Państwa korzystające z ATAK muszą teraz chłodno przeanalizować ryzyka i korzyści. Niewątpliwie ATAK jest znakomitym narzędziem, sprawdzonym i rozwijanym latami – rezygnacja z niego to utrata konkretnych zdolności. Jednak poleganie na nim bez zabezpieczeń to potencjalny słaby punkt bezpieczeństwa narodowego. Decyzje nie będą łatwe, ale muszą być podejmowane świadomie.

W świecie coraz bardziej cyfrowego pola walki, kontrola nad kodem staje się równie ważna jak kontrola nad sprzętem. Incydent z ATAK jest cenną lekcją: nawet programy open-source mogą zmienić status w zależności od interesów państwowych. Dla analityków i decydentów to przypomnienie, by zawsze mieć plan na wypadek czarnego scenariusza i by aktywnie kształtować środowisko technologiczne, a nie tylko z niego korzystać. 

Jak mawiają wojskowi – „ufaj, ale sprawdzaj” – co w kontekście oprogramowania można parafrazować: „używaj, ale miej wgląd albo alternatywę”.

Źródła:

1. GitHub – ATAK-CIV repo (archiwizacja): “This repository was archived by the owner on May 2, 2025. It is now read-only.” – informacja na stronie repozytorium ATAK-CIV - github.com.

2. Reddit (r/ATAK) – dyskusja użytkowników nt. zamknięcia kodu (maj 2025): wskazano brak aktualizacji na GitHub od dawna i przejście projektu do wewnętrznego repo tak.gov, sugerując że projekt staje się zamknięty - reddit.com.

3. TAK.gov – Usage Statement: oficjalne stanowisko DoD nt. dystrybucji ATAK – ATAK-MIL tylko dla USA (FMS), ATAK-CIV jako open-source EAR99 - tak.govtak.gov.

4. CivTAK (portal społeczności) – informacja o wyborze ATAK przez armię brytyjską: “TAK has been selected as the preferred BMA solution for the British Army’s DSA programme… Dalby confirmed that the British Army will utilise the military version of ATAK.” - civtak.orgcivtak.org.

5. TAK.gov – opis TAK Server i TAK Tracker: podkreśla centralną rolę serwera i możliwość wysyłania lokalizacji - “TAK Server… is required whenever TAK clients are not operating in a peer-to-peer network… TAK Tracker is a lightweight standalone android application for sending location information to a TAK Server.” - tak.govtak.gov

6. Google Play – opis ATAK-CIV: wskazuje na zgodność z infrastrukturą DoD i pracę sieciową. (polski): “Silnik geoprzestrzenny i komponent komunikacyjny obsługują standardy Departamentu Obrony (DoD)… Rozszerzalność platformy wspierana przez SDK (tak.gov)… Dane mogą być wstępnie ładowane do ATAK lub pobierane z sieci…” - play.google.com

7. Reddit (r/ATAK) – dyskusja o przyszłości open-source: użytkownicy sugerują możliwość forków lub reimplementacji: “Determined threat actor could reverse engineer. And I see a fork popping up and a fork/reimplementation for WinTAK…” - reddit.com

8. CivTAK.org – FreeTAKServer: przykład alternatywy open-source po stronie serwera - “An open source version of a TAKServer, called TAKFreeServer, has been released on GitHub… This is a great development for the TAK Community…” - civtak.org

9. Booz Allen – Sit(x) promo: przykład komercyjnej alternatywy oferującej interoperacyjność z ATAK - “Use Sit(x)® on its own or with ATAK to chat with groups, push data to others, and see your teammates' actions… Sit(x)® Mobile… operating within AWS GovCloud to ensure secure, scalable deployment for TAK users” - boozallen.com

10. Wypowiedzi użytkowników (Reddit, inne) dotyczące obaw i uprawnień: wskazywano, że ATAK wymaga wielu uprawnień na urządzeniu i budzi to niepokój co do prywatności/czy nie zbiera danych nadmiarowych (wzmianek brak w tekście głównym, ale to część szerszego kontekstu zaufania do aplikacji). - reddit.com