Rozpoczynamy nowy projekt. Pierwszą rzeczą, no może pierwszą po wybraniu jego motywu przewodniego, jest licencja. Zwykle bez namysłu sięgamy po GNU GPL – bo wszyscy tak robią, bo wydaje nam się, że dzieki temu zabezpieczymy swoje prawa, bo ta licencja uniemożliwi umieszczenie naszego kodu w zamkniętym oprogramowaniu. Czy jednak postępujemy słusznie?
Zastanawiają się nad tym również Bjorn Reese i Daniel Stenberg – dwaj programiści, których artykuł pojawił się niedawno na stronach prowadzonych przez wydawnictwo O’Reilly. Working Without Copyleft jest analizą postępowania twórców wolnego oprogramowania, wolnych licencji oraz korzyści płynących z przejęcia efektów naszej pracy przez komercyjne firmy.
Z tekstem Reese’a i Stenberga powinni zapoznać się wszyscy świadomi programiści. Spróbuję pokrótce przedstawić jego najważniejsze tezy.
Całość zaczyna się swoistym wyznaniem winy – autorzy zwracają uwagę na fakt, że przez długi czas tworzyli oprogramowanie rozprowadzane później na zasadach lewa autorskiego (copyleft). Problemy pojawiały się, gdy chciano dołączyć do projektu kod licencjonowany w sposób inny, niż GPL. GNU GPL zabrania łączenia kodu chronionego niekompatybilnymi (z GPLem) licencjami. Problemu nie rozwiazywało publikowanie kodu na dwóch licencjach (jak w projekcie Mozilla), ponieważ zawsze istniała możliwość stworzenia gałęzi opartej tylko o jedną z nich. Free Software Foundation nie zgodziła się niestety na dodanie nakazu mówiącego, że z żadnej z licencji nie można zrezygnować.
Skoro GNU GPL ogranicza twórców, to jak chronić swój kod przed zamknięciem i wykorzystaniem do celów czysto komercyjnych? To pytanie spędza sen z powiek wielu programistów. Jednak, jak uważają twórcy artykułu opublikowanego przez O’Reilly Network, pytanie nie powinno brzmieć jak chronić, tylko czy chronić.
Należy przecież pamiętać, że przyłączenie cudzego kodu do własnego projektu nie jest rzeczą prostą. Jeśli kod wynikowy ma być okazem doskonałości i stabilności, niemałą pracę trzeba włożyć w przejrzenie, udokumentowanie(!) oraz przystosowanie do własnych wymagań dodawanego oprogramowania. Często okazuje się, że skórka niewarta jest wyprawki.
Jednak kiedy już jakaś firma zdecyduje się na pożyczenie efektów naszej pracy i włączenie ich do swojego oprogramowania, nie musimy być na tym stratni. Przede wszystkim może okazać się, że wprowadzone poprawki wrócą do autorów. Wbrew pozorom, jest to opłacalne dla firm wykorzystujących oprogramowanie open source w swoich produktach. Oznacza, że będą mogły brać kolejne wersje naszego oprogramowania bez wiekszych poprawek – to dzięki temu, że bedzie ono kompatybilne z ich rozwiązaniami. Właśnie dzięki poprawkom, które zostaną odesłane.
Jeśli jednak poprawki do nas nie dotrą, również nie jesteśmy stratni. Przede wszystkim dzięki wykorzystaniu naszego kodu w cudzych projektach mamy mniej pracy przy utrzymaniu kompatybilności naszego kodu z komercyjną konkurencją. Pojawia się nawet szansa, że opracowane przez nas rozwiązanie stanie się standardem. No i w końcu możemy umieścić informację o naszym wkładzie w duży projekt w naszym CV, a potem starać się o pracę w firmie, która ten kod wykorzystała 😉
To oczywiście tylko część argumentacji przedstawionej przez twórców Working Without Copyleft. Warto przeczytać cały tekst, może natchnie was do zmiany ulubionej licencji na bardziej liberalną?
PS: link do artykułu dostaliśmy od andrew(at)bulba.umcs.lublin.pl. Dziękujemy.
Archiwalny news dodany przez użytkownika: honey.
Kliknij tutaj by zobaczyć archiwalne komentarze.