Wprowadzenie do licencji typu open source

  • 9 min

Licencje typu open source to umowy prawne, które definiują, jak można używać, modyfikować i dystrybuować oprogramowanie typu open source. Każdy projekt typu open source zawiera licencję, która określa prawa przyznane użytkownikom i wszelkie zobowiązania, które muszą spełnić. Zrozumienie licencji jest niezbędne do legalnej i bezpiecznej implementacji oprogramowania open source w kontekstach organizacyjnych.

Jakie licencje typu open source definiują

Licencja typu open source to dokument prawny, który towarzyszy kodowi źródłowemu i określa:

Przyznane uprawnienia

Licencje jawnie przyznają użytkownikom pewne prawa:

  • Prawa użytkowania: Uprawnienie do korzystania z oprogramowania w dowolnym celu, w tym aplikacji komercyjnych.
  • Prawa modyfikacji: Uprawnienie do modyfikowania kodu źródłowego zgodnie z określonymi potrzebami, naprawiania usterek lub dodawania funkcji.
  • Prawa dystrybucji: Uprawnienie do udostępniania oprogramowania innym osobom w postaci oryginalnej lub zmodyfikowanej.
  • Prawa do podlicencjonowania: W niektórych przypadkach uprawnienie do licencjonowania oprogramowania innym osobom na podstawie różnych warunków.

Bez wyraźnej licencji prawo autorskie zabrania używania, modyfikowania lub rozpowszechniania oprogramowania. Licencja zapewnia uprawnienia prawne dla tych działań.

Zobowiązania nałożone

Licencje zwykle nakładają wymagania na użytkowników:

  • Wymagania dotyczące autorstwa: Musi zachować informacje o prawach autorskich i tekst licencji w rozproszonych kopiach.
  • Ujawnienie kodu źródłowego: Niektóre licencje wymagają podania kodu źródłowego podczas dystrybucji plików binarnych.
  • Zachowywanie licencji: Musi zawierać tekst licencji z rozproszonymi kopiami.
  • Licencjonowanie prac pochodnych: Niektóre licencje wymagają użycia tej samej licencji (copyleft).
  • Granty patentowe: Niektóre licencje obejmują jawne dotacje patentowe lub klauzule zakończenia defensywnego.

Odpowiedzialność i zastrzeżenia do gwarancji

Prawie wszystkie licencje typu open source nie mają odpowiedzialności i gwarancji:

  • Brak gwarancji: Oprogramowanie jest dostarczane "tak, jak to jest" bez gwarancji możliwości handlowych, przydatności do celów lub nienależących do naruszenia.
  • Brak odpowiedzialności: Autorzy i posiadacze praw autorskich nie ponoszą odpowiedzialności za szkody wynikające z użytkowania oprogramowania.
  • Ryzyko związane z użytkownikiem: Użytkownicy akceptują wszystkie zagrożenia związane z używaniem oprogramowania.

Te zastrzeżenia chronią deweloperów open source przed odpowiedzialnością prawną, uznając, że oprogramowanie jest zwykle udostępniane bezpłatnie bez odszkodowania.

Definicja typu open source

Inicjatywa Open Source (OSI) utrzymuje autorytatywną Definicję Open Source, która określa kryteria, aby licencje mogły być uznane za prawdziwie open source:

Podstawowe wymagania

Zgodnie z definicją typu open source licencje typu open source muszą:

Bezpłatna redystrybucja:

  • Brak ograniczeń: Licencje nie mogą ograniczać nikogo przed sprzedażą ani rozdawaniem oprogramowania w ramach dystrybucji zagregowanej.
  • Brak opłat licencyjnych: Licencje nie mogą wymagać opłat ani opłat za taką sprzedaż.

Dołączanie kodu źródłowego:

  • Dostępność: Programy rozproszone muszą zawierać kod źródłowy lub zapewnić jasne instrukcje dotyczące uzyskiwania go bez ponoszenia kosztów.
  • Preferowany formularz: Kod źródłowy musi być w formie preferowanej dla modyfikacji.
  • Brak zaciemnienia: Celowo zaciemniony kod źródłowy nie spełnia wymagań.

Prace pochodne:

  • Dozwolone modyfikacje: Licencje muszą zezwalać na modyfikacje i prace pochodne.
  • Te same terminy: Licencje muszą zezwalać na dystrybucję modyfikacji zgodnie z tymi samymi warunkami co oryginalne oprogramowanie.

Integralność kodu źródłowego autora:

  • Pliki poprawek: Licencje mogą wymagać rozpowszechniania modyfikacji jako plików poprawek wraz z oryginalnym źródłem.
  • Nazewnictwo: Licencje mogą wymagać, aby pochodne prace używały różnych nazw lub numerów wersji niż oryginał.

