Przewodnik programisty dotyczący licencji Open Source

Nie wszystkie licencje open source są takie same. Niektóre z nich obligują dostawcę oprogramowania do udzielania licencji patentowych użytkownikom i twórcom oprogramowania. Inne licencje zobowiązują programistę korzystającego z licencjonowanego produktu lub biblioteki do zaoferowania kodu źródłowego tego produktu lub biblioteki na tych samych warunkach. Inni po prostu oddają kod, bez jakiejkolwiek gwarancji lub jakichkolwiek obaw. W tym artykule postaram się podkreślić główne różnice między najczęściej używanymi licencjami open-source z perspektywy użytkownika oprogramowania i twórcy oprogramowania.

Kiedy w 1984 roku Richard Stallman rozpoczął projekt GNU mający na celu stworzenie wolnego systemu operacyjnego, odzyskał ideę, że oprogramowanie powinno być dzielone między programistami, inżynierami i użytkownikami; i powinni być w stanie ulepszyć ją we współpracy w taki sam sposób, w jaki zwykle robi się naukę.

Ta opcja kontrastowała ze zwykłą koncepcją licencjonowanego oprogramowania, wybraną przez większość korporacji programistycznych i programistów do dystrybucji i sprzedaży swoich programów. Dzisiaj, ponad trzydzieści lat później, oprogramowanie open source powoli podbija szerokie sektory naszej branży: Linux, Android, Apache i Git są przykładami wiodących produktów open source w swoich kategoriach.

Oprogramowanie Open Source czy Wolne?

W tym artykule będę używać terminów „open source” i „bezpłatny” jako synonimów w odniesieniu do oprogramowania lub licencji. Moim zdaniem oba terminy wyrażają tę samą ideę. „Open-source” wyraża to w praktyczny i techniczny sposób, a użycie „Free” koncentruje się na filozoficznym i politycznym znaczeniu tego pojęcia.

Niestety słowo „free” w języku angielskim, oprócz tego, że jest przymiotnikiem związanym z „freedom”, oznacza również „bez kosztów”. To jest powód, dla którego zwykle wolę mówić „open source”.

Wspólne właściwości oprogramowania typu open source

Przypuszczam, że masz już przybliżone pojęcie o tym, czym jest oprogramowanie typu open source. Ale ponieważ zamierzamy mówić o szczegółach różnych licencji, najpierw musimy porozmawiać o konkretnych właściwościach, które definiują oprogramowanie typu open source.

Po pierwsze: nie jestem prawnikiem i to nie jest porada prawna. W razie wątpliwości prosimy o zapoznanie się z rzeczywistym tekstem licencji, o których mówię, oraz z radcą prawnym.

Całe oprogramowanie typu open source, zgodnie z inicjatywą Open Source, jest rozpowszechniane na podstawie licencji, która daje jego użytkownikom i programistom (licencjobiorcom) pewne prawa. Z pełną listą można zapoznać się w definicji Open Source, ale oto podstawowe podsumowanie:

1. Bezpłatna redystrybucja oprogramowania: oprogramowanie może być sprzedawane lub rozdawane jako produkt lub zawarte w pakiecie oprogramowania. Można to zrobić bez płacenia tantiem.
2. Kod źródłowy licencjonowanego oprogramowania jest albo zawarty w dystrybucji, albo przynajmniej istnieją dobrze nagłośnione sposoby uzyskania kodu źródłowego. Ten kod źródłowy jest przydatny do tworzenia zmodyfikowanych wersji oprogramowania.
3. Tworzenie utworów pochodnych jest dozwolone, a licencja pozwala na ich rozpowszechnianie na tych samych warunkach i licencji, co oryginalne oprogramowanie. W zależności od licencji oryginalnego oprogramowania, w niektórych przypadkach te dzieła pochodne muszą być odróżnione od oryginalnego oprogramowania poprzez zmianę nazwy lub numeru wersji, lub mogą być rozpowszechniane jedynie w formie poprawek kodu źródłowego.
4. Oprogramowanie może być używane przez dowolną osobę lub grupę osób, w dowolnych dziedzinach, bez ograniczeń.

