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

> Otwarta licencja nie wystarcza do suwerenności. Open-core, zmiany licencji (BSL/SSPL), repackaging przez chmury i przejęcia — oraz test, który naprawdę definiuje sovereign-ready tooling.

URL: https://eiac.dev/blog/open-source-a-suwerennosc
Filar: Infrastructure-as-Code
Data: 2026-04-24
Tagi: sovereignty, open-source, licensing, iac

---

W [Suwerennym IDP](/blog/suwerenny-idp-exit-by-design) 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.

<div class="callout">
<strong>Teza</strong>
<p>Testem suwerenności nie jest to, czy narzędzie ma licencję open source. Testem jest, czy organizacja może je <em>self-hostować, operować i zmigrować</em> bez zależności od jednego podmiotu komercyjnego.</p>
</div>

## 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](/katalog/terraform) po zmianie jego licencji na BSL. Społeczność odpowiedziała [OpenTofu](/katalog/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:

```bash
# 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](/katalog/gitea)), przez GitOps ([Argo CD](/katalog/argo-cd)), po rejestry ([Harbor](/katalog/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](/blog/wersjonowanie-semver-conventional-commits), 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.