Jaką licencję otwartą wybrać?

Transkrypt

1 Jaką licencję otwartą wybrać? Poradnik Autorzy dr inź. Tomasz Boiński Centrum Doskonałości Naukowej Infrastruktury Wytwarzania Aplikacji (CD NIWA). Projekt współfinansowany z Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka. Dotacje na innowacje Politechnika Gdańska, ul. Gabriela Narutowicza 11/12, Gdańsk 1/8

2 Spis treści 1. Wprowadzenie Proponowane licencje na oprogramowanie i ich cechy clause BSD Simplified BSD (2-clause BSD) MIT/X GPL LGPL Komercjalizacja otwartego/wolnego oprogramowania Jaką licencję na oprogramowanie należy wybrać? Licencja na dokumentację i inne dzieła nie będące oprogramowaniem...8 2/8

3 1. Wprowadzenie Dobór właściwej licencji jest jednym z kluczowych aspektów tworzenia otwartego oprogramowania i innych dzieł twórczych. W przypadku użycia zbyt restrykcyjnej licencji dzieło będzie niechętnie stosowane z przyczyn czysto ideologicznych, zbyt swobodna licencja z kolei powoduje utratę jakiegokolwiek wpływu na jego dalsze wykorzystanie. W ogólności licencje możemy podzielić na dwa rodzaje dbające o wolność użytkownika (licencje typu BSD) lub dbające o wolność samego oprogramowania (GPL). Każda z nich niesie pewne korzyści ale też i zobowiązania. Należy też pamiętać, że wydając dzieło na otwartych licencjach nie możemy nikomu zabronić jego użytkowania, nawet jeżeli nie zaakceptuje on naszej licencji. Jednak skorzystanie z jakichkolwiek dodatkowych praw wynikających z licencji, a wykraczających samo użytkowanie aplikacji, wymaga już całkowitego podporządkowania się jej zasadom. Niniejszy poradnik ma za zadanie przedstawić proponowane wolne i otwarte licencje oraz dopomóc w wyborze właściwej z nich. 2. Proponowane licencje na oprogramowanie i ich cechy clause BSD Jest to prosta, zezwalająca licencja dająca odbiorcy oprogramowania pełnię praw na zasadzie: możesz z tym zrobić co zechcesz poza stwierdzeniem, że to napisałeś. Oprogramowanie wykorzystujący kod na licencji BSD może być wydane na dowolnej, również zamkniętej licencji, niezależnie od stopnia w jakim wykorzystuje nasz kod. Licencja wymaga jednak, by była dołączona zarówno do postaci źródłowej jak i binarnej do produktu pochodnego. Zabronione jest również używanie nazwy oryginalnego twórcy w promocji produktów pochodnych. Licencja ta jest bardzo przyjemna dla odbiorców końcowych, gdyż nie narzuca jakichkolwiek ograniczeń co do sposobu wykorzystania naszego kodu. Z powodu możliwości nieograniczonego łączenia jej z innymi licencjami utrudnia jednak przyszłe komercyjne zastosowanie inne niż oferowanie wsparcia czy szkoleń związanego z wdrożeniem oprogramowania. Licencja ta nie wymaga również publikacji zmian wprowadzonych do oryginalnego oprogramowania. Więc kiedy ją użyć? W sytuacji, gdy nie wiążemy żadnych planów z naszym oprogramowaniem i chcemy je udostępnić jak najszerszemu gronu odbiorców licencja tego typu jest najlepszym wyborem. Oprogramowanie tego typu jest obecnie składową systemów typu Linux, UNIX, czy nawet Windows, oraz licznych aplikacji użytkowych. Kod na licencji BSD jest szczególnie popularny w zamkniętym oprogramowaniu, gdyż nie narzuca praktycznie żadnych ograniczeń. Pomimo tego twórcy tych rozwiązań są szeroko znanymi i uznanymi osobowościami czy instytucjami, a sam kod tworzony jest z myślą o pełnym jego otwarciu i jak najszerszego zastosowania Simplified BSD (2-clause BSD) Licencja podobna do tej z punktu 2.1, jednak z wykluczoną koniecznością pozyskania zgody na reklamę 3/8

