Licencje open source w firmie – ryzyka prawne i compliance

Open source jest dziś fundamentem niemal każdego oprogramowania – od strony internetowej, przez system CRM, po aplikację, którą sprzedajesz klientom. Jest darmowy, szybki i elastyczny, więc łatwo potraktować go jak gotowy element, za który nic się nie płaci i o nic nie trzeba się martwić. I tu zaczyna się problem: darmowy nie znaczy bez warunków. Każdy komponent open source działa na licencji – a niektóre z nich potrafią zobowiązać cię do ujawnienia własnego kodu, zablokować sprzedaż produktu albo zablokować transakcję sprzedaży firmy. Najczęściej wychodzi to na jaw w najgorszym możliwym momencie: podczas audytu zamówionego przez dużego klienta albo badania due diligence przed inwestycją.

W dalszej części artykułu wyjaśniamy, w jakich sytuacjach open source staje się źródłem ryzyka, których licencji należy unikać oraz jak wdrożyć podstawowe zasady compliance bez ponoszenia znaczących nakładów.

Czym jest licencja open source i czym nie jest?

Zacznijmy od najważniejszego nieporozumienia. Open source to nie jest oprogramowanie bez właściciela. To cudzy utwór chroniony prawem autorskim, który autor udostępnił na licencji – czyli zgodzie na korzystanie pod określonymi warunkami. Warunki te bywają łagodne, jak w przypadku wymogu zachowania informacji o autorze, albo bardzo poważne w skutkach jak np. obowiązek udostępnienia własnego kodu stworzonego przy wykorzystaniu oprogramowania open source. To, że nie płacisz za komponent, nie zwalnia cię z obowiązku przestrzegania jego licencji.

Warto odróżnić open source od kilku podobnych kategorii, które często są ze sobą mylone

• Freeware – oprogramowanie darmowe, ale na zasadach ustalonych jednostronnie przez producenta. Zwykle nie daje prawa do modyfikacji ani dalszej dystrybucji kodu. Darmowe w użyciu nie znaczy otwarte.
• Wersja trial – czasowo ograniczona licencja komercyjna. Po okresie testowym trzeba ją kupić albo przestać używać oprogramowania. Dalsze korzystanie po terminie to naruszenie licencji.
• Kod z GitHuba bez wskazanej licencji – to pułapka, która wygląda niewinnie. Publiczna dostępność kodu nie oznacza, że wolno go użyć. Bez licencji obowiązuje pełna ochrona prawnoautorska, czyli w praktyce brak prawa do użycia, modyfikacji i dystrybucji. Brak licencji to nie wolność – to zakaz.

Kiedy open source staje się realnym ryzykiem? Trzy scenariusze

Obowiązki wynikające z licencji open source nie zależą tylko od tego, jakiej biblioteki użyłeś, ale przede wszystkim od tego, jak jej używasz. Ten sam komponent może być całkowicie bezpieczny w jednym scenariuszu i groźny w innym. Dla przedsiębiorcy liczą się trzy sytuacje:

1. Używasz oprogramowania tylko wewnątrz firmy

Serwery, narzędzia księgowe, wewnętrzne systemy – nic nie wychodzi na zewnątrz. To najniższy poziom ryzyka prawnego. Większość licencji nie nakłada tu dodatkowych obowiązków, bo nie dochodzi do dystrybucji. Uwaga jednak na wyjątki oraz na ryzyka niezwiązane z licencją – podatności i brak wsparcia.

2. Dystrybuujesz produkt klientom 

Sprzedajesz aplikację, urządzenie z wbudowanym oprogramowaniem albo instalujesz system u klienta. To właśnie moment, w którym włączają się najostrzejsze obowiązki licencji typu copyleft. Użycie jednej biblioteki na złej licencji może zobowiązać cię do ujawnienia kodu źródłowego własnego produktu.

3. Udostępniasz oprogramowanie jako usługę

Klient nie dostaje kopii programu, tylko korzysta z niego przez internet. Kiedyś uznawano, że to omija obowiązki copyleft – i dlatego powstała licencja AGPL, która świadomie tę lukę zamyka. Jeśli w backendzie usługi SaaS znajdzie się komponent na AGPL, może powstać obowiązek udostępnienia kodu użytkownikom – mimo że formalnie niczego im nie wysyłasz.

Zanim więc ocenisz ryzyko konkretnej licencji, odpowiedz na jedno pytanie: w którym z tych trzech scenariuszy działasz?

Rodziny licencji – ściąga dla przedsiębiorcy

W obiegu jest kilkadziesiąt licencji open source, ale nie musisz ich znać na pamięć. Wystarczy rozpoznać kilka ich głównych rodzin i wiedzieć, co każda z nich oznacza w praktyce.

