5 Opensource

Wbrew pozorom, open source jest niezwykle restrykcyjną licencją. Warto zwrócić uwagę, czy znajduje się w oferowanym nam rozwiązaniu. Jeśli tak, może okazać się, że ewentualne nasze własne modyfikacje dostarczonego rozwiązania zostaną "zarażone" wirusem open source i będziemy musieli je ujawnić. Może też się okazać, że opłata, jakiej żąda dostawca, jest sprzeczna z licencją open source i całe oprogramowanie musi zostać nam udostępnione bez opłat licencyjnych. Jest to niedoceniany problem, ale będący coraz częściej przedmiotem sporów i orzeczeń, w tym tuż za naszą granicą - w Niemczech i Czechach. Polecam wymienienie w umowie składników open source z wyszczególnieniem licencji, na mocy których są udzielone.

6 Licencja a outsourcing

Będące w obrocie licencje praktycznie zawsze wyłączają możliwość outsourcingu. Część z nich eliminuje nawet możliwość obsługi przez podmioty zewnętrzne (np. zewnętrznych administratorów). Jeżeli tego typu operacje są planowane, warto wprowadzić odpowiednie opcje, nawet odpłatne, ale przynajmniej określające jasne reguły gry.

7 Powiązanie umowy wdrożeniowej i licencyjnej

Wspomniałem o tym, opisując modele dystrybucyjne. Zazwyczaj - a w modelu pośrednictwa w 99% - wdrożenie nie jest powiązane w całość z licencją. Jak się nie powiedzie, odbiorca nie ma szans na zwrot opłat licencyjnych. W przypadku standardowych rozwiązań, takich jak pakiety firm SAP czy Oracle, wdrożenie może dokończyć ktoś inny. W wypadku unikalnego, dedykowanego oprogramowania są to zazwyczaj zmarnowane pieniądze.

8 Zakres wdrożenia, czyli kłopot z analizą

Większość umów wdrożeniowych w momencie podpisania ma ściśle określony termin zakończenia i budżet, przedmiot zaś wdrożenia niezwykle skromnie. Materializuje się on po przeprowadzeniu analizy. Kłopot wystąpi, jeżeli analiza - nawet przeprowadzona zgodnie z regułami sztuki - nie odpowiada potrzebom zamawiającego lub założeniom biznesowym wykonawcy. Albo jesteśmy wtedy zmuszeni do wdrożenia rozwiązania niespełniającego naszych oczekiwań, albo narażamy się na konflikt z wykonawcą, który zrobi wszystko, aby podbić cenę lub wycofać się z nieopłacalnego kontraktu.

Rozwiązanie jest proste, tyle że rzadko spotykane - podpisać dwie umowy, najpierw na analizę, potem na wdrożenie. Jeśli nie da się tak zrobić, dla zamawiającego warunkiem minimum powinno być umowne prawo odstąpienia (a wiec bez podania przyczyn) po otrzymaniu analizy. Nawet jak jej koszt okaże się bezcelowy, jest to ułamek kosztów bezcelowego wdrożenia.

9 Zobowiązania nabywcy

O ile zakres zobowiązań wykonawcy znajduje się w każdej umowie, o tyle zakres współdziałania nabywcy niekoniecznie. A jest to podstawowy zarzut podnoszony przez dostawców - czy musimy zapewnić dostęp online? W jakim wymiarze nasi pracownicy mają spotykać się z konsultantami dostawcy? Co z dostępem do pomieszczeń? Zapotrzebowanie na takie czynności powinno być częścią analizy, z jasnym wskazaniem, że ryzyko nieokreślenia zakresu koniecznego współdziałania obciąża wykonawcę, jako eksperta w umowach wdrożeniowych.

10 Prawa autorskie powstałe w trakcie wdrożenia

Podczas prac wdrożeniowych powstaje sporo drobnych utworów autorskich. Parametryzacji, skryptów, konfiguracji. Warto zadbać o nabycie do nich odpowiednich uprawnień, najlepiej praw majątkowych. Być może sensowne jest też wprowadzenie zakazu udostępniania opracowanych rozwiązań konkurencji.

Bardzo ciekawa jest sytuacja takich prac, które nie są twórcze (są zdeterminowane technicznie, czy biznesowo, np. niektóre wdrożenia rozwiązań podatkowych) i nie są chronione prawem autorskim. Podstawą do ich ochrony jest tylko tajemnica przedsiębiorstwa. Zagadnienie trudne do opisania w umowie, a często o wielkiej gospodarczej wartości. Z punktu widzenia dostawcy sprzedaż praw do takich elementów może narazić go na brak możliwości zastosowania "wynalezionych" rozwiązań w innych projektach. Czasami rozwiązaniem jest sprzedaż udziałów w prawach. Nieraz licencja. A czasami lepiej nic nie pisać.

11 Przesada z formą, pełnomocnictwa

Mój ulubiony błąd prawniczy - "Wszystkie oświadczenia związane z umową i jej zmiany wymagają formy pisemnej pod rygorem nieważności". Tyle, że w praktyce komunikacja między stronami jest albo ustna, albo poprzez pocztę elektroniczną. Kierownicy projektu podejmują dziesiątki decyzji de facto zmieniających umowę - w tym przesunięcia produktów, zmiana terminów, zmiana specyfikacji, całe zarządzanie zmianą wg zasad ITIL. Z reguły nie są oni formalnie do tego upoważnieni, więc nawet jak przez przypadek zachowają formę pisemną, i tak nie wywołuje to skutków. A potem w sądzie udowadniamy, że projekt był prowadzony zgodnie z wolą stron, choć niezgodnie z pisemną umową. Horror.

12 Bezpieczeństwo danych firmowych

Zagadnienia te doceniane są tylko w największych firmach. W ten zakres wchodzą regulacje umowne od określenia zasad dysponowania tajemnicą przedsiębiorstwa i dostępu zdalnego, po przepisy dotyczące tajnych kancelarii, czy świadectw bezpieczeństwa przemysłowego. Tak samo ważne są kwestie danych osobowych. Jest to obszar, który bezwzględnie w każdej umowie zasługuje na dokładną analizę i precyzyjne zapisy, zamiast standardowych formułek, często zresztą bezskutecznych.

13 Zbytnia wiara w umowę

Część moich klientów wymaga opracowania bardzo restrykcyjnych umów. Polityka taka zdaje się wadliwa co najmniej z dwóch powodów - po pierwsze, jak przesadzimy z restrykcjami (np. surrealnie wysokimi karami umownymi), to cały wysiłek dostawcy będzie skupiony na tym, aby wykazać, że w ogóle nie było zdarzenia lub nie było ono zawinione. To eskaluje konflikt, zamiast służyć rozsądnemu uregulowaniu wyrządzonych szkód.