4 dzieła pochodnego nazwą twórcy oprogramowania wydanego na tej licencji. Podobnie jak w przypadku 3-clause BSD, wykorzystanie licencji nie wiąże się z jakimikolwiek ograniczeniami MIT/X11 Jest to prosta licencja tożsama z licencją BSD, zwłaszcza z wersją 3-zdaniową. Stosowana byłą głównie przez XFree86, najpopularniejszej implementacji systemu X Window dla systemów UNIX'owych. Podobnie jak w przypadku licencji typu BSD, oprogramowanie wydane na licencji MIT/X11 może być wykorzystywane w zamkniętym kodzie, pod warunkiem dołączenia treści licencji. Jako, że licencja BSD jest niejednoznaczna (istnieją przynajmniej jej 3 wersje) Richard Stallman proponuje zamiast którejkolwiek z licencji BSD używać licencji MIT/X11. Jednakże część prawników wskazuje, że licencja MIT/X11 zawiera nieprecyzyjne sformułowania zajmować się oprogramowaniem (w oryg. to deal in the Software ) oraz oprogramowanie i związane [dołączone] pliki dokumentacji (w oryg. this software and associated documentation files ), które (wg np. Rosena) mogą sprawiać problemy w interpretacji prawnej GPL Jest to najpopularniejsza wolna licencja. W odróżnieniu od licencji zezwalających (jak np. BSD) za cel stawia sobie wolność oprogramowania a nie użytkownika. Podstawowe warunki licencji to: treść licencji musi być rozpowszechniana wraz z oprogramowaniem, kod źródłowy musi być dostępny wraz z postacią binarną, lub być łatwo i bezpłatnie dostępny w inny sposób każdy odbiorca ma dokładnie takie same prawa nie można wykluczyć żadnego podmiotu z praw wynikających z licencji czy zabronić mu wykorzystania oprogramowania, użytkownik uzyskuje pełnię praw do uzyskanej kopii, może więc ją dalej kopiować, dystrybuować, modyfikować i wykorzystywać do tworzenia dzieł pochodnych, jednakże: każda kopia musi być rozpowszechniana na tej samej licencji co oryginał, każde dzieło pochodne, funkcjonujące w obrębie jednego procesu z kodem wydanym na licencji GPL (nawet w przypadku dynamicznego linkowania!) musi również być wydane na takiej samej licencji jak oryginalny kod, wszelkie zmiany upowszechnione w jakiejkowliek postaci wymagają udostępnienia ich kodu źródłowego. Licencja GPL gwarantuje więc, że nasze oprogramowanie nie zostanie wykorzystane w zamkniętym rozwiązaniu. Gwarantuje też pozyskanie wszystkich zmian wykonanych przez inne osoby. Z drugiej strony wszelkie zastosowania niekomercyjne, czy komercyjne nastawione na usługi mogą z powodzeniem z naszego oprogramowania korzystać. Licencja ta pozwala więc na zachowanie pewnej kontroli nad zakresem działań jakie będą możliwe do wykonania przez użytkowników końcowych oraz z jakim oprogramowaniem będzie wykorzystywane. Licencja GPL obecnie stosowana jest w dwu wersjach 2.1 oraz 3. Wersja 3cia jest zaktualizowaną wersją i dostosowaną do bieżących wyzwań informatyki. Jej krytycy argumentują jednak, że jest zbędna i zbyt ogranicza użytkowników końcowych. Główne różnice pomiędzy obiema wersjami, wprowadzone w wersji trzeciej, obejmują: 4/8

