Jeżeli życzysz sobie informacji z tej strony

Dalsze losy smoka (skurwysyna), czyli po co przed świętami negocjować umowy licencyjne

Mój post o chmurze przywołał postać smoka skurwysyna, który to smok zjednał sobie spore grono zwolenników. Ostatni z kolei mikołajkowo-promocyjny artykulik (Black December) sprowokował pytanie, czym się charakteryzuje ów smok w przypadku umów licencyjnych. Spieszę więc z odpowiedzią.

Zacznijmy od definicji smoka: to ucieleśnienie niepewności i obawy. Terra incognita, na której może stać się krzywda. Im bardziej incognita, tym groźniej. Stąd bardzo groźne smoki to w istocie skurwysyny. W powszechnej opinii smoki licencyjne to stworzenia najbardziej wszeteczne z wszetecznych. Opinia ta bywa niestety uzasadniona, ale pozwalam sobie postawić tezę, że trochę na nasze, karmicieli smoków, życzenie. Smoki są zdolne do porozumienia. Miluśkie to one nigdy nie będą, ale współżyć się da. Trzeba tylko wiedzieć, jak z nimi nawiązać nić porozumienia, bo nieostrożni grajkowie, błędni rycerze czy szewczykowie łatwo smoka rozdrażniają i smok ich je. Czasami tak sprytnie, że jeszcze przez długi czas nie wiedzą, że są właśnie trawieni. Ale jeśli do zadania podejść rzetelnie, owcę z siarką naszykować, to wiele można osiągnąć.

Co jest realnie możliwe do osiągnięcia? Odpowiedzi uniwersalnych oczywiście nie ma, nasza siła negocjacyjna zależy od pozycji naszego królestwa i wojska, czasu w którym negocjujemy, przedmiotu transakcji, a czasem świadczeń zupełnie pobocznych. Jeźdźcy różnych smoków wiedzą, że lubią one różne przysmaki – jedne marzą o chmurach, inne śnią o Hanie Solo wszechmocnym, nad światem baz władającym. Transakcje uwzględniające te marzenia są łatwiejsze do przeprowadzenia, a pole ustępstw i manewrów znacznie większe. Poniżej garść moich doświadczeń – tylko moich, subiektywnych, ale to Linkedin, tu wolno subiektywnie (małe przekleństwo też mam nadzieję Państwo wybaczą).

Zacznijmy od mitu, że ogólne warunki umów, ZCiW czy inne standardowe dokumenty nie są możliwe do zmian. Z reguły są – gdyby nie były, smoki byłyby wszędzie. Zakres tych zmian jest jednak bardzo różny, nie tylko ze względu na okoliczności opisane powyżej, ale także prawną (LMS-ową) politykę dostawców. Co, poza opłatami, powinno się negocjować?

Obszar pierwszy to niezbędnik prawny, higiena, must be, minimum przyzwoitości, korekta niepasujących, żeby nie napisać idiotycznych, przepisów. Zmiana tego, co jest oczywiście sprzeczne z wolą stron. Bywa tak, że umowy pisane pod obcym prawem nie korelują z naszymi ustawami, a domniemane skutki wynikające z polskich ustaw są nie do zaakceptowania przez biznes i muszą być zmienione. Z większością smoków temat do omówienia i to nawet na spokojnie, bez urwanych głów czy odgryzionych rąk.

Tytułem przykładu – zmiany w zakresie terytorium (polska ustawa o prawie autorskim wprowadza domniemanie siedziby licencjobiorcy, więc jeżeli umowa milczy o terytorium korzystania, jest to tylko nasza dobra Rzeczpospolita, bez Irlandii, Wlk. Brytanii i Chicago). Należy także uważać, jak pojęcie korzystania jest interpretowane przez dostawców – dla jednych jest to miejsce instalacji serwerów, ale dla innych obszar, z którego jest nawiązywane połączenie z oprogramowaniem, nawet zdalnie (wątpliwe prawnie, ale lepiej uregulować). Czasami pojawią się zakazy eksportowe, ale to już szczegóły, no chyba że ktoś ma fabrykę w Libii.

Kolejne „must be” to czas trwania licencji – z ustawy domniemanie to tylko pięć lat, więc konieczna zmiana na czas nieokreślony. Zostawienie tego bez zmian, no cóż, kosztuje, choć z reguły kolejna opłata po 5 latach ma duży upust. Okres wypowiedzenia – ustawowo jeden rok, zdecydowanie za krótko na migrację do nowego systemu, nie mówiąc o pytaniu, dlaczego niby w ogóle wypowiadać licencję, za którą została wniesiona opłata.