Należy jednak pamiętać, że licencje na oprogramowanie mówią tylko o używaniu lub rozpowszechnianiu zezwoleń udzielonych przez właścicieli praw autorskich. Licencje typu open source mogą umożliwiać swobodne rozpowszechnianie oprogramowania lub dzieł pochodnych, ale ten dodatek może być również ograniczony w niektórych krajach, w których eksportowanie oprogramowania kryptograficznego jest zabronione. W podobny sposób licencje open-source pozwalają na używanie oprogramowania w dowolnym celu, ale to nie znaczy, że pozwalają włamać się do banku za pomocą licencjonowanego oprogramowania open source. Innym tego przykładem są patenty na oprogramowanie: niektóre licencje typu open source dają uprawnienia do swobodnego korzystania z patentów, ale nie wszystkie.

Czy możemy więc wykorzystać oprogramowanie typu open source do rozwoju produktu lub projektu? Zasadniczo zależy to od licencji używanego oprogramowania i planowanej licencji na produkt końcowy. Różne licencje mają również znaczenie, gdy chcesz opublikować własny kod jako open-source i decydujesz, której licencji użyć.

Prawo autorskie

Jedną z całkiem interesujących koncepcji dotyczących licencji open source jest to, co zwykle nazywa się copyleft, co jest przeciwieństwem praw autorskich. Tam, gdzie prawa autorskie są wykorzystywane do ochrony własności intelektualnej (w tym oprogramowania) przed kopiowaniem lub rozpowszechnianiem, stosuje się copyleft, aby zapewnić, że własność intelektualna i oprogramowanie o otwartym kodzie źródłowym mogą być kopiowane lub rozpowszechniane jako open source.

Zgodnie z jego siłą istnieją dwa rodzaje copyleft:

• Silny copyleft: gdy utwory pochodzące z innych utworów objętych licencją typu „mocne prawo autorskie” lub z nimi powiązane, muszą nadal posiadać silne licencje typu „copyleft” lub nawet dokładnie taką samą licencję. Oznacza to, że te dzieła o otwartym kodzie źródłowym nie mogą zostać zamknięte w przyszłości.
• Słaby copyleft: gdy prace wykorzystujące słabe licencjonowane prace typu copyleft lub powiązane z nim, mogą być licencjonowane na podstawie innych licencji, nawet licencji o zamkniętym kodzie źródłowym. W tym przypadku copyleft dotyczy tylko oryginalnego utworu objętego słabą licencją typu copyleft.

Istnieją również licencje open-source bez copyleft: po prostu nie dbają o przyszłą otwartość oprogramowania pochodnego.

Lekkie obyczaje

Ze względu na ich dopuszczalność, licencje można również sklasyfikować w:

• Ścisłe licencje: gdy nie można mieszać silnego licencjonowanego oprogramowania z oprogramowaniem o zamkniętym kodzie źródłowym, a nawet z oprogramowaniem bardziej liberalnym.
• Licencje permisywne: gdy produkty zwykle można mieszać z oprogramowaniem o zamkniętym kodzie źródłowym lub oprogramowaniem z całkowicie licencją typu open source.

Zwykle silne licencje typu copyleft są również surowe, a słabe licencje typu copyleft są bardziej liberalne, ale nie musi tak być.

Różnice w licencjach Open Source

Istnieje wiele licencji open source. Inicjatywa Open Source zatwierdziła już ponad 80 z nich. Niektóre są zbędne i można je uznać za równoważne z innymi. Inne są specyficzne dla interesów wydawcy oprogramowania (np. licencja NASA) lub dla określonego środowiska lub celu (np. Educational Community License lub Open Font License).

To rozpowszechnianie licencji opiera się na określonych warunkach w licencji, które, dodane do podstawowych właściwości open source, zezwalają lub nie zezwalają na inne zastosowania. Przykłady tych dodatkowych warunków mogą obejmować:

