Eksplorowanie typowych licencji typu open source

  • 8 min

Istnieją setki licencji typu open source, ale większość oprogramowania typu open source używa stosunkowo małej liczby popularnych licencji. Zrozumienie tych typowych licencji, ich warunków i ich implikacji ułatwia organizacjom podejmowanie świadomych decyzji dotyczących składników typu open source, które mogą bezpiecznie włączyć do swojego oprogramowania.

Spektrum licencji

Licencje typu open source istnieją w spektrum od wysoce permisywnego do silnie copyleft:

Zrzut ekranu przedstawiający spektrum licencji.

Licencje zezwalające (uznanie autorstwa)

Po lewej stronie spektrum są licencje permissywne, które nakładają minimalne ograniczenia:

  • Charakterystyka: Zezwalaj na używanie kodu w oprogramowaniu zastrzeżonym bez konieczności używania zastrzeżonego oprogramowania jako oprogramowania typu open source.
  • Podstawowe wymaganie: Uznanie autorstwa — zachowywanie powiadomień o prawach autorskich i tekstu licencji.
  • Użycie komercyjne: W pełni zgodne z tworzeniem i sprzedażą własnościowego oprogramowania komercyjnego.
  • Swoboda dalszego rozpowszechniania: Użytkownicy mogą zdecydować, czy uczynić dzieła pochodne otwartoźródłowymi.

Przykłady: Licencja MIT, licencja apache 2.0, licencje BSD.

Licencje copyleft

Po prawej stronie spektrum znajdują się licencje copyleft z silnymi wymaganiami dotyczącymi wzajemności:

  • Charakterystyka: Prace pochodne i połączone muszą korzystać z tej samej licencji.
  • Wirusowa natura: Licencja "rozszerza się" na oprogramowanie, które zawiera lub jest łączone z licencjonowanym kodem.
  • Wymaganie kodu źródłowego: Dystrybucja plików binarnych wymaga udostępnienia kodu źródłowego.
  • Zachowanie wolności: Upewnij się, że oprogramowanie pozostaje oprogramowaniem open source w miarę rozwoju i jest włączone do innych projektów.

Przykłady: Licencja publiczna GNU (GPL v2 i v3), GNU Affero General Public License (AGPL).

Słabe licencje copyleft

W środku spektrum są słabe licencje copyleft, które równoważą otwartość z opłacalnością komercyjną:

  • Charakterystyka: Wymagane są modyfikacje licencjonowanego składnika, aby były open source, ale dozwolone jest włączanie składnika do większych zamkniętych prac.
  • Przyjazne dla biblioteki: Przeznaczony dla bibliotek, które mogą być używane w zastrzeżonych aplikacjach.
  • Copyleft na poziomie pliku lub modułu: Wymagania dotyczą elementu objętego licencją, a nie całej aplikacji.
  • Praktyczna równowaga: Włączanie komercyjnego użycia przy jednoczesnym zapewnieniu, że ulepszenia komponentu pozostają otwartoźródłowe.

Przykłady: Gnu Lesser General Public License (LGPL), Mozilla Public License (MPL), Eclipse Public License (EPL).

Typowe licencje zezwalające

Licencja MIT

Licencja MIT jest jedną z najprostszych i najbardziej permisyjnych licencji typu open source:

Kluczowe terminy:

  • Uprawnienia: Używanie, kopiowanie, modyfikowanie, scalanie, publikowanie, rozpowszechnianie, podlicencjonowanie i sprzedawanie oprogramowania.
  • Warunki: Uwzględnij informacje o prawach autorskich i tekst licencji we wszystkich kopiach lub istotnych fragmentach.
  • Ograniczenia: Brak gwarancji, brak odpowiedzialności za szkody.

Dlaczego projekty wybierają MIT:

  • Maksymalne wdrożenie: Minimalne ograniczenia zachęcają do powszechnego stosowania.
  • Proste i jasne: Krótki tekst licencji, który jest łatwy do zrozumienia.
  • Przyjazne komercyjnie: Brak barier w dołączaniu kodu licencjonowanego na licencji MIT w oprogramowaniu własnościowym.
  • Elastyczność: Użytkownicy mają pełną swobodę w sposobie używania i rozpowszechniania oprogramowania.

Popularne projekty licencjonowane na mit: React, Angular, Node.js, jQuery, Rails, .NET Core.

Implikacje dla organizacji:

  • Bezpieczne do użytku komercyjnego: Może dołączać składniki licencjonowane przez mit do oprogramowania własnościowego bez ograniczeń.
  • Wymagane jest przypisanie: Należy zachować uwagi dotyczące praw autorskich — należy zwykle umieścić tekst licencji w dokumentacji aplikacji lub oknach dialogowych Informacje.
  • Brak udzielenia patentu: Licencja MIT nie dotyczy jawnie patentów, co stwarza potencjalną niejednoznaczność.

