Free software

Licencje free i non-free w systemach Linux – czyli jak ruch Wolnego i Otwartego Oprogramowania radzi sobie z ograniczeniami licencyjnymi

Bill Gates w 1989 roku w wywiadzie dla „Electronics Magazine” otwarcie powiedział, że: jest tylko jeden trick w oprogramowaniu – jest nim wykorzystywanie już napisanego oprogramowania. Jednocześnie ten sam człowiek przez bardzo długi czas starał się uniemożliwić wykorzystanie tego „triku” przez kogokolwiek, stosując środki prawne, takie jak zamknięte licencje oprogramowania. Po kilku latach zaczął jednak […]

Bill Gates w 1989 roku w wywiadzie dla „Electronics Magazine” otwarcie powiedział, że: jest tylko jeden trick w oprogramowaniu – jest nim wykorzystywanie już napisanego oprogramowania. Jednocześnie ten sam człowiek przez bardzo długi czas starał się uniemożliwić wykorzystanie tego „triku” przez kogokolwiek, stosując środki prawne, takie jak zamknięte licencje oprogramowania. Po kilku latach zaczął jednak dawać przyzwolenie na nieprzestrzeganie praw tych licencji, w przypadku gdy jego rozwiązania musiały konkurować z otwartym oprogramowaniem. Przykładem może być wypowiedź z 2007 roku, kiedy w jednym z wywiadów stwierdził, że: łatwiej jest konkurować z Linuxem, kiedy istnieje piractwo, niż kiedy go nie ma1.

Stworzenie Standardów – free w świecie Open Source

Jednym z głównych powodów powstania otwartych oraz wolnych systemów operacyjnych były kwestie licencyjne uniemożliwiające wykorzystanie wyżej wspomnianego „triku” stosowane przez korporacyjnych gigantów. Jednak nawet tego typu oprogramowanie potrzebowało ram umownych, takich jak licencje. Te w przypadku otwartego czy wolnego oprogramowania diametralnie różnią się od tych znanych z systemów zamkniętych. Szybko rosnąca ilość otwartych oraz wolnych systemów powodowała powstawanie ogromnej ilości licencji, które wymagały uporządkowania. Wymyślono więc pewne standardy, którymi później kierowano się, pisząc oprogramowanie i związane z nim licencje. Ograniczono także liczbę przyjętych licencji.

Dwa uznawane standardy to:

Powyższe definicje na ogół współgrały ze sobą i realizowały podobne pomysły. Z reguły w poszczególnych dystrybucjach i ich społecznościach programy na tych licencjach były określane jako free – czyli wolne (niekoniecznie darmowe). Trzeba było jednak rozwiązać pewne kwestie np. jak współżyć z oprogramowaniem o zamkniętym kodzie. Udało się przekonać korporacje pracujące nad oprogramowaniem z zamkniętym kodem do pewnych ustępstw w kwestii wykorzystania ich kodu. Nadal przynosi to obopólne korzyści, nawet jeśli droga do nich wiąże się z pewnymi sporami.

Efekty Wprowadzenia Standardów otwartego i wolnego oprogramowania

Poniżej przykłady sytuacji, z którymi mierzono się w przeszłości wraz z opisem podjętych działań:

  • chęć wykorzystania protokołu firm mających do niego prawa – np. twórcy projektu Samba podejmowali rozmowy z Microsoftem oraz IBM-em w sprawie używania protokołu SMB/CIFS. Protokoły te były wykorzystywane przez Microsoft do stworzenia rozwiązania Active Directory. Celem Samby była możliwość skutecznej pracy z Active Directory. Potrzebowała do tego jednak nieskrępowanej możliwości korzystania z wyżej wspomnianych protokołów i zapewnienia dobrej woli, aby uniknąć pozwów, np. oskarżenia o inżynierię wsteczną. W wyniku rozmów z Microsoftem i IBM-em Samba otrzymała te możliwości. Co więcej, Microsoft zrzekł się opłat za część patentów, a w późniejszym czasie zrezygnował z tworzenia oddzielnego protokołu SMB. Co więcej, Samba do dziś owocnie współpracuje z Microsoftem;
  • pośrednie narzucanie konieczności korzystania z rozwiązań o zamkniętym kodzie źródłowym – np. „Pułapka Javy”. Java jako język mógł być wykorzystywany do pisania wolnego oprogramowania, ale samo środowisko Javy nie było wolne. W efekcie korzystanie z programu o otwartym kodzie, ale napisanego w Javie, mogło wiązać się z koniecznością wykorzystania oprogramowania o zamkniętym kodzie. Ostatecznie w 2006 roku uwolniono dostateczną ilość kodu na licencji GPL dla środowiska programistycznego Javy;
  • zachowanie jasnych standardów licencyjnych w dystrybucjach – by oddzielić programy o licencjach niespełniających standardów FSF, OSI lub danej dystrybucji, podzielono rozwiązania na free oraz non-free.

