Open source ≠ suwerenność: licencje i co-option chmury

W Suwerennym IDP założyłem, że fundamentem przenośności jest otwarte tooling. Sam przez lata powtarzałem sobie wygodny mit: „open source jest z definicji suwerenny i wolny od lock-inu”. Nauczyłem się — nieraz boleśnie — że to nieprawda, a trend idzie w niekorzystną stronę. Otwarta licencja to warunek konieczny, ale daleko niewystarczający.

Cztery sposoby, w jakie „otwarte” przestaje być wolne

Open source bywa fundamentem suwerenności, ale kilka strukturalnych nacisków tę przewagę eroduje.

Trend	Przykłady	Ryzyko dla suwerenności
Open core	Backstage, Elasticsearch, MongoDB, Terraform	Rdzeń otwarty, funkcje enterprise zamknięte — migrujesz do open source, a potem wpadasz w komercyjny lock-in na kluczowych zdolnościach
Zmiany licencji	Elastic (SSPL), MongoDB (AGPL→SSPL), HashiCorp (BSL)	Przejście z licencji permisywnej łamie zaufanie i retroaktywnie ogranicza użycie
Co-option przez chmury	repackaging projektów jako usługi zarządzane	Hyperscaler dokłada warstwy proprietary, odtwarzając lock-in, którego projekt miał unikać
Przejęcia	Red Hat (IBM), GitHub (Microsoft), HashiCorp (IBM)	Priorytety społeczności zmieniają się po akwizycji

Każdy z tych mechanizmów może zamienić „otwarte” narzędzie w pułapkę — nie z dnia na dzień, lecz stopniowo, gdy już jesteś od niego zależny.

Praktyczne wnioski

Z tej diagnozy płyną trzy zasady projektowania suwerennego toolingu:

• Suwerenność wymaga czystego, społecznościowego open source. Modele open-core to świetne punkty wejścia, ale ich warstwy enterprise SaaS są produktami komercyjnymi. Prawdziwa autonomia opiera się na nieskrępowanym, swobodnie modyfikowalnym rdzeniu.
• Zmiany licencji erodują zaufanie. Audytuj licencje przed adopcją i monitoruj zmiany. To argument za stawianiem na projekty pod skrzydłami fundacji (Linux Foundation, CNCF), które gwarantują, że rdzeń pozostanie otwarty i zarządzany przez społeczność.
• Chmury co-optują open source. Usługi zarządzane oparte na otwartych projektach często dokładają warstwy proprietary, odtwarzające lock-in, którego oryginał miał unikać.

Case: OpenTofu jako odpowiedź na BSL

Najczystszy przykład to fork Terraform po zmianie jego licencji na BSL. Społeczność odpowiedziała OpenTofu — zgodnym składniowo (HCL, format stanu, ekosystem providerów) zamiennikiem pod Linux Foundation, co gwarantuje, że silnik definiujący infrastrukturę organizacji pozostaje otwarty i wolny od przechwycenia przez jeden podmiot.

W praktyce dla większości projektów migracja jest niemal wymianą binarki:

# ten sam kod .tf, moduły i providerzy — inna komenda
tofu init
tofu plan
tofu apply

To pokazuje, czym jest „sovereign-ready”: nie samą licencją, lecz realną możliwością odejścia bez przepisywania całej infrastruktury.

Kryteria wyboru sovereign-ready tooling

Praktyczna lista kontrolna przy ocenie narzędzia do platformy:

• Self-hosting — czy da się uruchomić w pełni we własnej jurysdykcji, także air-gapped?
• Migrowalność — czy istnieje droga wyjścia bez zależności od jednego dostawcy (otwarte formaty, standardy)?
• Governance — czy projekt jest pod fundacją / wieloma kontrybutorami, czy kontroluje go jeden komercyjny właściciel?
• Licencja — permisywna/community, nie BSL/SSPL; z historią stabilności.
• Brak ukrytego open-core — czy funkcje krytyczne dla Ciebie są w otwartym rdzeniu, czy za płatną bramką?

Przez ten pryzmat warto patrzeć na cały katalog narzędzi platformy — od VCS (Gitea), przez GitOps (Argo CD), po rejestry (Harbor).

Niuans: governance to też proces, nie tylko licencja

Suwerenność toolingu łączy się z szerszym tematem zarządzania zmianą — jak projekt (i Twoja organizacja) panuje nad wersjami, kompatybilnością i procesem wydań. To, co pisaliśmy o deterministycznym, opartym na regułach procesie w artykule o wersjonowaniu, dotyczy także zaufania do zależności: przewidywalny, otwarty proces wydawniczy jest częścią „sovereign-ready”.

Podsumowanie

„Open source” na etykiecie nie wystarcza. Liczy się, czy możesz narzędzie self-hostować, nim operować i od niego odejść — bez łaski jednego komercyjnego właściciela. Open-core, zmiany licencji, co-option przez chmury i przejęcia to realne wektory utraty autonomii. Dlatego sovereign-ready tooling rozpoznajesz nie po licencji, lecz po przenośności i governance — a fundacje takie jak Linux Foundation czy CNCF są tu Twoim najlepszym sojusznikiem. Następnym razem, gdy zobaczysz łatkę „open source”, zadaj trzy pytania: self-host, operowanie, wyjście. Reszta to marketing.