Open source czy tylko „dostępny kod"? Sprawdź licencję

Coraz więcej narzędzi do integracji e-commerce reklamuje się jako „open source”. Część rzeczywiście nim jest. Część ma kod widoczny publicznie — ale to nie to samo. Różnica jest prawna, konkretna i ma bezpośrednie konsekwencje dla tego, jak możesz używać oprogramowania w swoim biznesie. Ten wpis tłumaczy ją bez zbędnego prawniczego języka.

Zaznaczmy od razu: nie jesteśmy prawnikami i to nie jest porada prawna. To wyjaśnienie pojęć, które pomoże Ci zadać właściwe pytania — a przy poważnej decyzji i tak warto sprawdzić regulamin konkretnej licencji albo skonsultować go z kimś, kto się na tym zna.

Czym jest open source — i czym zarazem nie jest

„Open source” ma konkretną, formalną definicję. Określa ją Open Source Initiative (OSI) — organizacja, która od 1998 roku zatwierdza licencje spełniające tzw. Open Source Definition. Licencja jest open source, jeśli m.in. pozwala na swobodne używanie, modyfikowanie i dystrybuowanie oprogramowania w dowolnym celu, w tym komercyjnym, bez dodatkowych ograniczeń.

Licencje zatwierdzone przez OSI to m.in. MIT, Apache 2.0, GPL, AGPL. Każda daje w szczegółach inne prawa, ale wszystkie spełniają ten sam podstawowy warunek: możesz użyć kodu bez pytania kogokolwiek o pozwolenie na konkretny sposób użycia.

Licencje, które nie są open source w rozumieniu OSI, to m.in. Elastic License 2.0 (ELv2), Server Side Public License (SSPL) i Business Source License (BSL). Żadna z nich nie jest zatwierdzona przez OSI i nie kwalifikuje się jako open source — niezależnie od tego, jak producent je opisuje w materiałach marketingowych. Kod jest widoczny publicznie, ale licencja nakłada konkretne zakazy na sposób użycia. Nazywa się to source-available — kod dostępny publicznie, ale nie wolny.

Co możesz zrobić z oprogramowaniem — zależy od licencji

Trzy licencje, które najczęściej spotkasz w narzędziach e-commerce, różnią się fundamentalnie — nie w szczegółach, ale w tym, co wolno Ci z nimi zrobić.

Apache 2.0 — możesz używać oprogramowania do dowolnego celu, w tym komercyjnego. Możesz je modyfikować, wdrożyć u klienta, budować na nim własne rozwiązania i je sprzedawać, a nawet hostować je jako usługę dla innych. Jedyny wymóg to zachowanie informacji o licencji i prawach autorskich w dystrybucji. Apache 2.0 zawiera też jawne udzielenie licencji patentowej (explicit patent grant) — każdy kontrybutor automatycznie udziela Ci licencji patentowej, co ma znaczenie w środowiskach enterprise, gdzie ryzyko patentowe jest realne.

Elastic License 2.0 (ELv2) — możesz używać, kopiować, modyfikować i dystrybuować oprogramowanie, ale ELv2 zabrania oferowania go jako hostowanego serwisu dla innych. W praktyce oznacza to, że agencja nie może wdrożyć takiego oprogramowania u klienta jako usługę — tylko jako instalację, którą klient sam utrzymuje. ELv2 zawiera też klauzulę zakazującą obchodzenia funkcji klucza licencyjnego — nie możesz technicznie ominąć wbudowanych mechanizmów kontroli licencji, nawet mając dostęp do kodu.

SSPL (Server Side Public License) — możesz używać i modyfikować, ale jeśli udostępniasz oprogramowanie innym jako usługę, musisz publicznie ujawnić nie tylko swoje modyfikacje, ale cały kod infrastruktury stojącej za tą usługą — bazy danych, monitoring, narzędzia deploymentu. W praktyce firmy z zamkniętym kodem rzadko mogą pozwolić sobie na SSPL w produktach komercyjnych, bo ceną za świadczenie usługi jest ujawnienie całej architektury technicznej.

Co to oznacza dla sprzedawcy

Jeśli wybierasz narzędzie do integracji sklepu z marketplace’ami i zastanawiasz się, czy jest „naprawdę open source” — zadaj jedno proste pytanie: pod jaką licencją jest wydane? Cała różnica między licencją open source a source-available sprowadza się do odpowiedzi na to jedno pytanie.

Jeśli odpowiedź brzmi Apache 2.0, MIT lub inna licencja z listy OSI — masz gwarancję, że zasady nie zmienią się pod Twoją instalacją. Licencje OSI są nieodwołalne dla już wydanych wersji: producent nie może wstecznie zablokować Ci dostępu do kodu ani zmienić warunków użycia oprogramowania, które już masz. (Warto wiedzieć, że samo udzielenie licencji patentowej w Apache 2.0 może wygasnąć, jeśli to Ty pozwiesz kogoś o naruszenie patentu — ale prawo do używania kodu zostaje.)