Brak dyskryminacji osób lub grup:

  • Dostęp uniwersalny: Licencje nie mogą dyskryminować żadnej osoby lub grupy osób.
  • Równe prawa: Każdy musi mieć te same prawa do korzystania z oprogramowania.

Brak dyskryminacji dziedzin wysiłku:

  • Dowolny cel: Licencje nie mogą ograniczać użycia oprogramowania w określonych dziedzinach, takich jak badania biznesowe lub genetyczne.
  • Użycie komercyjne: Licencje nie mogą uniemożliwiać korzystania z oprogramowania w aplikacjach komercyjnych.

Dystrybucja licencji:

  • Aplikacja automatyczna: Prawa dołączone do programu muszą mieć zastosowanie do wszystkich osób, do których program jest redystrybuowany.
  • Brak dodatkowych licencji: Użytkownicy nie powinni wykonywać dodatkowych licencji w celu otrzymania tych praw.

Licencja nie może być specyficzna dla produktu:

  • Prawa autonomiczne: Prawa nie mogą zależeć od programu będącego częścią określonej dystrybucji oprogramowania.
  • Niezależne wykonanie: W przypadku wyodrębnienia z oryginalnej dystrybucji oprogramowanie musi mieć te same prawa.

Licencja nie może ograniczać innego oprogramowania:

  • Brak skażenia: Licencje nie mogą nakładać ograniczeń na inne oprogramowanie dystrybuowane razem z licencjonowanym oprogramowaniem.
  • Dozwolone agregacje: Licencje nie mogą uniemożliwić rozpowszechniania oprogramowania wraz z oprogramowaniem na podstawie różnych licencji.

Licencja musi być neutralna pod względem technologii:

  • Brak ograniczeń interfejsu: Licencje nie mogą wymagać określonych technologii ani stylów interfejsu.
  • Niezależne od metody wykonywania: Licencje nie powinny dbać o to, czy oprogramowanie jest wykonywane za pomocą ikon, wierszy poleceń czy interfejsów internetowych.

Dlaczego te wymagania mają znaczenie

Definicja open source gwarantuje, że licencje zapewniają znaczącą swobodę:

Chroni wolność użytkownika: Wymagania uniemożliwiają nakładanie ukrytych ograniczeń przez licencje, które mogłyby podważyć zasady open source.

Umożliwia użycie komercyjne: Zakazując dyskryminacji z dziedzin przedsięwzięcia, definicja zapewnia przedsiębiorstwom możliwość tworzenia produktów przy użyciu oprogramowania open source.

Zwiększa zgodność: Wymagania ograniczające wpływ licencji na inne oprogramowanie zmniejszają problemy ze zgodnością.

Zapobiega fragmentacji: Wymagając rozsądnych terminów, definicja uniemożliwia rozprzestrzenianie niezgodnych quasi-otwartych licencji.

Kategorie licencji typu open source

Chociaż istnieje wiele różnych licencji typu open source, zazwyczaj należą one do dwóch szerokich kategorii:

Licencje otwarte

Licencje permissywne nakładają minimalne wymagania dotyczące prac pochodnych:

  • Charakterystyka: Zezwala na dołączanie kodu do oprogramowania własnościowego bez konieczności otwarcia jego źródła.
  • Wymagania: Zazwyczaj wymaga tylko autorstwa (zachowanie powiadomień o prawach autorskich i tekstu licencji).
  • Użycie komercyjne: W pełni zgodne z tworzeniem oprogramowania komercyjnego.
  • Przykłady: Licencja MIT, licencja apache 2.0, licencje BSD.

Licencje permissywne maksymalizują swobodę dla użytkowników, umożliwiając im tworzenie produktów komercyjnych typu zamkniętych zawierających kod open source.

Licencje copyleft

Licencje copyleft wymagają, aby narzędzia pochodne korzystały z tej samej licencji:

  • Charakterystyka: Upewnij się, że zmodyfikowane wersje i prace pochodne pozostają typu open source.
  • Wymagania: Wymagaj dystrybucji kodu źródłowego i używania tej samej licencji dla prac pochodnych.
  • Użycie komercyjne: Może być używany w oprogramowaniu komercyjnym, ale prace pochodne muszą być open source.
  • Przykłady: Gnu General Public License (GPL), GNU Lesser General Public License (LGPL), Mozilla Public License (MPL).

Licencje copyleft ustalają priorytety swobody oprogramowania w zakresie swobody użytkownika, zapewniając, że oprogramowanie typu open source pozostaje oprogramowaniem typu open source nawet w miarę rozwoju.

Słabe copyleft

Niektóre licencje zajmują środek:

  • Dozwolone użycie biblioteki: Zezwalaj na łączenie z bibliotekami w zastrzeżonych aplikacjach bez otwierania źródła aplikacji.
  • Ograniczenia modyfikacji: Modyfikacje samej biblioteki muszą być typu open source.
  • Przykłady: GNU LGPL, Licencja publiczna Mozilla.