Licencja apache 2.0

Licencja Apache License 2.0 jest licencją permissywną z jawną ochroną patentową:

Kluczowe terminy:

  • Uprawnienia: Użyj, odtwórz, przygotuj prace pochodne, wyświetl, wykonaj, podlicencjonowanie i dystrybuuj.
  • Warunki: Uwzględnij informacje o prawach autorskich, tekst licencji i informacje o modyfikacjach; zachować uwagi patentowe; zapewnij uznanie autorstwa.
  • Udzielenie patentu: Jawne udzielanie praw patentowych od współautorów.
  • Odwet patentowy: Granty patentowe kończą się, jeśli licencjobiorca inicjuje spór patentowy przeciwko współautorom.
  • Ograniczenia: Bez gwarancji, bez odpowiedzialności, bez praw do znaków towarowych.

Dlaczego projekty wybierają platformę Apache 2.0:

  • Przejrzystość patentu: Jawne dotacje patentowe zapewniają pewność prawną.
  • Przezroczystość modyfikacji: Wymaganie dokumentowania modyfikacji promuje przejrzystość.
  • Pewność korporacji: Jasne warunki i ochrona patentowa sprawiają, że korporacje czują się komfortowo przyczyniając się.
  • Zgodność: Zgodność z GPL v3 (ale nie GPL v2).

Popularne projekty apache 2.0: Kubernetes, TensorFlow, Android, Spring Framework, Apache Hadoop, Apache Kafka.

Implikacje dla organizacji:

  • Ochrona patentowa: Jawne przyznanie patentu zmniejsza ryzyko sporów patentowych ze strony współautorów.
  • Powiadomienie o modyfikacji: Musi wskazywać, kiedy pliki zostały zmodyfikowane.
  • Wymagania dotyczące autorstwa: Nieco bardziej złożone niż MIT, wymagające zachowania plików NOTICE.
  • Zakończenie defensywne: Granty patentowe zakończą się, jeśli pozywasz współautorów za naruszenie patentu, zachęcając do pokojowego współistnienia.

Licencje BSD (2-klauzulowa i 3-klauzulowa)

Licencje BSD (Berkeley Software Distribution) to permisywne licencje podobne do MIT.

BSD 2-Clause (uproszczony BSD):

  • Uprawnienia: Redystrybucja i użycie w formach źródłowych i binarnych z modyfikacją lub bez nich.
  • Warunki: Zachowaj powiadomienie o prawach autorskich, listę warunków i zastrzeżenie; zachowaj przypisanie w dokumentacji dla dystrybucji binarnych.
  • Ograniczenia: Brak gwarancji, brak odpowiedzialności.

BSD 3-Clause (zmodyfikowany BSD):

  • Dodatkowy warunek: Nie można używać nazw posiadaczy praw autorskich do wspierania produktów pochodnych bez zgody.
  • Ochrona znaków towarowych: Uniemożliwia sugerowanie poparcia przez oryginalnych autorów.

Popularne projekty licencjonowane na usługę BSD: FreeBSD, OpenBSD, części systemów macOS i iOS.

Implikacje dla organizacji:

  • Podobnie jak MIT: Minimalne ograniczenia, przyjazne dla rynku.
  • Ograniczenie użycia nazw: 3-Klauzula BSD uniemożliwia używanie nazw projektów do marketingu bez uprawnień.
  • Dobrze ugruntowane: Długa historia w oprogramowaniu akademickim i komercyjnym.

Typowe licencje copyleft

Ogólna licencja publiczna GNU (GPL) v2 i v3

Licencja publiczna GNU jest najbardziej znaną licencją copyleft:

Kluczowe terminy GPL v2:

  • Uprawnienia: Używanie, modyfikowanie i rozpowszechnianie oprogramowania.
  • Warunki: Dystrybuowanie kodu źródłowego za pomocą plików binarnych; prace pochodne muszą korzystać z GPL v2; zachowywanie powiadomień o prawach autorskich.
  • Zakres copyleft: Dotyczy prac pochodnych i połączonych prac, które łączą się z kodem GPL.
  • Ograniczenia: Brak gwarancji, brak odpowiedzialności.

Ulepszenia GPL w wersji 3:

  • Ochrona patentowa: Jawne dotacje patentowe podobne do Apache 2.0.
  • Zapobieganie "tivoizacji": Zapobiega używaniu ograniczeń sprzętowych, aby uniemożliwić użytkownikom uruchamianie zmodyfikowanego oprogramowania.
  • Zgodność międzynarodowa: Ulepszono przejrzystość prawną dla jurysdykcji międzynarodowych.
  • Zgodność z platformą Apache 2.0: Można połączyć kod GPL v3 z kodem Apache 2.0.

