Korzystanie z bibliotek open source w komercyjnym produkcie to dziś standard — trudno dziś napisać cokolwiek od zera. Problem w tym, że nie każda licencja open source pozwala na to samo, a różnice między nimi potrafią zaskoczyć zarówno prawnika, jak i developera.

Nie każdy „open source” znaczy to samo

„Open source” to szeroka kategoria obejmująca dziesiątki różnych licencji o zupełnie różnych skutkach prawnych. Kluczowy podział to licencje permisywne (np. MIT, Apache 2.0, BSD) i licencje typu copyleft (np. GPL, AGPL) — i to właśnie ten drugi typ najczęściej zaskakuje firmy komercyjne.

Licencje permisywne — bezpieczne dla produktu komercyjnego

Licencje takie jak MIT czy Apache 2.0 pozwalają na dowolne wykorzystanie kodu, w tym w produktach zamkniętych i komercyjnych, zwykle pod warunkiem zachowania informacji o autorstwie i treści licencji. To najbezpieczniejsza kategoria dla firm, które nie chcą ujawniać własnego kodu.

Licencje copyleft — pułapka dla zamkniętego produktu

Licencja GPL (a zwłaszcza jej wersja AGPL, stosowana często w narzędziach serwerowych) może wymagać, żeby cały produkt, który zawiera lub łączy się z takim kodem, również został udostępniony na tej samej licencji — czyli, w uproszczeniu, żeby firma ujawniła własny kod źródłowy. To dokładnie odwrotność tego, czego chce większość firm budujących produkt komercyjny.

Zakres tego obowiązku zależy od tego, jak dokładnie kod jest wykorzystywany (np. czy jest linkowany statycznie, dynamicznie, czy uruchamiany jako osobny proces) — to jeden z najbardziej technicznych aspektów prawa autorskiego, gdzie decyzja architektoniczna developera ma bezpośrednie skutki prawne.

Dlaczego to wymaga współpracy prawnika z developerem

Sama lista bibliotek użytych w projekcie niewiele powie prawnikowi bez kontekstu, jak dokładnie są wykorzystywane. Z drugiej strony, developerzy rzadko mają pełną świadomość, że wybór konkretnej biblioteki może pociągać za sobą obowiązek ujawnienia kodu całego produktu. To obszar, w którym rozmowa prawnika bezpośrednio z zespołem technicznym — bez pośredników i bez tłumaczenia pojęć od podstaw — realnie skraca czas potrzebny na bezpieczną ocenę ryzyka.

Co warto zrobić zanim licencja stanie się problemem

  • sporządzić i na bieżąco aktualizować listę wykorzystywanych bibliotek open source wraz z ich licencjami (tzw. SBOM — Software Bill of Materials),
  • przed wdrożeniem nowej, nieznanej biblioteki — sprawdzić jej licencję, a nie tylko funkcjonalność,
  • ustalić wewnętrzną politykę dopuszczalnych licencji, żeby developerzy nie musieli za każdym razem pytać prawnika o zgodę.