5 udzielenie niezbywalnej, przechodniej licencji na patenty implementowane przez oprogramowanie, zakaz stosowania oprogramowania wydanego na licencji GPL v3 do ograniczania wolności użytkowników, czyli np. jako mechanizmy typu DRM, zakaz tzw. "tivoizacji", czyli procesu polegającego na produkcji sprzętu obsługiwanego poprzez otwarte oprogramowanie, ale z wbudowanym zabezpieczeniem przed modyfikacją kodu. W ten sposób użytkownik otrzymywał kod źródłowy oprogramowania, mógł go zmodyfikować i samodzielnie skompilować (a tym samym warunki licencji GPL v2.1 zostały spełnione), jednak sprzęt odmawiał współpracy ze zmodyfikowanym kodem poprzez dodatkowe zabezpieczenia sprzętowe, dodanie zbioru klauzul opcjonalnych pozwalających indywidualnie zmieniać w ściśle określonym zakresie zapisy licencji, zakaz współpracy pomiędzy firmami stosującymi oprogramowanie zamknięte i firmami stosującymi oprogramowanie otwarte, podobnej do współpracy pomiędzy firmami Novell i Microsoft. Większość nowych projektów, jak i znaczna liczba starych, jest przekształcana na licencję GPL v3 więc wydaje się, że jest to ta wersja, którą należy przypisywać oprogramowaniu. Jednakże ostateczny wybór uzależniony jest od akceptacji (lub nie) zmian jakie pojawiły się względem wersji 2.1. Linus Torvalds stwierdził dla przykłądu, że nie ma potrzeby zastępować dobrej licencji inną i nie ma zamiaru przejść w przypadku jądra systemu Linux na wersję 3. Licencja GPL powinna być stosowana w przypadku otwierania kompletnych systemów, które chcemy pokazać światu, bez utraty przynajmniej części kontroli nad sposobem jej wykorzystania. Jest z powodzeniem stosowana dla małych jak i dużych projektów i stanowi obecnie podstawę ruchu wolnego i otwartego oprogramowania LGPL Licencja GPL, przedstawiona w poprzednim punkcie, posiada pewną charakterystyczną cechę, powodującą jej ograniczone zastosowanie w przypadku tworzenia dzieł pochodnych, które nie chcemy by były wydane na licencji GPL, a mianowicie jej "wirusowość" każdy kod związany w jakikolwiek sposób z kodem wydanym na licencji GPL musi być rozpowszechniany na tej samej licencji. W związku z tym utworzono licencję LGPL, która jest de facto licencją GPL, ale z brakiem wymogu publikacji dzieła pochodnego na licencji LGPL w sytuacji, gdy nasze oprogramowanie jest odrębną całością współpracującą z nową aplikacją. Podobnie jak w przypadku licencji GPL, obecnie obowiązują dwie wersje 2.1 oraz 3. Zmiany pomiędzy nimi są identyczne jak w przypadku licencji GPL. Licencję tą należy stosować w sytuacjach podobnych jak dla GPL, ale gdy chcemy umożliwić innym wykorzystanie naszego rozwiązania również w aplikacjach komercyjnych, ale z zachowaniem integralności i odrębności naszego dzieła. Doskonałym przykładem są tu biblioteki, których większość wydana jest na licencji LGPL. Zewnętrzne systemy mogą więc, niezależnie od ich licencji, wykorzystywać możliwości naszej biblioteki, jednak same modyfikacje, poprawki czy rozszerzenia samej biblioteki muszą już być rozpowszechnione na licencji LGPL. Innym przykładem aplikacji wydanej na licencji LGPL jest pakiet OpenOffice /LibreOffice. Pomimo, że 5/8