Przykład z życia: sklep wdraża narzędzie integracyjne pod licencją source-available. Po roku producent zmienia warunki — nowa wersja ma większe ograniczenia. Przy Apache 2.0 stara wersja zostaje na starych warunkach na zawsze. Przy source-available — zależy to od regulaminu, który realnie czytasz dopiero wtedy, gdy już coś zainstalujesz.

Jeśli odpowiedź brzmi Elastic License, SSPL albo po prostu „source-available” — sprawdź regulamin dokładnie, bo prawo do użycia może zależeć od tego, jak korzystasz z narzędzia. To nie zarzut, tylko fakt, którym warto zainteresować się na etapie podejmowania decyzji, a nie po wdrożeniu.

Co to oznacza dla agencji i dewelopera

Dla agencji, która chce wdrażać narzędzie u klientów albo budować na nim własne usługi, licencja ma jeszcze bardziej bezpośrednie konsekwencje.

Co chcesz zrobić	Apache 2.0	Elastic License 2.0
Wdrożyć u klienta jako instalację	✅	✅
Utrzymywać jako usługę dla klienta	✅	⚠️ wymaga analizy
Modyfikować kod i zachować zmiany jako własność	✅	✅
Budować własne produkty na bazie kodu	✅	✅ z ograniczeniami
Oferować jako hostowany SaaS dla wielu klientów	✅	❌
Użyć bez konsultacji prawnej	✅	⚠️ zalecana konsultacja

Różnica między „wdrożyłem i przekazałem klientowi do utrzymania” a „utrzymuję to dla klienta jako usługę” bywa subtelna. Przy Apache 2.0 nie ma ona znaczenia prawnego — możesz robić jedno i drugie. Przy Elastic License warto ją skonsultować z prawnikiem, zanim zbudujesz na tym ofertę. Jeśli budujesz usługi wokół OpenLinkera, rozkładamy to na czynniki pierwsze na stronie dla agencji.

Dlaczego to ma znaczenie w e-commerce

Narzędzia do integracji e-commerce są coraz częściej opisywane jako „open source” albo „open” — ale nie zawsze precyzują, pod jaką licencją. Katalogi w rodzaju Open Source Alternatives listują wyłącznie narzędzia z licencjami zatwierdzonymi przez OSI; narzędzia source-available pod SSPL, BSL czy Elastic License się tam nie pojawiają, bo nie spełniają Open Source Definition.

Ma to praktyczne znaczenie w dwóch sytuacjach.

Pierwsza: gdy producent narzędzia zdecyduje się zmienić licencję — co zdarzyło się wielokrotnie (Elasticsearch w 2021, HashiCorp/Terraform w 2023, Redis w 2024). Przy licencji OSI jesteś chroniony: wersja, którą masz, zostaje na zawsze pod tą licencją. Przy source-available nowe wersje mogą mieć inne ograniczenia.

Druga: gdy chcesz sprawdzić, czy w ogóle wolno Ci coś z narzędziem zrobić — przy licencji OSI odpowiedź jest prosta i nie wymaga konsultacji prawnej.

Po której stronie jest OpenLinker

OpenLinker jest wydany na licencji Apache 2.0. Nie source-available, nie licencja z kluczem, nie ograniczenia komercyjne. Możesz go używać, wdrożyć u klienta, budować na nim własne rozwiązania i modyfikować — bez pytania nas o pozwolenie i bez opłat licencyjnych.

Konkretnie oznacza to: brak opłaty od zamówienia, brak miesięcznego abonamentu licencyjnego, kod, który możesz sprawdzić i zmodyfikować, oraz licencja, która nie zmieni się pod Twoją instalacją. Płacisz za własną infrastrukturę i czas dewelopera — to jest całkowity koszt licencji.

OpenLinker jest w fazie alfa, przed wersją 1.0. Wybór Apache 2.0 to świadoma decyzja o tym, jaki projekt chcemy budować — nie zabezpieczenie przed konkurencją, tylko zobowiązanie wobec użytkowników. Licencja to fundament; resztę możesz zobaczyć w kodzie.

Co możesz zrobić teraz

• Zobacz cennik i model kosztów — co realnie płacisz przy self-hostingu, skoro nie ma opłaty licencyjnej ani opłaty od zamówienia.
• Przeczytaj, dlaczego zbudowaliśmy OpenLinkera — skąd wziął się wybór open source jako fundamentu.
• Zastanów się, czy własny system to Twój kierunek — pięć pytań, które pomogą podjąć decyzję, zanim zaczniesz.
• Sprawdź pełną listę integracji — co działa dziś, co w toku, a co dopiero planujemy.
• Zostaw gwiazdkę na GitHubie — jeśli chcesz wesprzeć rozwój otwartego systemu na licencji Apache 2.0.

Licencja to pierwsze pytanie, które warto zadać, a nie ostatnie. My na nie odpowiadamy krótko: Apache 2.0, bez gwiazdek.