Dlaczego projekty wybierają GPL:

  • Zapewnienie swobody: GPL zapewnia, że modyfikacje pozostaną open source, uniemożliwiając własnościowe rozwidlenia.
  • Budowanie społeczności: Zachęca do udostępniania ulepszeń z powrotem społeczności.
  • Wyrównanie filozoficzne: Zgadza się z filozofią wolnego oprogramowania, że oprogramowanie powinno pozostać wolne.

Popularne projekty licencjonowane na bibliotekę GPL: Jądro systemu Linux (GPL v2), Git (GPL v2), WordPress (GPL v2), GCC (GPL v3), Bash (GPL v3).

Implikacje dla organizacji:

  • Wymagania dotyczące pracy pochodnej: Jeśli zmodyfikujesz kod GPL lub utworzysz prace pochodne, podczas dystrybucji należy je open source w ramach biblioteki GPL.
  • Zagadnienia związane z łączeniem: Łączenie zamkniętego kodu źródłowego z bibliotekami GPL może prowadzić do zastosowania wymagań copyleftu (interpretacja różni się).
  • Dystrybucja komercyjna: Może sprzedawać oprogramowanie GPL, ale musi dostarczać kod źródłowy klientom.
  • Zagadnienia dotyczące modelu SaaS: GPL v2 i v3 nie wymagają ujawnienia kodu źródłowego dla oprogramowania jako usługi, chyba że jest używana grupa AGPL.

GNU Affero General Public License (AGPL)

AGPL rozszerza GPL v3 klauzulą dotyczącą użycia sieciowego:

Dodatkowe wymaganie AGPL:

  • Kopyleft sieciowy: Jeśli zmodyfikujesz oprogramowanie AGPL i użytkownicy wchodzą z nim w interakcję za pośrednictwem sieci (SaaS), musisz udostępnić kod źródłowy tym użytkownikom.
  • Zamykanie luki ASP: Uniemożliwia firmom modyfikowanie oprogramowania i oferowanie go jako usługi bez konieczności udostępniania modyfikacji.

Dlaczego projekty wybierają AGPL:

  • Ochrona SaaS: Zapewnia, że usługi w chmurze nie mogą używać oprogramowania typu open source bez wnoszenia wkładu z powrotem do społeczności.
  • Silniejsza copyleft: Maksymalna ochrona przed zastrzeżonym użyciem.

Popularne projekty licencjonowane na AGPL: MongoDB (zmieniono z AGPL), RocketChat, Grafana.

Implikacje dla organizacji:

  • Unikaj aplikacji SaaS: Większość organizacji unika oprogramowania licencjonowanego na platformę AGPL dla ofert usług, ponieważ wymaga modyfikacji typu open source.
  • Użycie wewnętrzne: Można używać wewnętrznie bez wyzwalania wymagań, jeśli nie są widoczne dla użytkowników za pośrednictwem sieci.
  • Ocena ryzyka: Dokładnie oceń, czy oprogramowanie kwalifikuje się jako "działające w sieci".

Typowe licencje copyleft o słabym charakterze

Mniej ogólna licencja publiczna GNU (LGPL)

Biblioteka LGPL umożliwia łączenie z bibliotekami bez wyzwalania pełnych wymagań GPL:

Kluczowe terminy:

  • Użycie biblioteki: Można linkować do bibliotek LGPL z zastrzeżonego oprogramowania bez udostępniania kodu źródłowego aplikacji zastrzeżonej.
  • Modyfikacje biblioteki: Modyfikacje samej biblioteki LGPL muszą być typu open source.
  • Łączenie dynamiczne: LGPL jawnie zezwala na łączenie dynamiczne z zastrzeżonym kodem.
  • Prace pochodne: Kompletne aplikacje nie są uznawane za prace pochodne tylko dlatego, że korzystają z bibliotek LGPL.

Dlaczego projekty wybierają LGPL:

  • Wdrażanie biblioteki: Zachęca do używania w zastrzeżonym oprogramowaniu, jednocześnie chroniąc samą bibliotekę.
  • Pozycja kompromisowa: Równoważy otwartość z rentownością.
  • Standardowa użyteczność biblioteki: Odpowiednie dla bibliotek przeznaczonych jako standardowe składniki.

Popularne projekty licencjonowane na licencję LGPL: Qt (podwójna licencja z opcją komercyjną), GTK, GStreamer, wiele bibliotek C.

Implikacje dla organizacji:

  • Może być używany w aplikacjach zastrzeżonych: Bezpieczne używanie bibliotek LGPL w aplikacjach komercyjnych.
  • Musi podać źródło biblioteki: Jeśli zmodyfikujesz bibliotekę LGPL, podaj kod źródłowy do modyfikacji.
  • Złożoność łączenia statycznego: Łączenie statyczne może wyzwalać bardziej rygorystyczne wymagania; łączenie dynamiczne jest bezpieczniejsze.

Licencja publiczna Mozilla (MPL) 2.0

Platforma MPL 2.0 zapewnia kopiowanie na poziomie plików:

Kluczowe terminy:

  • Copyleft na poziomie pliku: Wymagania dotyczą tylko plików, które były pierwotnie objęte MPL.
  • Większe wykluczenie z pracy: Może łączyć pliki MPL z zastrzeżonymi plikami w tej samej aplikacji.
  • Ujawnienie kodu źródłowego: Musi podać kod źródłowy dla plików MPL.
  • Udzielenie patentu: Obejmuje jawne przyznanie patentu i defensywne zakończenie.
  • Zgodność Z biblioteką GPL: MPL 2.0 jest zgodny z GPL.

Dlaczego projekty wybierają MPL 2.0:

  • Równowaga: Silniejsze niż licencje liberalne, bardziej elastyczne niż GPL.
  • Użycie komercyjne: Umożliwia użycie komercyjne podczas ochrony składnika open source.
  • Śledzenie plików: Kopiowanie na poziomie plików ułatwia śledzenie zgodności.

Popularne projekty licencjonowane na MPL: Firefox, Thunderbird, LibreOffice.

Implikacje dla organizacji:

  • Może mieszać się z zastrzeżonym kodem: Łatwiejsza integracja z zastrzeżonym oprogramowaniem niż GPL.
  • Śledzenie na poziomie pliku: Musi zachować jasne granice między plikami MPL i zastrzeżonymi plikami.
  • Udostępnione modyfikacje: Zmiany w plikach MPL muszą być udostępniane, ale dodatki w oddzielnych plikach nie muszą być udostępniane.

Zgodność licencji

Różne licencje mają różne reguły zgodności:

Zgodne kombinacje

  • MIT + Apache 2.0: Zgodne — może łączyć się w tym samym projekcie.
  • MIT + GPL v3: Zgodne — projekty GPL v3 mogą zawierać kod licencjonowany na MIT.
  • Apache 2.0 + GPL v3: Zgodne — GPL v3 może zawierać kod Apache 2.0.
  • LGPL + GPL: Zgodne — można uaktualnić bibliotekę LGPL do GPL.

Niezgodne kombinacje

  • GPL v2 + Apache 2.0: Niezgodne — nie można połączyć w tej samej pracy.
  • GPL + Zastrzeżone: Niezgodne — GPL wymaga, aby prace pochodne były objęte licencją GPL.
  • Różne licencje copyleft: Ogólnie niezgodne — zwykle nie można połączyć kodu GPL, AGPL i LGPL z różnymi licencjami copyleft w sposób, który spełnia oba te wymagania.

Zagadnienia dotyczące zgodności

Podczas wybierania zależności:

  • Spis licencji: Znajdź licencje dla wszystkich zależności.
  • Sprawdzanie zgodności: Sprawdź, czy licencje różnych składników są zgodne.
  • Przegląd prawny: Złożone przypadki wymagają wiedzy prawnej w celu oceny zgodności.

Strategie podwójnego licencjonowania

Niektóre projekty oferują wiele opcji licencjonowania:

Open source + komercyjna

  • Strategia: Oferta w ramach licencji GPL (copyleft) lub komercyjnej.
  • Uzasadnienie: Firmy, które chcą zintegrować własnościowe oprogramowanie, kupują licencję komercyjną; natomiast społeczność open source korzysta z wersji GPL.
  • Przykłady: Qt, MySQL, MongoDB (zmienione podejście).

Wiele licencji typu open source

  • Strategia: Zezwalaj użytkownikom na wybór spośród wielu zgodnych licencji.
  • Uzasadnienie: Maksymalizuj zgodność z różnymi projektami.
  • Przykłady: Niektóre biblioteki oferują opcje licencjonowania apache 2.0 lub MIT.

Zrozumienie typowych licencji typu open source, ich warunków i zgodności pomaga organizacjom podejmować świadome decyzje dotyczące składników typu open source do użycia i sposobu tworzenia struktury oprogramowania w celu zachowania zgodności licencji. W następnej lekcji przedstawiono implikacje i oceny licencji, które pomagają ocenić ryzyko i podejmować decyzje.