Czym jest non-free?

Non-free to określenie rozwiązania, którego licencja w pewien sposób ogranicza wolności wskazane przez FSF lub zasady wypisane przez OSI. Mogą one jednak przypominać licencje otwartego lub wolnego oprogramowania. Nie umieszcza się ich domyślnie w serwerowych repozytoriach Enterprise’owych systemów Linux, takich jak np. EuroLinux.

Oprogramowanie non-free jest zwykle umieszczane w oddzielnych repozytoriach dla poszczególnych dystrybucji systemów. Najczęściej znajdują się w nich programy z licencjami typu sharware, shared source lub takie, które mimo starań o zgodność ze standardami OSI lub FSF, wytworzyły wady prawne. W repozytoriach tych rzadko pojawiają się ściśle zamknięte rozwiązania.

Poniżej wybrane czynniki powodujące uznanie licencji danego oprogramowania za non-free:

  • ograniczenia w użytkowaniu (np. licencja Code Project Open License zabrania wypożyczania, użyczania czy wykorzystywania oprogramowania w sposób „nielegalny, niemoralny lub niewłaściwy”2. Nie wolno go też sprzedawać);
  • ograniczanie użytku komercyjnego oprogramowania;
  • zakaz pobierania opłat za wykonywanie dodatkowych usług związanych z danym oprogramowaniem na rzecz jego użytkowników;
  • brak dostępu do kodu źródłowego;
  • brak zgodności z wolnymi lub otwartymi licencjami, zwykle z GPL;
  • niemożliwe lub trudne do jasnego prawnego ujęcia klauzule. Np. licencja JSON wymaga, żeby oprogramowanie było „wykorzystywane dla Dobra, a nie dla Zła”3;
  • restrykcje dotyczące dystrybucji;
  • bardzo duże podobieństwo do innej popularnej dystrybucji – celem ograniczenia chaosu w kwestii nazw umów i ich liczby (wspomniana już licencja JSON to licencja MIT z dodatkowym warunkiem).

Zatem rozwiązania non-free uniemożliwiają komercyjne wykorzystanie oprogramowania, utrudniają jego użytkowanie lub modyfikacje bądź mają wady prawne. Problemy te nie powinny raczej dotyczyć użytkownika domowego. Jednak wykorzystanie oprogramowania z licencją non-free w firmie powinno być zawsze poprzedzone rzetelną analizą treści jego licencji.

Na zakończenie

Dzięki przyjętym modelem OSI, firma EuroLinux oferuje swoim klientom produkt zgodny z tym dostarczanym przez innych dostawców. Jednak w sposób maksymalnie uczciwy – np. nie dzieląc produktów lub nie zawyżając sztucznie ich cen. W efekcie dostarcza usługi bez typowo korporacyjnego balastu, koncentrując się na ich wysokiej jakości.

Źródła:
http://archive.fortune.com/magazines/fortune/fortune_archive/2007/07/23/100134488/index.htm
Punkt 5f licencji – https://www.codeproject.com/info/cpol10.aspx
https://www.json.org/license.html

Autorzy

Artykuły na blogu są pisane przez osoby z zespołu EuroLinux. 80% treści zawdzięczamy naszym developerom, pozostałą część przygotowuje dział sprzedaży lub marketingu. Dokładamy starań, żeby treści były jak najlepsze merytorycznie i językowo, ale nie jesteśmy nieomylni. Jeśli zauważysz coś wartego poprawienia lub wyjaśnienia, będziemy wdzięczni za wiadomość.