Licencje

W ostatnim miesiącu krótko opowiedziałem o prawie autorskim, a w tym chciałbym kontynuować temat własności intelektualnej, omawiając licencje.

Początkowo oprogramowanie nie było objęte prawami autorskimi.

Jeśli źródła były dostępne i nie było kontraktu, wtedy oprogramowanie było praktycznie w domenie publicznej i ludzie mogli zrobić z nim, co tylko chcieli.

Zastosowanie prawa autorskiego do oprogramowania wszystko to zmieniło. W większości systemów prawnych prawo autorskie było generowane automatycznie i nie można było kopiować czy nawet używać źródeł oraz plików binarnych.

Oprogramowanie musiało posiadać jedną lub więcej licencji (do kodu źródłowego albo do plików binarnych), które określały, co użytkownik ma prawo z nim zrobić.

Pracując wtedy w Digital Equipment Corporation (DEC), musiałem wraz z kolegami tworzyć szczegółowe licencje dla naszych produktów. Musieliśmy nauczyć się konkretnych prawnych terminów dotyczących oprogramowania, które uzyskaliśmy z naszych źródeł, i uświadomiliśmy sobie wtedy, że w wielu przypadkach byliśmy „podlicencjobiorcą”. Oryginalni twórcy oprogramowania ciągle posiadali prawa do niego i musieliśmy chronić te prawa. Niektóre z nich przekazywaliśmy naszym klientom, a inne zachowywaliśmy sami.

Przykładowo, w większości przypadków nie mogliśmy przekazywać kodu źródłowego klientom, ponieważ dostawca ciągle posiadał prawa do plików binarnych, które dostarczaliśmy. Najlepszym tego przykładem był silnik Display PostScript od Adobe, który znalazł się na naszym serwerze X Window System i odpowiadał za wyświetlanie plików PostScript. W DEC-u było tylko dwóch inżynierów oprogramowania, którzy mogli zobaczyć kod źródłowy programu – jeden dla Digital UNIX i jeden dla OpenVMS.

Kiedy klienci DEC-a chcieli uzyskać kod źródłowy dla Ultriksa (przykładowo), który był oparty na 4.1c BSD Uniksie, musieli najpierw wykupić licencję na kod źródłowy dla Uniksa od AT&T, następnie licencję na kod źródłowy od DEC i na koniec sam kod źródłowy od DEC. W dalszym ciągu nie mogli kompilować i budować całego systemu. Brakowało kilku „kawałków”, ale nie dlatego że DEC nie chciał ich przekazać, ale dlatego że nie mógł tego zrobić.

Inną ciekawą częścią licencjonowania były licencje wystawiane dla kodu źródłowego przez uniwersytety, takie jak Uniwersytet Kalifornijski w Berkeley, MIT, Uniwersytet Carnegiego i Mellonów i inne. Uniwersytety te najczęściej chciały przekazać swój kod do innych uniwersytetów, aby umożliwić współpracę przy badaniach. Jednak nie chciały wydawać tysięcy dolarów na opłaty prawne za każdą kopię programu, skoro nie miały ich sprzedawać. Wpadły więc na pomysł zagnieżdżenia licencji w kodzie źródłowym. Nie tylko mówiła ona użytkownikom, jakie mieli prawa, ale też zabezpieczała uniwersytet, ponieważ oprogramowanie nie było objęte gwarancją do żadnego konkretnego zastosowania.

Uniwersytety posiadały różne potrzeby, więc powstało mnóstwo niewiele się od siebie różniących licencji.

Z czasem pojawiły się inne podmioty, które chciały zaznaczyć, że oprogramowanie powstało u nich, dążyły do tego, aby zmiany w narzędziach były do nich przesyłane, aby mogli je wprowadzać lub potrzebowały informacji od użytkowników.

Dodajmy do tego firmy komercyjne z ich zmianami i wkrótce otrzymamy całą masę licencji, które w niewielkim stopniu się od siebie różnią (a różnice te zwykle nie mają znaczenia).

W końcu okazało się, że takie licencjonowanie było zbyt uciążliwe, szczególnie jeśli chciało się wszystkie licencje zapisać i połączyć na jednym CD/DVD/ISO. Prawnicy dystrybucji musieliby czytać każdą z nich i sprawdzać, czy były kompatybilne.

Wtedy grupa ludzie zebrała się i przemyślała kwestię licencji, wydzielając wszystkie podobne do siebie i dzieląc je na dwie podstawowe grupy: „zezwalające” i „restrykcyjne”.

Licencje zezwalające zwykle mają mniej wymagań dla programisty korzystającego z kodu źródłowego w kwestii przekazywania zmian – do kolejnego programisty czy użytkownika końcowego. Licencje restrykcyjne, z których GPL jest najbardziej znaną, wymagają od użytkownika kodu źródłowego przekazania zmian do kolejnego programisty lub użytkownika końcowego.

Zbiór wszystkich tych licencji nazwany został „otwartym kodem źródłowym”. Jednak warto wyjaśnić, jaka jest rzeczywista różnica pomiędzy oboma typami licencji.

Firmy i deweloperzy uwielbiają otwarty kod na licencji zezwalającej. Mogą korzystać ze źródeł, które inni utworzyli, co pozwala im na szybsze dostarczanie produktów z przetestowanym kodem i nie zmusza do przekazywania własności intelektualnej innym firmom lub klientom. W tym scenariuszu, jeśli klient potrzebuje zmiany lub naprawy błędu, musi czekać, aż deweloperzy je wprowadzą.

Z kolei klienci uwielbiają restrykcyjne otwarte źródła, lepiej znane jako wolne oprogramowanie. Dzięki niemu mogą wspierać wybrane przez siebie oprogramowanie. Mogą znaleźć programistów, którzy potrafią tworzyć łatki i dzięki temu są niezależni od deweloperów, którzy program stworzyli. To jest wolność oprogramowania.

Jon „maddog” Hall jest autorem, wykładowcą, informatykiem i jednym z pionierów Wolnego Oprogramowania. Od 1994 roku, kiedy po raz pierwszy spotkał Linusa Torvaldsa i ułatwił przeniesienie jądra na systemy 64-bitowe, pozostaje orędownikiem Linuksa. Obecnie jest prezesem Linux International®.