Jeśli zaniedbamy wprowadzenie tych podstawowych zasad, to wejdą reguły ustawowe – a to doskonała pożywka dla każdego smoka. Taka czysta proteina z kompleksem witamin.

Obszar drugi to opisanie sławnych pól eksploatacji (na marginesie: moim zdaniem art. 74.4 p.a. to nie pola eksploatacji, jeden z mitów założycielskich interpretacji prawa autorskiego). Przesądzenie, co nam wolno z oprogramowaniem czynić na dość ogólnym poziomie. Pierwsze uprawnienie opisane ustawą czyli zwielokrotnianie z reguły nie budzi zastrzeżeń, choć np. liczba instancji czy kopii zapasowych wcale nie bywa oczywista.

Znacznie więcej emocji wywołuje prawo do modyfikacji. Wielu śmiałków bardzo chce to prawo mieć, choć zapewne niewielu z nich mogłoby realnie z niego skorzystać, nawet gdyby i prawo i kod źródłowy otrzymali. W przypadku dużych dostawców prawo do modyfikacji jest zazwyczaj nierealnym, pobożnym życzeniem – jeśli dostajemy jakieś uprawnienia to tylko takie, jakie wynikają z dostarczonych nam narzędzi (choć ściśle rzecz biorąc nie jest to modyfikacja w znaczeniu prawnym). Niezwykle ciekawe są zapisy dotyczące dalszych losów takiej modyfikacji klienta – SAP np. ma różne konstrukcje zmierzające do przejęcia praw do takich zmian, od nieskutecznych do wątpliwych. Trudno to jednoznacznie uregulować, ale proszę pamiętać, że zasada jest sztywna – prawa do utworu ma ten, kto utwór stworzył. Jeśli stworzył go klient, prawa ma klient. Koniec, kropka. Może te prawa zbyć, ale to wymaga dość sformalizowanej umowy i ogólne zapisy OWU raczej nie wystarczą.

Kolejne pole eksploatacji, czyli rozpowszechnianie – z reguły w umowach zabronione, ale jeśli się postarać, dozwalane np. w grupie kapitałowej. Zdecydowanie warto opisać modele takiego rozpowszechniania, jak sublicencje czy SaaS, zwłaszcza w przypadku, gdy ktoś tworzy CUW (SaaS w odróżnieniu od sublicencji z reguły nie jest uwzględniany w standardach dostawców). Jeżeli o tym zapomnimy, może powstać trochę głupia sytuacja, gdy spółka matka kupi 1000 licencji dla spółek córek, tylko nie będzie mogła ich legalnie przekazać (bywa, bywa). Smoki wiedzą, smoki czuwają i bywają tu bezlitosne, jeśli się zagapimy przy negocjacjach. Na pocieszenie można dodać, że w odróżnieniu od modyfikacji, tutaj jest spora wola dostawców do zmian, wręcz są gotowe klauzule standardowe do podmiany. Przy okazji warto uregulować kwestie dostępu do oprogramowania przez podmioty trzecie, takie jak firmy serwisujące czy nawet administratorzy (kluczowe przy outsourcingu takich usług).

Obszar trzeci – dopasowanie umowy do potrzeb klienta na poziomie poszczególnych zapisów. Tutaj wkraczamy już w zmiany bardzo techniczne, wymagające uważnej lektury warunków standardowych. O ile pierwsze dwa obszary można zmieniać „w ciemno”, z reguły załączając do umowy coś w rodzaju indywidualnych uzgodnień, nadpisujących standardowe OWU, to obszar obecnie omawiany to operacje bezpośrednio na tekście umowy. Najbardziej klasycznym przypadkiem jest uszczegółowienie metryk licencyjnych – definicji użytkownika, PVU, obrotu (w jednym tłumaczeniu pomylono obrót z dochodem, wiele radości przy rozliczeniu licencji dostarczając), sposobu obliczania liczby licencji na procesor itp. Bardzo często w tym obszarze nie tyle zmieniamy umowę, ile doprecyzowujemy jej znaczenie. Ekstremalnie ważna czynność, bo zdecydowana większość umów jest pisana trudnym i jednocześnie dalekim od precyzji językiem. A rozróżnienie między użytkownikiem pełnym a ograniczonym może oznaczać kilka tysięcy złotych na jednej licencji. Jednym z typowych przewinień jest traktowanie urządzenia jako użytkownika – np. skanera czy kasy fiskalnej, kiedy większość umów wymaga dla każdego pracownika odrębnej licencji (co oznacza np. 5 licencji na skaner). Duże pole do popisu – jak idzie dobrze, a dostawca łaskawy, można nawet „podpiąć” pewne czynności pod tańsze metryki.

