Czy mogę zabronić komuś korzystania z programu z licencją open source?

Czy mogę zabronić korzystania z oprogramowania open source? Brak wykluczeń

Zrozumienie tego, czy mogę zabronić korzystania z oprogramowania open source, jest kluczowe dla ochrony Twoich praw autorskich i uniknięcia błędów prawnych. Niewłaściwe ograniczenie dostępu prowadzi do naruszenia standardów licencyjnych i problemów z globalną infrastrukturą kodu. Warto poznać te reguły, aby skutecznie zarządzać projektami i uniknąć niepotrzebnych sporów z użytkownikami.

Krótka odpowiedź: Czy to w ogóle możliwe?

Pytanie to może mieć kilka różnych interpretacji, ale odpowiedź jest jednoznaczna. Nie, nie możesz zablokować komuś dostępu, jeśli używasz prawdziwej licencji open source. Z definicji takie oprogramowanie nie pozwala na dyskryminacja użytkowników open source ani celów, w jakich kod jest wykorzystywany. Jeśli chcesz zablokować użytek komercyjny, musisz wybrać zupełnie inny typ licencji.

Szacuje się, że około 96% nowoczesnych komercyjnych baz kodu zawiera komponenty open source.^[1] Dlaczego to takie ważne? Ponieważ cała ta globalna infrastruktura opiera się na jednej, absolutnej zasadzie: braku wykluczeń. Kiedy udostępniasz kod na licencji takiej jak MIT czy Apache, zgadzasz się, że kto może korzystać z open source. Tak, nawet Twoja największa i najbardziej agresywna konkurencja na rynku.

To bywa bolesne. Ale jest pewien krytyczny błąd, który popełnia około 80% początkujących twórców, gdy próbują ten system obejść - wyjaśnię go dokładnie w sekcji dotyczącej definicji OSI poniżej.

Dlaczego prawdziwy Open Source zakazuje dyskryminacji

Bądźmy szczerzy - wizja tego, że gigantyczna korporacja bierze Twój darmowy kod, pakuje go w swój produkt i zarabia na nim miliony bez słowa dziękuję, potrafi mocno irytować. To naturalne, że chcemy chronić owoce swojej pracy przed wykorzystaniem przez podmioty, z którymi się nie zgadzamy ideologicznie lub biznesowo.

Szczerze mówiąc, sam kiedyś wpadłem w tę pułapkę. Napisałem świetne, lekkie narzędzie do analizy logów i udostępniłem je na GitHubie. Do pliku licencji dopisałem jedno zdanie zakazujące używania mojego kodu firmom z branży zbrojeniowej. Myślałem, że to genialny ruch. Szybko się okazało, jak bardzo się myliłem. Otrzymałem dziesiątki zgłoszeń od innych programistów informujących mnie, że mój projekt nie jest już open source. Usunięcie tej jednej klauzuli zajęło mi kilka dni walki z własnym ego.

Święte zasady: Punkty 5 i 6 definicji OSI

Oto ten krytyczny błąd, o którym wspomniałem wcześniej: modyfikowanie standardowych licencji. Aby oprogramowanie mogło być oficjalnie nazwane open source, musi spełniać 10 warunków Open Source Initiative (OSI). Dwa z nich są tutaj absolutnie kluczowe.

Punkt piąty zabrania dyskryminacji osób lub grup. Nie możesz napisać w licencji, że zakazujesz używania programu mieszkańcom konkretnego kraju, zwolennikom danej partii politycznej czy pracownikom wybranej firmy. Punkt szósty idzie o krok dalej - zabrania dyskryminacji ze względu na cel użycia. Oznacza to, że analizując ograniczenia licencji open source, nie możesz zakazać wykorzystywania Twojego kodu do badań genetycznych czy budowania komercyjnych platform e-commerce.

Kod publiczny to nie zawsze Open Source

Zazwyczaj początkujący mylą dwa pojęcia: open source oraz source-available. To, że wrzucisz swój kod na publiczne repozytorium i każdy może go przeczytać, nie czyni go oprogramowaniem o otwartym źródle w sensie prawnym. Czasem to po prostu darmowa wystawa w sklepie, w którym niczego nie można dotykać.

Jeśli chcesz mieć pełną kontrolę nad tym, kto korzysta z Twojego rozwiązania, powinieneś zrezygnować z nazwy open source. Zamiast tego powinieneś sprawdzić, czy można zakazać używania open source poprzez inne modele prawne, które udostępniają kod, ale nakładają restrykcje biznesowe.

Porównanie: Open Source vs Source-Available

Licencje Permisywne (MIT, Apache 2.0)

• Maksymalna - kod może być łatwo łączony z innymi projektami

• Surowo wzbroniona zgodnie z definicją OSI

• Zawsze w pełni dozwolony, bez żadnych opłat i ograniczeń

Licencje Copyleft (GPL v3)

• Ograniczona - zmusza projekty pochodne do przyjęcia tej samej licencji

• Wzbroniona, ale restrykcje copyleft często odstraszają korporacje

• Dozwolony, ale wymaga udostępnienia zmodyfikowanego kodu źródłowego

Source-Available (BSL, SSPL) ⭐

• Bardzo niska - odrzucana przez społeczność purystów wolnego oprogramowania

• Dozwolona - można wykluczyć konkretnych konkurentów lub branże

• Często ograniczony lub całkowicie zabroniony w zastosowaniach produkcyjnych

Frustracja i nauka: Jak Marek próbował zablokować korporacje

Marek, programista backendowy z Krakowa, spędził około 4 miesiące po godzinach, tworząc niezwykle szybką bibliotekę do przetwarzania płatności. Udostępnił ją początkowo na GitHubie z własną, ręcznie napisaną licencją, która pozwalała na darmowy użytek tylko dla startupów zatrudniających poniżej 10 osób.

Szybko zderzył się ze ścianą. Duży bank był zainteresowany jego rozwiązaniem, ale ich dział prawny natychmiast odrzucił projekt ze względu na niejasną, niestandardową licencję. Z kolei inni deweloperzy omijali repozytorium, bo narzędzia automatyczne oznaczały je jako niekompatybilne z ekosystemem open source.

Marek próbował negocjować z bankiem indywidualne warunki, ale proces trwał tygodniami i pochłaniał jego energię. Zrozumiał, że niestandardowe restrykcje zabiły całkowicie organiczny rozwój jego narzędzia. Frustracja była ogromna.

Ostatecznie zmienił strategię na model dual-licensing. Podstawowy kod został opublikowany na licencji GPL v3, co zniechęciło korporacje do zamykania jego kodu we własnych produktach, ale pozwoliło mu sprzedawać komercyjne licencje bez tych restrykcji. Po tej zmianie adopcja narzędzia znacząco wzrosła w ciągu pół roku, a on zyskał kilku płacących klientów korporacyjnych. ^[2]