• Rodzaj copyleft: słaby, silny lub nieistniejący.
• Rodzaj permisywizmu: permisywny lub surowy.
• Obowiązek dodania informacji o prawach autorskich w kodzie źródłowym lub w interfejsie użytkownika.
• Automatyczne przyznawanie patentów licencjobiorcom.
• Traktowanie jako licencjobiorców nie tylko stron, do których dystrybuowane jest oprogramowanie, ale także użytkowników oprogramowania (tak, aby osoby korzystające z usługi w chmurze korzystającej z tego rodzaju oprogramowania typu open source miały możliwość pobrania kodu źródłowego oprogramowanie)

Problem mieszania kodu z różnymi licencjami

Zgodnie z tym, co już powiedzieliśmy wcześniej, niektóre licencje są permisywne, pozwalając użytkownikom na łączenie kodu z kodem źródłowym na innej licencji (być może z dodatkowymi warunkami). Ten przypadek umożliwiłby mieszanie tego rodzaju licencjonowanego oprogramowania typu open source z oprogramowaniem o zamkniętym kodzie źródłowym. Przykładem tego rodzaju licencji jest licencja MIT.

Inne są bardziej restrykcyjne, więc kod źródłowy można łączyć tylko z kodem licencjonowanym w podobny sposób, a ostateczny wynik musi być objęty tą samą oryginalną licencją. Przykładem tego rodzaju licencji jest General Public License (GPL).

Może chcesz połączyć licencjonowany kod z dwiema różnymi restrykcyjnymi licencjami open-source. Korzystając z wolności open source do korzystania z oprogramowania tak, jak chcesz, możesz to zrobić. Ale ostateczny program nie może być redystrybuowany, ponieważ powinien być rozpowszechniany na dwóch licencjach, które nie są ze sobą kompatybilne.

Jednym z przykładów takiej sytuacji był ZFS. ZFS to bardzo zaawansowany i innowacyjny system plików, który został dołączony do OpenSolarisa w 2005 roku. Jest to oprogramowanie typu open source licencjonowane na warunkach licencji Common Development and Distribution License (CDDL). Chociaż jest to kod typu open source, nie można go zintegrować z jądrem Linuksa, ponieważ kod źródłowy Linuksa jest rozpowszechniany na warunkach Powszechnej Licencji Publicznej, kolejnej restrykcyjnej licencji open source. Pliki binarne jądra Linux skompilowane z obsługą ZFS nie mogą być dystrybuowane z powodu konfliktu licencji.

Tego rodzaju konflikty można rozwiązać tylko wtedy, gdy wszyscy właściciele jednego z programów o otwartym kodzie źródłowym zgodzą się na zmianę licencji lub dodanie wyjątków do licencji oprogramowania. Na przykład: wiele programów na licencji GPL jest powiązanych z biblioteką OpenSSL. Dystrybucja biblioteki OpenSSL jest licencjonowana i wymaga, aby fraza pojawiała się w materiałach reklamowych i wszelkich redystrybucjach. Te dodatkowe warunki nie są zgodne z GPL iz tego powodu twórcy produktów GPL korzystających z OpenSSL umieścili w swojej licencji wyjątek pozwalający na łączenie z OpenSSL.

Cechy różnicowe licencji Open Source

Teraz postaram się przeanalizować najpopularniejsze licencje open-source, zwracając uwagę na ich cechy różnicowe, z małym przewodnikiem na temat tego, kiedy ich używać, a kiedy nie. Posortowałem je od bardziej do mniej używanych, zgodnie z bazą wiedzy Black Duck.

Powszechna Licencja Publiczna GNU (GPL)

GPL jest najpopularniejszą licencją typu open source. Została stworzona przez FSF jako licencja dla projektu GNU, a także jest licencją jądra Linuksa.

Jego cechy różnicujące:

• Silny copyleft.
• Bardzo ścisła licencja.
• Zwykle nazywa się to licencją „wirusową”: jeśli połączysz swój kod z innym fragmentem kodu na licencji GPL i chcesz rozpowszechniać wyniki, cały produkt musi być objęty licencją GPL.
• Jest to również licencja „obejmująca”: jeśli tworzysz oprogramowanie i chcesz je licencjonować na GPL, możesz je połączyć lub dołączyć inne oprogramowanie typu open source, o ile to oprogramowanie ma licencję zgodną z GPL. Nie wymaga żadnych zobowiązań niewymaganych przez GPL.