6 jest to kompletny i niezależny system zdecydowano się na wydanie go na licencji LGPL zamiast GPL. Decyzja ta spowodowana była możliwością rozbudowy możliwości pakietu OpenOffice/LibreOffice o nowe funkcjonalności poprzez makra i skrypty w wbudowanym w pakiet języku. W przypadku wydania aplikacji na licencji GPL również te rozwiązania musiałyby być publikowane na licencji GPL. 3. Komercjalizacja otwartego/wolnego oprogramowania Jeżeli posiadamy pełnię praw autorskich majątkowych do oprogramowania, zawsze możemy wydać dowolną jego wersję na dowolnej licencji, niezależnie od tych już przyznanych. Proces ten nazywa się podwójnym licencjonowaniem i jest z powodzeniem stosowany przez wiele komercyjnych organizacji, jak np. RedHat, Oracle (właściciel MySQL), Stylite (egroupware) itp. Każde oprogramowanie, które wydaliśmy na licencji otwartej możemy więc również oferować na zasadach komercyjnych. Należy jednak pamiętać, że udostępnienie oprogramowania na określonej licencji otwartej może być trudne do cofnięcia. W polskim prawodawstwie co prawda nie funkcjonuje pojęcie niewygasalnych licencji (ang. perpetual licences). Usankcjonowanie wycofania licencji względem wszystkich odbiorców oprogramowania, zwłaszcza tych, którzy uzyskali je nie bezpośrednio od nas, może być w dużej mierze niemożliwe do wykonania. W przypadku np. prawodawstwa w USA otwartych licencji z definicji nie można wypowiedzieć. Niezależnie jednak od decyzji w przypadku podwójnego licencjonowania rozwijane są dwie gałęzie oprogramowania otwarta i komercyjna. Ta pierwsza jest publicznie dostępna. Druga oferowana jest chętnym, którzy z różnych względów, najczęściej integracyjnych, nie mogą zgodzić się na licencję typu GPL/LGPL, lub wymagają wsparcia technicznego, pomocy w rozwoju itp. Należy tutaj zauważyć, że zastosowanie licencji typu BSD ogranicza możliwość komercjalizacji rozwiązania do świadczenia wsparcia technicznego itp., gdyż ta licencja nie ma wpływu na licencję dzieł pochodnych. Aspekt ten należy wziąć pod uwagę decydując się na określoną licencję. 4. Jaką licencję na oprogramowanie należy wybrać? Proces wyboru licencji został przedstawiony na Rys. 1. Diagram ten uwzględnia informacje zawarte w punktach 2 i 3 w postaci pytań typu TAK/NIE. Odpowiedź na nie zasugeruje najlepszą licencję dla danego rozwiązania. 6/8

7 Rysunek 1: Proponowany proces wyboru otwartej licencji 7/8

8 5. Licencja na dokumentację i inne dzieła nie będące oprogramowaniem W przypadku rozwiązań nie będących oprogramowaniem zalecane jest użycie licencji Creative Commons w wersji 3 lub nowszej, a najlepiej 4.0. Licencja ta posiada kilka opcjonalnych wariantów pozwalających na jej dopasowanie do indywidualnych potrzeb. Te podstawowe warunki licencji Creative Commons to: 1. uznanie autorstwa - wolno kopiować, rozprowadzać, przedstawiać i wykonywać objęty prawem autorskim utwór oraz opracowane na jego podstawie utwory zależne pod warunkiem, że zostanie przywołane nazwisko autora pierwowzoru, 2. użycie niekomercyjne - wolno kopiować, rozprowadzać, przedstawiać i wykonywać objęty prawem autorskim utwór oraz opracowane na jego podstawie utwory zależne jedynie do celów niekomercyjnych, 3. na tych samych warunkach - wolno rozprowadzać utwory zależne jedynie na licencji identycznej do tej, na jakiej udostępniono utwór oryginalny, 4. bez utworów zależnych - wolno kopiować, rozprowadzać, przedstawiać i wykonywać utwór jedynie w jego oryginalnej postaci tworzenie utworów zależnych nie jest dozwolone. Bazując na tych czterech wariantach, poprzez ich dowolną kombinację, możliwe jest opracowanie właściwej dla nas wersji licencji. Wszystkie dostępne warianty zaprezentowane są na stronie Można również skorzystać w tym celu z kreatora dostępnego na stronie (zalecane). W przypadku wersji 4.0 mamy do dyspozycji tylko wersję międzynarodową. W przypadku gdy chcemy skorzystać z odwzorowania na prawodawstwo polskie należy skorzystać z wersji 3.0 licencji. Powyższy kreator pozwoli na wygenerowanie zarówno grafiki informacyjnej o typie licencji jak i kodu HTML zawierającego odpowiednie metadane. Odpowiedni kreator dostępny jest również w trakcie deponowania dzieł w oferowanego w ramach CD NIWA repozytorium instytucjonalnego. Użytkownik deponując rozwiązanie w repozytorium może określić wszystkie parametry dostępne poprzez kreator opisany powyżej dla licencji w wariancie Creative Commons 3.0 Polska. Odpowiednia informacja zostanie automatycznie zaprezentowana wszystkim użytkownikom na stronie z pozycją. 8/8