Słaba licencja copyleft łączy promowanie rozwoju open-source z możliwością komercyjnego użycia.

Wybór licencji według projektów

Projekty typu open source wybierają licencje na podstawie ich celów:

Maksymalizowanie wdrożenia: Projekty ustalające priorytety powszechnego wdrażania zwykle wybierają licencje permisywne, które nie nakładają znaczących zobowiązań dla użytkowników.

Zapewnienie swobody: Projekty ustalające priorytety swobody oprogramowania wybierają licencje copyleft, które zapewniają, że prace pochodne pozostaną oprogramowaniem typu open source.

Zapobieganie zastrzeżonym rozwidleniu: Licencje copyleft uniemożliwiają firmom tworzenie zastrzeżonych wersji oprogramowania typu open source.

Ochrona patentowa: Projekty zainteresowane patentami wybierają licencje z wyraźnymi grantami patentowymi (takimi jak Apache 2.0), które zapewniają jaśniejsze prawa patentowe.

Zgodność: Projekty mogą wybierać licencje zgodne z innym oprogramowaniem, od którego zależą lub z którymi chcą się zintegrować.

Wiele licencji

Niektóre projekty używają wielu strategii licencjonowania:

Podwójne licencjonowanie: Oferowanie oprogramowania zarówno w ramach licencji typu open source, jak i komercyjnych, dzięki czemu użytkownicy mogą wybrać, które warunki mają zastosowanie.

Tworzenie stosu licencji: Różne składniki projektu mogą mieć różne licencje.

Ewolucja licencji: Projekty czasami zmieniają licencje w czasie, chociaż wymaga to umowy od wszystkich współautorów.

Paradoks przejrzystości

Przejrzystość kodu źródłowego tworzy zarówno korzyści zabezpieczeń, jak i zagrożenia:

Korzyści z bezpieczeństwa przejrzystości

Publiczny kod źródłowy umożliwia ulepszenia zabezpieczeń:

  • Wiele oczu: Tysiące deweloperów może przejrzeć kod pod kątem luk w zabezpieczeniach, zwiększając prawdopodobieństwo odnajdywania.
  • Szybsze ujawnienie: Po znalezieniu luk w zabezpieczeniach można je ujawnić i zastosować poprawki publicznie, informując wszystkich użytkowników.
  • Poprawki społeczności: Deweloperzy świadomi zabezpieczeń współtworzyją poprawki w celu naprawienia luk w zabezpieczeniach.
  • Możliwość inspekcji: Organizacje mogą przeprowadzać inspekcję zależności typu open source pod kątem problemów z zabezpieczeniami, co jest niemożliwe w przypadku oprogramowania zamkniętego źródła.

Zagrożenia bezpieczeństwa związane z przejrzystością

Publiczny kod źródłowy pomaga również osobom atakującym:

  • Odnajdywanie luk w zabezpieczeniach: Złośliwi aktorzy mogą analizować kod źródłowy, aby znaleźć luki w zabezpieczeniach, które można wykorzystać.
  • Programowanie wykorzystujące luki w zabezpieczeniach: Zrozumienie szczegółów implementacji ułatwia atakującym opracowywanie luk w zabezpieczeniach.
  • Identyfikacja docelowa: Osoby atakujące mogą zidentyfikować, które aplikacje używają podatnych na zagrożenia wersji składników typu open source.
  • Wykorzystanie zero-dniowe: Osoby atakujące mogą wykrywać luki w zabezpieczeniach i wykorzystywać je, zanim zostaną publicznie ujawnione.

Saldo

Badania sugerują, że przejrzystość zapewnia korzyści z bezpieczeństwa netto:

Prawo Linusa: "Przy wystarczającej liczbie osób wszystkie błędy są płytkie." Otwarty przegląd zwykle szybciej znajduje i naprawia luki w zabezpieczeniach niż rozwój oprogramowania zamkniętego.

Utajnienie nie jest zabezpieczeniem: Utrzymywanie kodu źródłowego w tajemnicy nie zapobiega lukom w zabezpieczeniach — ukrywa je tylko do momentu, w którym zostaną odkryte przez atakujących.

Odpowiedzialne ujawnienie: Społeczność open source opracowała praktyki odpowiedzialnego ujawniania informacji, które równoważą bezpieczeństwo z przejrzystością.

Rzeczywistość praktyczna: Najcięższe naruszenia zabezpieczeń obejmują oprogramowanie typu zamkniętego lub błędną konfigurację, a nie luki w zabezpieczeniach typu open source, co sugeruje, że przejrzystość nie zmniejsza z natury zabezpieczeń.

Zrozumienie licencji typu open source i ich kategorii stanowi podstawę do oceny określonych licencji. W następnej lekcji szczegółowo omówiono typowe licencje typu open source, pomagając zrozumieć, jakie terminy nakładają popularne licencje i jak się różnią.