Rodzina licencji	Przykłady	Co wolno?	Na co uważać?	Ryzyko
Permisywne	MIT, BSD, Apache 2.0	Używać, modyfikować i dystrybuować także w produktach komercyjnych o zamkniętym kodzie	Zachować informację o autorach i treść licencji	Niskie
Copyleft ograniczony	LGPL	Korzystać z biblioteki bez obejmowania całej aplikacji licencją open source	Trzeba spełnić warunki np. możliwość podmiany biblioteki przez użytkownika	Średnie
Copyleft pełny	GPL	Korzystać i modyfikować kod	Przy dystrybucji produktu może powstać obowiązek udostępnienia kodu źródłowego całości	Wysokie
Copyleft dla usług	AGPL	Korzystać i modyfikować kod	Obowiązek udostępnienia kodu może dotyczyć także SaaS, nie tylko klasycznej dystrybucji	Wysokie
Brak licencji i niejasne źródło	kod z GitHuba bez licencji	Nic – dopóki nie ustalisz warunków	Domyślnie pełna ochrona prawnoautorska = brak prawa do użycia	Krytyczne

W skrócie: licencje permisywne to zielone światło – można je stosować niemal wszędzie, pod warunkiem zachowania informacji o autorach. Apache 2.0 jest tu szczególnie ceniona przez firmy, bo zawiera dodatkowe klauzule ograniczające ryzyko sporów patentowych. Licencje copyleft nie są zakazane, ale wymagają przestrzegania zasad co do tego, gdzie i jak wolno ich używać – zwłaszcza gdy dystrybuujesz produkt lub prowadzisz usługę SaaS.

Największe ryzyka prawne w praktyce

Kiedy już wiesz, jakie scenariusze mogą mieć miejsce w praktyce oraz jakie wyróżniamy rodziny licencji, łatwiej zrozumieć, co konkretnie może pójść nie tak.

Przymusowe otwarcie własnego kodu

To największe ryzyko licencji typu copyleft. Jeśli połączysz kod na licencji GPL z własnym w sposób tworzący jedno dzieło i zaczniesz go dystrybuować, całość może zostać objęta obowiązkiem udostępnienia kodu źródłowego. Dla firmy, która sprzedaje zamknięte oprogramowanie, to uderzenie w istotę jej modelu biznesowego.

Naruszenie praw autorskich

Użycie kodu bez licencji albo niedopełnienie jej warunków (np. usunięcie informacji o autorze) to naruszenie praw autorskich twórcy oprogramowania open source. Konsekwencją mogą być roszczenia odszkodowawcze, żądanie zaprzestania korzystania, a w skrajnym przypadku – wycofanie produktu z rynku.

Problem przy sprzedaży firmy lub pozyskaniu inwestora

W procesie due diligence inwestor lub nabywca często żąda pełnej listy użytych komponentów open source wraz z licencjami. Brak takiej listy albo znalezienie w produkcie biblioteki na ryzykownej licencji bywa czerwoną flagą, która obniża wycenę, opóźnia transakcję albo wymusza kosztowne przepisanie fragmentów systemu przed jej zamknięciem.

Bezpieczeństwo i łańcuch dostaw

To ryzyko nie wynika wprost z licencji, ale idzie w parze z open source. Nieaktualne biblioteki z lukami bezpieczeństwa to realne zagrożenie – zwłaszcza jeśli nie wiesz nawet, jakich komponentów używa twój produkt. Nie da się załatać czegoś, o czego istnieniu się nie wie.

Compliance open source bez rozbudowanego działu

Compliance kojarzy się z korporacyjnymi procedurami i etatem specjalisty. W małej i średniej firmie nie o to chodzi. Wystarczy kilka prostych nawyków, które w razie audytu, kontroli klienta czy sprzedaży firmy oszczędzą ogromnych kosztów. Oto realne minimum:

• Prowadź wykaz komponentów i ich licencji

Prosta lista: jaka biblioteka, w jakiej wersji, na jakiej licencji, w którym produkcie. To fundament – bez niej nie wiesz, czym w ogóle zarządzasz. Istnieją narzędzia, które generują taki wykaz automatycznie.

• Ustal zasadę zatwierdzania nowych bibliotek

Zanim programista doda komponent do produktu komercyjnego, ktoś powinien sprawdzić jego licencję. Nie musi to być skomplikowany proces – często wystarczy krótka lista licencji dozwolonych automatycznie i licencji wymagających konsultacji.

• Zabezpiecz się w umowach z dostawcami IT

Jeśli oprogramowanie pisze dla ciebie zewnętrzna firma, to w umowie powinny znaleźć się odpowiednie klauzule zabezpieczające ryzyka, o których mowa w artykule.

• Wyznacz osobę odpowiedzialną

Nie chodzi o nowe stanowisko, tylko o jasność: kto pilnuje wykazu i podejmuje decyzje w razie wątpliwości. Rozproszona odpowiedzialność to brak odpowiedzialności.

Taki zestaw da się wdrożyć w kilka dni i skaluje się razem z firmą. Kluczowa zmiana to zmiana  mentalna: zarządzanie ryzykami związanymi ze stosowaniem oprogramowania open source to proces firmowy, a nie suma pojedynczych decyzji programistów.

Open source w umowie z dostawcą IT

Wielu przedsiębiorców nie pisze kodu samodzielnie – zleca to software house’owi lub freelancerowi. To wygodne, ale rodzi konkretne pytanie: kto odpowiada, jeśli w dostarczonym oprogramowaniu znajdzie się komponent na złej licencji? Odpowiedź w dużej mierze zależy od tego, co ustaliliście na piśmie. Dobra umowa z dostawcą IT powinna zawierać co najmniej:

1. Oświadczenie o użytych komponentach open source. Dostawca deklaruje, jakich bibliotek open source użył i na jakich licencjach – najlepiej z obowiązkiem dostarczenia aktualnego wykazu.
2. Gwarancję braku wad prawnych. Zapewnienie, że dostarczone oprogramowanie nie narusza praw osób trzecich, w tym warunków licencji open source, i że możesz z niego korzystać w zamierzony sposób np. dystrybuować klientom.
3. Zasady odpowiedzialności za naruszenia. Ustalenie, kto ponosi konsekwencje, jeśli okaże się, że użyto komponentu naruszającego prawa autorskie lub wymuszającego ujawnienie kodu – łącznie z pokryciem kosztów ewentualnego przepisania oprogramowania.
4. Zgodność z twoim modelem biznesowym. Jeśli sprzedajesz zamknięty produkt lub oprogramowanie typu SaaS, umowa powinna wprost wykluczać komponenty open source, które są z tym modelem niezgodne.

Te zapisy nie są formalnością – przy pierwszym poważnym audycie klienta lub próbie sprzedaży firmy decydują o tym, czy problem rozwiąże dostawca, czy zapłacisz za niego ty.

FAQ – najczęściej zadawane pytania

Czy skoro open source jest darmowy, można go po prostu używać w firmie?

Nie w każdym przypadku. Darmowość dotyczy opłat, a nie warunków korzystania. Każda licencja open source nakłada obowiązki – od minimalnych po poważne. Bezpieczne używanie zaczyna się od wiedzy, jakiej licencji się używa i w jakim scenariuszu.

Czy używanie open source tylko wewnątrz firmy też rodzi ryzyko prawne?

Ryzyko licencyjne jest wtedy najniższe, bo zwykle nie dochodzi do dystrybucji. Nie znika jednak całkowicie – wyjątkiem bywa licencja AGPL, a niezależnie od licencji pozostaje ryzyko bezpieczeństwa. Warto też prowadzić wykaz komponentów, bo firma może z czasem zacząć dystrybuować produkt, a wtedy ryzyka prawne związane z korzystaniem z oprogramowania open source aktualizują się.

Czym grozi użycie licencji GPL w produkcie komercyjnym?

Jeśli kod na GPL połączysz z własnym w jedno dzieło i będziesz dystrybuować produkt, może powstać obowiązek udostępnienia całego kodu źródłowego – w tym potencjalnie twojego. Dla firmy sprzedającej zamknięte oprogramowanie to poważne ryzyko. GPL nie jest zakazana, ale wymaga świadomej decyzji o tym, gdzie i jak jej używać.

Czy kod z GitHuba bez licencji jest wolny do użycia?

Nie. Publiczna dostępność kodu nie oznacza zgody na jego użycie. Bez wskazanej licencji obowiązuje pełna ochrona prawnoautorska, czyli domyślnie nie masz prawa go używać, modyfikować ani dystrybuować. Aby legalnie skorzystać z takiego kodu, potrzebujesz zgody autora lub jasnej licencji.

Dlaczego inwestor albo duży klient żąda listy komponentów open source?

Bo chce ocenić ryzyko prawne, które przejmuje razem z firmą lub produktem. Lista komponentów pokazuje, jakich licencji użyto i czy nie ma wśród nich takich, które wymuszają ujawnienie kodu albo naruszają cudze prawa. Brak takiej listy sam w sobie bywa sygnałem ostrzegawczym.

Kto odpowiada za naruszenie licencji – moja firma czy software house, który pisał kod?

Zależy to przede wszystkim od treści umowy, jaką zawarłeś z software house’m. Jeśli nie uregulowaliście omówionych w artykule kwestii na piśmie, ryzyko w dużej mierze spoczywa na tobie jako na podmiocie korzystającym z oprogramowania i dystrybuującym je dalej. Dlatego kluczowe są oświadczenia dostawcy o użytych komponentach, gwarancja braku wad prawnych i jasne zasady odpowiedzialności.

Podsumowanie

Open source to realna oszczędność i przewaga – ale tylko wtedy, gdy jest świadomie wykorzystywany. W praktyce najkosztowniejsze okazują się nie licencje, lecz drobiazgi, których nikt nie przemyślał lub nie skonsultował na etapie wdrażania projektu: jedna biblioteka na złej licencji, brak wykazu komponentów, niedopracowana umowa z dostawcą. Wystarczy kilka prostych nawyków – wiedza, w którym scenariuszu działasz, rozpoznanie rodziny licencji, podstawowy wykaz komponentów open source i dobre klauzule umowne – aby zamienić open source z ukrytego ryzyka w bezpieczne narzędzie.