Czy oprogramowanie open source ma licencję?

Czy oprogramowanie open source ma licencję? Tak i ma zasady

Czy oprogramowanie open source ma licencję to pytanie, które pomaga zrozumieć zasady korzystania z kodu o otwartym dostępie. Znajomość warunków licencyjnych ogranicza nieporozumienia związane z używaniem, modyfikacją i dystrybucją oprogramowania. Warto poznać podstawowe reguły przed wykorzystaniem projektu.

Czy oprogramowanie open source ma licencję? Kwestie fundamentalne

Tak, oprogramowanie open source zawsze ma licencję, chociaż interpretacja tego faktu często zależy od konkretnego kontekstu prawnego. Otwarty kod źródłowy absolutnie nie oznacza, że oprogramowanie znajduje się w domenie publicznej lub jest pozbawione ochrony prawnej.

Licencja to dokument, który w sposób legalny reguluje zasady korzystania, modyfikowania i rozpowszechniania danego programu. Obecnie większość projektów w głównych repozytoriach używa jasnych deklaracji licencyjnych.^[1] Bez takiego dokumentu kod jest domyślnie objęty pełnymi prawami autorskimi twórcy, co paradoksalnie zabrania jego swobodnego użycia przez innych.

Większość początkujących programistów uważa, że czy kod otwarty jest darmowy i można go po prostu wziąć i skopiować do swojego rozwiązania. Jest jednak jeden bardzo kosztowny błąd, który zrujnował już wiele komercyjnych projektów - wyjaśnię go dokładnie w sekcji o wykorzystaniu komercyjnym poniżej.

Błędne przekonanie: Open source a brak praw autorskich

Czy open source oznacza brak praw autorskich to mit, który nie chce umrzeć. Szczerze mówiąc, sam kiedyś myślałem, że open source znaczy po prostu swobodę robienia czegokolwiek z kodem. To nieprawda.

Kiedyś znalazłem idealną bibliotekę. Szybko ją pobrałem. Wrzuciłem do zamkniętego systemu. Byłem dumny z optymalizacji czasu pracy, dopóki prawnicy nie zablokowali wdrożenia na dwa dni przed premierą. Okazało się, że zignorowałem plik z tekstem prawnym w repozytorium. Kosztowało nas to trzy tygodnie przepisywania całego modułu od zera.

Jak prawo autorskie chroni twórców kodu

Licencja oprogramowania działa jako pomost między twórcą a użytkownikiem. Twórca zachowuje pełne prawa majątkowe i osobiste do swojego dzieła, ale poprzez specjalny dokument udziela ci warunkowego pozwolenia na korzystanie z niego. Analizy pokazują, że znaczna część komercyjnych baz kodu zawiera komponenty o wysokim ryzyku prawnym właśnie z powodu ignorowania jakie są licencje oprogramowania w codziennej praktyce. ^[2]

Zrozumienie lokalnych przepisów: Polskie prawo a licencje międzynarodowe

Wielu polskich twórców ma ogromny problem ze zrozumieniem, jak międzynarodowe dokumenty - pisane zazwyczaj w oparciu o prawo amerykańskie - przekładają się na nasze lokalne prawo autorskie. Zgodnie z polskimi przepisami, każdy programista automatycznie nabywa prawa autorskie w momencie stworzenia chociażby najprostszego skryptu.

Dokumenty takie jak MIT czy Apache 2.0 są w pełni wiążące w Polsce, funkcjonując jako umowy cywilnoprawne. Zrozumienie tego (co zajęło mi sporo czasu na początku kariery) jest absolutnie kluczowe dla bezpieczeństwa każdej firmy.

Należy jednak pamiętać o pewnym paradoksie. Wiele osób uważa, że trzeba podpisywać fizyczne umowy, aby przenieść prawa lub udzielić zgody. W świecie IT wystarczy umieszczenie odpowiedniego pliku tekstowego w głównym katalogu projektu, co z punktu widzenia sądów stanowi wyrażenie woli obu stron.

Czy można sprzedawać oprogramowanie open source?

Oto ten kosztowny błąd, o którym wspomniałem wcześniej: użycie cudzego kodu na licencji wirusowej we własnym, zamkniętym produkcie bez zrozumienia długoterminowych konsekwencji prawnych.

Czy można sprzedawać oprogramowanie open source? Możesz sprzedawać oprogramowanie bazujące na otwartym kodzie. Robią to największe korporacje technologiczne na świecie. Haczyk polega jednak na tym, że jeśli wbudujesz w swój produkt kod objęty licencją GNU GPL (znaną jako wirusową), całe twoje autorskie oprogramowanie musi zostać udostępnione dalej na tych samych, otwartych zasadach.

Wiele osób sądzi, że open source wyklucza zysk. Bądźmy szczerzy - nikt nie tworzy ogromnych systemów serwerowych wyłącznie charytatywnie. W rzeczywistości firmy zarabiają miliony na wsparciu, hostingu i dodatkowych zamkniętych modułach budowanych dookoła otwartego rdzenia.

Szybkie narzędzie decyzyjne: Jaką licencję open source wybrać?

Licencja MIT (Zalecana dla małych projektów)

• Konieczność zachowania oryginalnej informacji o autorach i samej licencji

• W pełni dozwolony w aplikacjach o zamkniętym kodzie

• Bardzo niskie, chętnie wykorzystywana przez korporacje

• Niezwykle swobodna, niemal brak ograniczeń

Licencja Apache 2.0

• Obowiązek dokumentowania wprowadzonych modyfikacji w plikach źródłowych

• W pełni dozwolony bez wymogu otwierania własnego kodu

• Niskie, bardzo bezpieczna pod kątem prawnym

• Średni, zawiera jasne zapisy chroniące przed roszczeniami patentowymi

Licencja GNU GPL (Wirusowa)

• Kod pochodny musi pozostać otwarty (copyleft)

• Dozwolony, ale wymaga udostępnienia całego systemu na tych samych zasadach

• Wysokie, wymaga świadomej izolacji architektonicznej od zamkniętego kodu

• Bardzo wysoki, chroni ideę wolnego oprogramowania

Problemy integracyjne w warszawskim startupie e-commerce

Michał, CTO w szybko rosnącym warszawskim startupie, stanął przed problemem powolnego generowania raportów. Znalazł popularną darmową bibliotekę analityczną i polecił zespołowi natychmiastowe wdrożenie jej do systemu zarządzania magazynem.

Zespół pobrał kod i zintegrował go w ciągu dwóch dni. Aplikacja przyspieszyła. Wszystko wydawało się idealne, aż do momentu rutynowego audytu kodu przeprowadzanego przez zewnętrzną firmę przed drugą rundą finansowania inwestorskiego.

Audytorzy zauważyli, że zintegrowana biblioteka posiadała licencję GPL, a startup wkompilował ją bezpośrednio do swojego rdzenia. To oznaczało, że cały ich autorski algorytm wyceny musiałby zostać upubliczniony. Michał był załamany - ignorowanie dokumentacji okazało się fatalne w skutkach.

Zespół musiał wstrzymać prace nad nowymi funkcjami na 4 tygodnie, usuwając wirusowy komponent i budując własne rozwiązanie zastępcze. Startup spalił 40 tysięcy złotych na same poprawki, ale Michał nauczył się, że dokładne sprawdzanie zasad to fundament profesjonalnego inżynieringu.