O ile obszar pierwszy i przynajmniej zasadniczo obszar drugi jest jako tako regulowany, korekty w zakresie obszaru trzeciego to może nie rzadkość, ale na pewno nie reguła. A tu zaczyna się strach prawdziwy i smok właściwy.

Obszar czwarty jest bardzo wciągający, creme de la creme, zabawa na poziomie architektury, opcji, integracji czy wirtualizacji, a nawet połączeń via wspólny storage. Czysty know how, najbardziej zajadłe smoki tu się kryją. Co gorsza i co jest krytyczne, praktycznie nie sposób tych kwestii negocjować, jeśli się nie ma docelowej wizji architektury, co jest wyzwaniem np. przy umowach wdrożeniowych, kiedy licencje kupuje się z góry, a architekturę poznajemy na etapie koncepcji wdrożenia. Ale trzeba pilnować, potwierdzać, badać, bo reguły tutaj są niejasne, wystarczy prześledzić praktykę podejścia Oracle do VMware (zwłaszcza skok interpretacyjny licencji między wersją 5.1 a 6.0). W tym obszarze podczas audytów często wykazywane jest niedolicencjonowanie, choć nie za bardzo są ku temu jasne powody kontraktowe. Jeśli zaniedbamy precyzję w umowie, jest ryzyko, że taka umowa pozwoli na dowolną interpretację audytorowi.

Takie zagadnienia można regulować kontraktowo. Problem w tym, że jeśli się dokładnie nie wie, w jaki sposób dane rozwiązanie ma działać, regulacje są dość prowizoryczne i łatwo się z nich wycofać. Coś na kształt indywidualnych interpretacji US. Jeśli dokładnie opisałeś stan faktyczny, jest szansa, że dostaniesz rozsądną interpretację. Jeśli o czymś zapomniałeś lub nie wiedziałeś (no, nie wspomniał Pan o tym, że serwer z naszym oprogramowaniem jest wpięty w farmę innych serwerów, to całkowicie zmienia sytuację…), uzgodnienia mogą nie pomóc. Smoki najprawdziwsze.

Obszar piąty nie zawsze występuje – to koordynacja już zawartych umów z nowymi warunkami. Każdy z dostawców aktualizuje swoje umowy, bywa, że co kwartał. W przypadku gdy mamy ich paczkę, wynikają ciekawe problemy. Temat na osobną dyskusję, tutaj tylko sygnalizuję – jeśli nie musisz, nie zgadzaj się bez dokładnego audytu i negocjacji na zastąpienie starych umów nowymi. W większości wypadków są to gorsze warunki. O ironio, jak już jest naprawdę źle, to taki misz masz prawny umów może pomóc.

Podsumowując – nie taki smok straszny, jak go malują. Większym kłopotem jest brak przygotowania po stronie zamawiających do tak szczegółowych rozmów. O ile kwestie finansowe są dokładnie omawiane, tak metryki, architektura itp. nie zawsze, żeby nie rzec – rzadko. Co przypomina trochę paranoję bardzo długich rozważań o wysokości kar umownych (czy 1% to dużo czy mało), kiedy sam parametr (np. dostępność) jest tak niejasny, że w ogóle nie ma jak naliczyć tej kary. Odwołując się do licencji – mamy bardzo fajną zniżkę na cenie użytkownika, tylko nie zauważamy, że przez jedną integrację (polecam np. opis licencyjny Netweavera) potrzebujemy dodatkowych kilkuset licencji. A jedna nieostrożna wirtualizacja to cena razy dwadzieścia.

Tak więc warto, należy i trzeba negocjować. Po to, aby spać spokojniej i działać w środowisku znanym i przewidywalnym. Łatwiej planować i zarządzać. SAM bez dobrej polityki kontraktowej jest półśrodkiem. Na koniec dnia jednoznaczne warunki są korzystne dla wszystkich, może poza działem audytu. Jeśli porozmawiamy z dostawcami jak partner z partnerem, pokażemy nasze potrzeby, dokładnie je omówimy, to i smok okaże się nie taki straszny, ogień z jego paszczy nie aż tak palący, w sumie można się nawet ogrzać, kolce faktycznie ostre, ale schowane. Smok – Twój przyjaciel. Święta idą!

share

No Comments Yet.

What do you think?

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *