Open source i jego aspekty prawno-biznesowe

Open source i jego aspekty prawno-biznesowe Milen Yakimov / stock.xchng

W zeszłym tygodniu redaktor popularnego serwisu Ostatic (wchodzącego w skład grupy GIGAOM), Sam Dean, opublikował na łamach swojego portalu artykuł, w którym stwierdził, iż rok 2011 upłynie pod gwiazdą Open Source.

Według Dean"a, koncerny informatyczne nie tylko będą dalej korzystać z elementów licencjonowanych w ramach OS, lecz wręcz zaczną udostępniać na warunkach tego rodzaju licencji całe systemy.

Open Source to ruch tworzący "wolne" oprogramowanie, czyli takie, do którego każdy ma dostęp za darmo (najczęściej nawet w celach komercyjnych), i które może być przez każdego dowolnie zmieniane, przystosowywane i kopiowane. Prawa do kodów Open Source udostępniane są na różnorodnych licencjach, takich jak GPL, MozillaPL czy BSD.

Open Source już dawno przestało być domeną pasjonatów i entuzjastów informatycznej anarchii. W komercyjnych celach wykorzystują je najwięksi producenci komercyjnych systemów IT – Oracle, SAP i Microsoft. Stosunkowo niedawno koncern Google stworzył system operacyjny Android, który również oparty jest o model Otwartego Oprogramowania.

Wolne Oprogramowanie przyspożyć może jednak licznych problemów prawnych komercyjnym producentom; przekonali się już o tym tacy giganci jak Oracle, Linksys czy Sun Microsystems. Dlatego też nastawieni na zysk twórcy oprogramowania wykorzystujący zasoby i rozwiązania opatrzone licencjami Open Source powinni zdawać sobie sprawę z pewnych podstawowych zagadnień prawniczych związanych z tymi umowami i brać je pod uwagę w swoich działaniach biznesowych.

Uwolnić programy

Open Source dystrybuowany jest przy pomocy różnorakich licencji. Niektóre z nich są bardziej restrykcyjne niż inne, lecz ogromnej większości z nich przyświeca idea, jak sama nazwa wskazuje, wolności oprogramowania. Oznacza to, że wiele programów Open Source można darmowo wykorzystywać nawet w celach biznesowych (również przy tworzeniu komercyjnego oprogramowania), lecz ich twórcy muszą przy okazji za darmo udostępniać ich kod, lub wręcz cały gotowy program.

Stwarza to szczególne problemy w przypadkach, w których program Open Source wykorzystywany jest jako część składową systemu – producent może być wtedy zmuszony do dystrybucji całego gotowego tworu… za darmo (takie postanowienie zawiera bardzo popularna licencja GPL 2.0).

Copyleft

Najbardziej restrykcyjnym rodzajem umów licencyjnych Open Source jest copyleft; paradoksalnie, jest on również rodzajem najbardziej popularnym. Licencje copyleft zobowiązują wszystkie osoby, które wykorzystują udostępniony na jej  warunkach kod przy tworzeniu własnego tworu do udostępniania tego tworu na warunkach odpowiedniej licencji open source. Oznacza to, iż oprogramowania zawierającego elementy objęte licencją copyleft nie można sprzedawać.

Rozważając licencje copyleft należy zwrócić uwagę na istnienie ich dwóch typów: słabego oraz mocnego copyleft. Słabe licencje copyleft pozwalają na komercjalizowanie tworów, które nie zawierają kodu nimi objętego, lecz są z nim połączone (np. program połączony z bilbiotekami objętymi licencją open source). Przykładem takiej licencji jest Open Software License v.3. Mocne licencje copyleft, takie jak niezwykle powszechna licencja GPL v.3, nie zezwalają nawet na tego rodzaju zabiegi.

BSD license

Znacznie mniej restrykcyjnym rodzajem licencji jest „BSD” - Berkeley Software Distribution License, trzyklauzulowa umowa opracowana na kalifornisjkim uniwersytecie Berkeley. Licencje BSD nie są licencjami copyleft – objęty nim kod może być łączony z komercyjnymi produktami. Jedynym warunkiem jest umieszczenie informacji o pochodzeniu i autorach kodu Open Source w dokumentacji programu.

Warto wspomnieć, iż pierwsza wersja licencji BSD (v.1) zawierała klauzulę  nakazującą umieszczanie w materiałach reklamowych komercyjnych produktów informacji o tym, iż zawierają one kod objęty BSD. W 1999 zrezygnowano z tego wymogu. Obecna wersja licencji BSD cały czas zawiera jednak inne postanowienie związane z promocją oprogramowania opartego o chronione nią twory: nie wolno używać imion lub nazw ich autorów w celach marketingowych bez ich wyraźnej zgody.

Autor królem

Większość licencji Open Source wymaga od dalszych dystrybutorów oprogramowania udostępnionego na ich warunkach umieszczania w dokumentacji odniesień do wszelkich autorów modyfkacji kodu programu.

Nie jest to najbardziej kontrowersyjne postanowienie z punktu widzenia biznesowego, lecz jest ono często ignorowane przez producentów wykorzystujących kody OS w pracach nad własnym oprogramowaniem. Jest to ogromny błąd, gdyż może okazać się, że w wyniku takiego zaniechania tracą oni licencję na kod OS, a co za tym idzie - wykorzystują go nielegalnie.

Murdes and atrocities

Demoniczny bankier inwestycyjny Patrick Bateman z flmu "American Psycho", zapytany o swoją pracę odpowiedział, że zajmuje się "murders and atrocities" zamiast "mergers and acquisitions". Niestety, taka wizja nie zawsze jest tylko koszmarem sennym szalonego yuppie - niewłaściwie użytkowane Open Source faktycznie może zamienić fuzję lub przejęcie w "morderczość" i okropność.

Podczas przygotowań do procesów M&A coraz częściej sprawdza się, czy frma biorąca w nim udział używa oprogramowania Open Source. Ma to szczególne znaczenie przy wycenie przedsiębiorstwa, a także przy analizie zgodności jej oprogramowania z postanowieniami licencyjnymi i prawami własności intelektualnej.

Słynnym przykładem problemu, który wynikł z powodu licencji open source w następstwie fuzji był spór pomiędzy Free Software Foundation a Cisco. FSF wniosło pozew przeciw informatycznemu gigantowi, gdy ten zakupił frmę Linksys (popularnego  producenta routerów), która w swoim oprogramowaniu umieszczała elementy objęte licencją Open Source nie respektując jej postanowień.

Papierkowa robota

Jak więc zabezpieczyć się przed problemami z Open Source? Przede wszystkim, trzeba wprowadzić wśród informatyków zasadę szczegółowego odnotowywania wszelkich wypadków wykorzystania kodu OS w ich pracach. Jest to zadanie wbrew pozorom dość mozolne, gdyż wielu programistów nie lubi marnować swojego czasu na taką "papierkową robotę".

Dobrym pomysłem jest również zwrócenie się do swojego prawnika z prośbą o szczegółowe przeanalizowanie licencji OS, z którymi mamy styczność podczas programowania, i przeprowadzenie analizy zgodności gotowego programu z ich postanowieniami. Jeżeli mamy zaś zamiar zakupić komercyjny system IT, powinniśmy zwrócić się z pytaniem do jego producenta o to, czy oferowane oprogramowanie zawiera elementy OS. Jeżeli okaże się, że w istocie tak jest - elementy te i związane z nimi licencje powinny zostać wyszczególnione w dokumentacji transakcyjnej.

Kancelaria Radcy Prawnego Stefan Cieśla Stefan Cieśla