Co się odwlecze, czyli pułapki licencjonowania

Data: 2017-02-28
Autor: Sebastian Konkol
Co się odwlecze, czyli pułapki licencjonowania

W kilku ostatnich projektach podejmowałem zagadnienia reguł licencjonowania tzw. gotowych rozwiązań informatycznych dostarczanych przez znane, duże firmy z branży. Muszę przyznać, że jestem pod wrażeniem sprytu branży w kształtowaniu tych reguł – sprytu niosącego poważne ryzyko dla kupujących te rozwiązania.

Dla ustalenia uwagi, umowy licencyjne muszą być, gdyż twórcy oprogramowania mają prawo do ochrony swoich wytworów. Dawno, dawno temu, kiedy systemy informatyczne były tworzone jako monolity dające minimalne możliwości integracji, licencje były po to, aby regulować sposób bezpośredniego korzystania z rozwiązania. Odkąd informatykę składa się z klocków, a otwartość na możliwości integracji staje się nawet ważniejszą cechą niż funkcjonalność, ciekawszym polem do popisu jest regulowanie zasad integracji i rozwoju takich „gotowych” rozwiązań. Co ciekawe, wraz ze zmianami zachodzącymi w wymiarze „otwartości” rozwiązań, zmieniały się także metody egzekwowania umów licencyjnych. W okresie dawno temu stosowano bardziej metody kontroli ex-ante, włączając serwery licencji, klucze sprzętowe i inne rozwiązania zapobiegające możliwości złamania umowy licencyjnej. Dzisiaj masowo stosowane są metody kontroli ex-post, opierające się na audytach wykorzystania licencji i karach załamanie takich umów. W praktyce okazuje się, że znacznie korzystniej (szczególnie finansowo) jest interpretować bardzo niejednoznaczne zapisy umów licencyjnych post factum, niż nie dopuszczać do łamania zasad takich umów. Spryt umów licencyjnych polega na niejednoznaczności zapisów stosowanych w takich umowach, umożliwiając bardzo szeroką interpretację.

Jest kilka wzorcowych przykładów wykorzystywanych w umowach. Pierwszym z nich jest rozróżnienie integracji z danym rozwiązaniem na zapisywanie danych do rozwiązania i odczytywanie danych z rozwiązania, gdzie odczyt nie wymaga licencji, a zapis wymaga. W tym przypadku, kiedy jakiś użytkownik – nawet nie działając bezpośrednio – dokonuje zapisu danych do systemu licencjonowanego, zgodność z zapisami umowy licencyjnej narzuca konieczność zakupienia licencji dla tego użytkownika na licencjonowany system, nawet jeśli ten użytkownik w życiu nie dotknął systemu licencjonowanego. Inny przykład opiera się na rozróżnieniu zapisu danych do systemu licencjonowanego na zapis dokonywany wsadowo i on-line, z wymaganiem licencji w przypadku zapisu on-line. Jeszcze inny przykład to wprowadzenie gradacji funkcji dostępnych w gotowym rozwiązaniu i obwarowanie ich różnymi poziomami licencji. Różne tego typu sztuczki są obecne w umowach licencyjnych wszystkich znaczących dostawców (np. SAP, IBM, HP, Microsoft) – znaczących, czyli takich, których umowy licencyjne nie podlegają negocjacjom.

Przy odpowiednim poziomie rozmycia definicji (np. wsadowo vs. on-line) możliwości interpretacji zgodności wykorzystania rozwiązania z warunkami umowy licencyjnej stają się ogromne, a wyniki audytu licencji mogą stanowić istotny składnik procesów negocjacyjnych między dostawcą rozwiązania a firmą je użytkującą. Spryt (czy może to już perfidia?) kształtowania umów licencyjnych idzie jednak dalej. Każde rozwiązanie „gotowe” jest wszak rozwijane, a możliwość „darmowego” upgrade’u jest przecież zaletą umowy licencyjnej, prawda? Niezupełnie. Wraz z upgrade’m akceptowana jest nowa postać umowy licencyjnej, która – tak samo, jak system licencjonowany – mogła podlegać zmianom. Jakaś funkcja systemu mogła w nowej wersji „wyladować” w wyższym progu licencjonowania, a jej użytkowanie w nowej wersji wymaga także „upgrade’u” licencji. Zmienia się definicja „wsadowości” lub „onlajnowości” rozgraniczających możliwość utrzymania braku licencji dla integracji. Utrzymywana jest możliwość „braku licencji” na zapisywanie danych do rozwiązania gotowego – uwarunkowane wykorzystaniem technologii pośredniczącej od tego samego dostawcy – lecz cena technologii pośredniczącej wzrasta. W efekcie coś, co było zgodne z regułami licencji w starej wersji staje się niezgodne z nową wersją licencji – pułapka zastawiona. Jeśli coś takiego zostanie przeoczone w ramach decyzji o zmianie wersji licencjonowanego systemu, pułapka się zatrzaskuje, a wysokość kary zależna będzie jedynie od czasu do audytu i zdolności interpretacji zapisów nowej umowy licencyjnej. Zwykle boli kwotami z wieloma zerami…

Czasami powody kwotowych bóli mogą być zaskakujące. Dla przykładu, firma Oracle (bazując na zakupie Sun Microsystems dokonanym ponad 3 lata temu) zaczęła ostatnio nakładać kary za korzystanie z pewnej wersji Javy SE, która wszak jest kojarzona z filozofią open source. Pomysły na zmiany w zapisach umów licencyjnych nie są zwykle pochodną bezmyślności dostawców – zmiany takie wynikać mogą z bardzo złożonych analiz sposobu wykorzystania funkcji aplikacji, przychodów ze sprzedaży i tego, co mówią klienci (nie wspominając już o przemożnym wpływie tub propagandowych branży IT, np. Gartnera).

W ramach – przynajmniej częściowego – pewnego usprawiedliwienia dla działań dostawców licencjonowanych rozwiązań informatycznych należy przyznać, że – bez wątpienia – stan ten jest także wynikiem „podatności” kupujących rozwiązania na działania „na pograniczu” zgodności z zapisami umów licencyjnych. Odpowiednio wartościowy obszar pogranicza, zgodnego z regułami licencjonowania starej wersji rozwiązania, jest idealnym kandydatem na pułapkę upgrade’ową do nowej wersji takiego rozwiązania. Ewolucja reguł licencjonowania „przykrywana” zmianami funkcjonalnymi jest więc doskonałą pułapką na klientów działających „na pograniczu” umów licencyjnych. Tym niemniej, w moim przekonaniu nastąpiło przesunięcie znaczenia reguł licencjonowania. Kiedyś licencjonowanie służyło bezpośredniej ochronie interesów twórców systemu przez łamaniem zasad bezpośredniego korzystania z rozwiązania. Dzisiaj umowa licencyjna jest pełnoprawnym modelem biznesowym uzyskiwania korzyści z niebezpośredniego korzystania z rozwiązania i to modelem – odnoszę wrażenie – co najmniej tak istotnym jak sama sprzedaż rozwiązań. Nie muszę chyba wyjaśniać, że The Bright New World „rozwiązań chmurowych” to kolejna fala tej ewolucji, choć nie do końca chyba jeszcze zdajemy sobie sprawę z głębokości ubezwłasnowolnienia kupujących takie rozwiązania.

Uważacie, że to wszystko jest oczywiste i wszyscy dobrze o tym wiedzą? To dlaczego pośród wymagań RFI na rozwiązania tak tragicznie rzadkimi są oczekiwania stabilności reguł licencjonowania?

Pozostaw komentarz