Zwykle tekst używanej licencji zawiera tekst mówiący, że oprogramowanie jest rozpowszechniane na warunkach licencji GPL w wersji N (lub dowolnej późniejszej wersji).

Obecnie w użyciu są dwie wersje licencji GPL: v2 i v3. Wersja 3 została wydana w 2007 roku w celu rozwiązania niektórych problemów, które pojawiły się od wydania wersji 2 w 1991 roku.

GPL v3 zawiera dodatkowe klauzule i warunki, które odnoszą się do przepisów dotyczących kompatybilności z innymi licencjami open source, zobowiązują do licencjonowania patentów, definiują warunki korzystania z oprogramowania na licencji GPL jako oprogramowania sprzętowego w urządzeniach oraz uwzględniają koncepcje zarządzania prawami cyfrowymi.

Licencja MIT

Licencja typu open source, zwykle znana jako licencja MIT, znana również jako licencja X11, jest bardzo liberalną licencją nie będącą copyleft, która pozwala wszystkim zasadniczo używać licencjonowanego kodu do czegokolwiek, o ile zachowujesz wiadomość o prawach autorskich i wiesz, że oprogramowanie jest dostarczane bez jakiejkolwiek gwarancji.

Ta licencja jest bardzo popularna i jest używana przez kilka projektów, takich jak X Window System, Ruby on Rails, jQuery czy Node.js.

Jest zgodny z GPL, więc możesz mieszać kod na licencji MIT z oprogramowaniem GPL.

Licencja Apache 2.0

Licencja Apache została utworzona przez Apache Software Foundation (ASF) jako licencja na jej serwer Apache HTTP Server.

Podobnie jak licencja MIT, jest to bardzo liberalna licencja nie będąca copyleft, która umożliwia korzystanie z oprogramowania w dowolnym celu, jego dystrybucję, modyfikację i dystrybucję jego pochodnych prac bez obaw o tantiemy. Jego główną różnicą w porównaniu z licencją MIT są:

• Korzystając z licencji Apache, autorzy oprogramowania udzielają licencji patentowych każdemu użytkownikowi lub dystrybutorowi kodu. Te licencje patentowe mają zastosowanie do każdego patentu, który będąc licencjonowanym przez dowolnego autora oprogramowania, zostałby naruszony przez utworzony przez niego fragment kodu.
• Licencja Apache wymaga, aby niezmodyfikowane części w utworach pochodnych zachowały Licencję.
• W każdym licencjonowanym pliku należy zachować wszelkie oryginalne informacje o prawach autorskich, patentach, znakach towarowych lub atrybucjach.
• Każda zmiana w licencjonowanym pliku musi zawierać powiadomienie stwierdzające, że zmiany zostały dokonane w pliku.
• Jeśli oprogramowanie na licencji Apache zawiera plik NOTICE, ten plik i jego zawartość muszą być zachowane we wszystkich pracach pochodnych.
• Jeśli ktokolwiek celowo wyśle ​​do autorów wkład dotyczący oprogramowania na licencji Apache, wkład ten może zostać automatycznie wykorzystany na podstawie licencji Apache.

Ta licencja jest interesująca ze względu na automatyczną licencję patentową oraz klauzulę o zgłoszeniu wkładu.

Jest zgodny z GPL, więc możesz mieszać licencjonowany kod Apache z oprogramowaniem GPL.

Licencja BSD

Istnieją 3 różne licencje BSD. Wszystkie są bardzo liberalnymi licencjami bez copyleft.

Dwuklauzulowa licencja BSD (lub uproszczona licencja BSD) jest całkowitym odpowiednikiem licencji MIT, która została wyjaśniona wcześniej.

3-klauzula Licencja BSD (lub Nowa Licencja BSD) dodaje jedną klauzulę, określającą, że ani nazwisko właściciela praw autorskich, ani nazwiska jego współtwórców nie mogą być używane do promowania lub promowania produktów wywodzących się z oprogramowania bez uprzedniej pisemnej zgody. Ta wersja jest zgodna z GPL, co pozwala na łączenie kodu na licencji 3 klauzul BSD z oprogramowaniem GPL.

4-klauzula Licencja BSD (lub Oryginalna Licencja BSD) dodaje kolejną klauzulę, określając, że wszystkie materiały reklamowe wspominające funkcje lub użycie oprogramowania muszą zawierać potwierdzenie, że produkt zawiera oprogramowanie opracowane przez właściciela praw autorskich. Ta czteroklauzulowa licencja BSD nie jest zgodna z GPL. Kod z tą licencją nie może być ponownie licencjonowany zgodnie z warunkami GPL, ponieważ czwarta klauzula dodaje wymaganie, które nie jest wymagane w GPL.

Mniejsza Powszechna Licencja Publiczna GNU (LGPL)

LGPL została stworzona przez FSF jako modyfikacja GPL ze słabszym copyleft, umożliwiająca łączenie oprogramowania na licencji LGPL z dowolnym innym oprogramowaniem. W swoich początkach LGPL oznaczało „Library General Public License”, ale później przyjęło swoją obecną nazwę „Lesser General Public License”, co oznacza opinię FSF, która mówi, że całe oprogramowanie powinno być wolne, a przez to nie powinno być powszechnie używane.

Możesz połączyć kod o zamkniętym kodzie źródłowym z biblioteką lub oprogramowaniem LGPL i rozpowszechniać wyniki końcowe, o ile:

• Podajesz kod źródłowy części objętej LGPL wraz ze wszystkimi modyfikacjami, które w niej wprowadziłeś.
• Każdy użytkownik z wystarczającą wiedzą jest w stanie zastąpić część programu z LGPL zmodyfikowaną wersją. Można to zrobić, rozpowszechniając część programu z licencją LGPL jako bibliotekę dynamiczną (DLL w Windows, .so w Linux/Unix) lub dostarczając kod wynikowy części programu, która nie jest objęta LGPL.

LGPL v3 jest kompatybilny z GPLv3, więc możesz wprowadzić kod LGPLv3 do oprogramowania GPL.

Licencja artystyczna

Licencja artystyczna w obecnej wersji 2.0 jest liberalną licencją open-source bez copyleft, podobną do licencji MIT.

Główna różnica między licencją MIT a licencją artystyczną polega na tym, że ta ostatnia wymaga, aby wszelkie modyfikacje wprowadzone w kodzie były wyraźnie określone.

Ta licencja jest prawie wyłącznie używana w społeczności Perla.

Obecna licencja artystyczna 2.0 jest zgodna z GPL: możesz mieszać kod z licencją artystyczną z oprogramowaniem GPL.

Licencja Publiczna Microsoft (MS-PL)

Microsoft Public License została stworzona w 2008 roku przez tę firmę jako jedna z licencji open-source stworzonych przez ich Shared Source Initiative.

Jest to ścisła, słaba licencja typu copyleft: umożliwia tworzenie i dystrybucję programów o zamkniętym kodzie źródłowym z kodem MS-PLed, ale zobowiązuje do używania MS-PL jako licencji dzieł pochodnych, jeśli są one rozpowszechniane w kodzie źródłowym.

Osobiście uważam, że ta licencja jest nieco przewrotna i sprzeczna z duchem open-source, pozwalająca na zamknięcie kodu tak, że w pewnym sensie właściciel praw autorskich nie przejmuje się tym, co można zrobić z oprogramowaniem, ale nie można udostępnij kod do zmieszania z innym kodem źródłowym typu copyleft. Więc z drugiej strony właściciel praw autorskich naprawdę dba o to, co możesz zrobić, i nie chce, abyś używał kodu z powodów takich jak ulepszanie Linuksa.

MS-PL jest niezgodny z GPL.

Licencja publiczna Eclipse (EPL)

Licencja Publiczna Eclipse to licencja stworzona przez Fundację Eclipse dla zintegrowanego środowiska programistycznego. Jest to restrykcyjna i słaba licencja typu copyleft, podobna pod wieloma względami do LGPL. Zawiera również klauzule dotyczące automatycznego udzielania licencji patentowych.

EPL jest niezgodna z GPL.

Licencja publiczna Mozilli (MPL)

Mozilla Public License w wersji 2.0 jest słabą, liberalną licencją typu copyleft, stworzoną przez Mozilla Foundation dla swoich produktów.

Moglibyśmy uznać tę licencję za podobną do LGPL, ale z tą główną różnicą, że MPL pozwala również na statyczne łączenie fragmentów kodu z MPL z oprogramowaniem o zamkniętym kodzie źródłowym.

MPL w obecnej wersji 2.0 jest zgodny z GPL. Nie dotyczy to poprzednich wersji MPL.

Wspólna licencja programistyczna i dystrybucyjna (CDDL)

CDDL jest słabą, liberalną licencją typu copyleft, stworzoną przez firmę Sun (obecnie Oracle) w oparciu o MPL w wersji 1.1. Zasadniczo ma takie same właściwości jak MPL. Jej warunki zostały doprecyzowane, ale nie zmieniły się znacząco.

CDDL to licencja open-source wybrana przez firmę Sun (obecnie Oracle) dla wielu swoich produktów, między innymi OpenSolaris czy NetBeans.

Ponieważ ta licencja była oparta na MPLv1.1, ta licencja nie jest zgodna z GPL, więc nie można mieszać źródła na licencji CDDL z oprogramowaniem na licencji GPL. Wiele osób twierdzi, że było to zamierzone, więc kodu źródłowego OpenSolarisa nie można wprowadzić do jądra Linuksa.

Powszechna Licencja Publiczna GNU Affero (AGPL)

AGPL to wersja GPL z jeszcze silniejszym i bardziej restrykcyjnym copyleft. Zobowiązuje do udostępnienia kodu źródłowego aplikacji nie tylko osobom otrzymującym kopię oprogramowania, ale także osobom korzystającym z tego oprogramowania za pośrednictwem sieci komputerowej.

Ta licencja została stworzona przez FSF, aby dać programistom środki pozwalające uniknąć praktycznego zamknięcia oprogramowania typu open source, gdy jest ono wykonywane na serwerach sieciowych lub w chmurze, ponieważ GPL nie może zmusić dostawców usług do udostępnienia kodu źródłowego użytkownikom . W takim przypadku oprogramowanie nie jest rozpowszechniane.

AGPLv3 jest kompatybilny z GPL3. Możesz umieścić kod AGPLv3 w kodzie GPLv3, o ile końcowy wynik jest objęty licencją AGPLv3.

Licencja ISC

Licencja ISC to liberalna licencja wolnego oprogramowania napisana przez Internet Software Consortium (ISC). Jest funkcjonalnie równoważny z 2-klauzulowymi licencjami BSD i MIT, po usunięciu niektórych języków, które uznano za niepotrzebne.

Początkowo używana we własnych wydaniach oprogramowania ISC, od tego czasu stała się preferowaną licencją OpenBSD (od czerwca 2003) między innymi projektami.

Jest zgodny z GPL: możesz mieszać kod na licencji ISC z oprogramowaniem GPL.

Licencja wzajemna firmy Microsoft (MS-RL)

Microsoft Reciprocal License została stworzona w 2008 roku przez tę firmę jako jedna z licencji open-source stworzonych przez ich Shared Source Initiative.

Jest podobny do opisanego wcześniej MS-PL, ale ma nieco silniejszy copyleft, przypominający warunki LGPL, CDDL i EPL. Wymaga to, aby jeśli mieszasz swój kod z kodem źródłowym na licencji MS-RL i chcesz rozpowszechniać wyniki końcowe, przynajmniej oryginalna część z licencją MS-RL musi nadal być licencjonowana z tą licencją.

Nie jest zgodny z GPL.

Domena publiczna (CC0)

Według Wikipedii „dzieła należące do domeny publicznej to te, których prawa własności intelektualnej wygasły, zostały utracone lub nie mają zastosowania”. Dedykując utwór do domeny publicznej, autor zrzeka się wszelkich praw do niego wynikających z prawa autorskiego.

Istnieje kilka projektów oprogramowania w domenie publicznej, na przykład SQLite, biblioteka implementująca łatwy do osadzania i prosty silnik bazy danych SQL, który jest zawarty w kilku innych projektach, takich jak projekty Mozilla, Android itp.

Istnieje wiele sposobów na dedykowanie oprogramowania do domeny publicznej. Creative Commons stworzyło CC0 Public Domain Dedication, uniwersalny sposób na przekazanie dzieła do domeny publicznej. FSF zaleca używanie tego tekstu do dedykowania oprogramowania w domenie publicznej.

Prace w domenie publicznej są kompatybilne z dowolnymi licencjami open lub zamkniętymi źródłami i można je mieszać z dowolnym innym oprogramowaniem.

Licencjonowanie wielokrotne

Istnieje oprogramowanie typu open source, które ma podwójną lub nawet potrójną licencję. Oznacza to, że osoba, która otrzyma to oprogramowanie objęte wielokrotną licencją, może wybrać, w ramach której licencji chce je rozpowszechniać. Ponieważ każda licencja daje inne uprawnienia i nakłada inne obowiązki, należy dokonać wyboru licencji, która najlepiej odpowiada potrzebom.

Jest to typowy przypadek w niektórych bibliotekach. Na przykład NSS to biblioteka stworzona przez Mozillę, która oprócz innych funkcji związanych z bezpieczeństwem implementuje obsługę SSL/TLS. Jest potrójnie licencjonowany w ramach licencji MPL, GPL i LGPL.

Proszę, wybierz licencję

Wiele osób publikuje kod na platformach jako GitHub bez żadnej pisemnej licencji. Nikt nie powinien używać tego kodu. Nie mamy pojęcia, jakie mamy uprawnienia do korzystania z niego. Jeśli go użyjesz, możesz zostać za to pozwany. To tak, jakby ci ludzie droczyli się z nami, mówiąc: „Hej, spójrz, co zrobiłem! Fajne, prawda? Ale nie możesz tego użyć, chciałem ci tylko pokazać!”.

Proszę, nie bądź jednym z nich. Jeśli przesyłasz swój kod do GitHub lub podobnych witryn publicznych, pozwól innym używać go i ulepszać. Jeśli nie chcesz dużo myśleć, oto moje rekomendacje:

• Jeśli chcesz zachować prostotę i swobodę, pozwalając każdemu robić z Twoim kodem, co chcą, pod warunkiem, że zwrócą ci przypisanie autorstwa i nie pociągną cię do odpowiedzialności, skorzystaj z licencji MIT.
• Jeśli chcesz zachować swobodę, pozwalając wszystkim robić, co chcą z twoim kodem, ale mądrze wyliczać prawa wynikające z prawa autorskiego i przyznawać te prawa, wraz z zapewnieniem wyraźnego przyznania praw patentowych od współtwórców do użytkowników, użyj licencji Apache 2.0 .

• Jeśli zależy Ci na udostępnianiu modyfikacji i nie chcesz, aby Twój kod był używany w zamkniętych programach (ani w zamkniętych produktach programowych, ani w zamkniętych urządzeniach sprzętowych), użyj GPL v3.

  • Jeśli nie zależy Ci na możliwości wykorzystania Twojego oprogramowania w zamkniętym urządzeniu, użyj GPL v2. Ale proszę o zdanie „lub jakakolwiek nowsza wersja”, aby twój kod mógł być również używany w projektach GPLv3.
  • Jeśli nie obchodzi cię możliwość, że twoje oprogramowanie zostanie użyte w zamkniętym oprogramowaniu, o ile twoje oprogramowanie lub część, która go używa, nadal jest open-source na tych samych warunkach, użyj LGPL v3.
  • Jeśli chcesz, aby wszyscy korzystający z Twojego oprogramowania za pośrednictwem sieci mieli prawo do uzyskania jego kodu źródłowego, użyj AGPL v3.

Po tym wszystkim możesz być wyczerpany całym tym niemal bezsensownym quasi-legalnym bełkotem. Ale czy wiesz co? To jest potrzebne. Ponieważ bez licencji nie masz praw do używania ani rozpowszechniania jakiegokolwiek kodu.