W 2011 roku, w artykule Czego najbardziej brakuje systemom klasy ERP? pisałem, że nawet, jeżeli wdrażane jest dostępne na rynku standardowe oprogramowanie, co minimalizuje ryzyko uzależnienia od jednego dostawcy, to już zgoda na jego tak zwaną kastomizację (dostosowanie do specyficznych wymagań) natychmiast powoduje efekt zwany ‘vendor lock-in’. Identyczny jak w przypadku oprogramowania dedykowanego opracowanego i dostarczonego przez jego wykonawcę.

Z jednej strony tak zwany ‘vendor lock-in’ krytykują wszyscy klienci, nabywcy systemów ERP (ogólnie oprogramowania), a z drugiej strony godzą się na to w umowach. Jak to robią? Scenariusz jest prosty i częsty:

  1. opisanie wymagań na oprogramowanie w postaci jego idei jego użycia i wykonania (prawo autorskie nie chroni idei),
  2. wybór dostawcy oprogramowania a potem, w umowie, zlecenie mu wykonania analizy przedwdrożeniowej i opracowania projektu i implementacji oprogramowania (prawa majątkowe do całości ma ten dostawca oprogramowana i się go raczej tanio nie pozbędzie),
  3. zgoda na zapis w umowie z dostawcą brzmiący: “wszelkie wartości intelektualne powstałe w toku realizacji umowy przechodzą na dostawcę”.

Od tego momentu w zasadzie pozostaje już tylko podpisywanie bez negocjacji kolejnych umów na rozwój z takim dostawcą i na jego warunkach.

Czy można inaczej inaczej? Można:

  1. podpisać z projektantem umowę na analizę i projektowanie, dostać prawa majątkowe do opracowanego projektu (Opis Techniczny Oprogramowania).
  2. Zawrzeć Opis Techniczny Oprogramowania w zapytaniu ofertowym, wybrać dostawcę i podpisać umowę na dostarczenie oprogramowania zgodnego z Opisem Technicznym Oprogramowania (w tej umowie staje się on Opisem Przedmiotu Zamówienia).
  3. dostawca ten, zgodnie z tą umową, wytworzy oprogramowanie stanowiące utwór zależny (utworem pierwotnym jest Opis Techniczny Oprogramowania), w tej sytuacji dostawca nie ma prawa samodzielnego dysponowania oprogramowaniem, które tak wykonał, w efekcie oprogramowanie to nie zostanie przez tego sprzedawcę, nikomu innemu zaoferowane,
  4. zamawiający ma swój egzemplarz oprogramowania i prawo decydowania o nim, można także w dowolnym momencie zmienić dostawcę/wykonawcę na innego, nowy usługodawca będzie się musiał zapoznać z kodem, lub napisać swoją implementację na bazie otrzymanego aktualnego Projektu Technicznego Oprogramowania (co jest relatywnie szybkie).

Niestety bardzo często na etapie sprzedaży, przed zawarciem umowy, dostawcy mówią: “nie wiążecie się Państwo z nami, bo standardowy software, który oferujemy ma tę zaletę, że możecie Państwo zawsze zmienić firmą wdrażającą, gdyż producent ma rozbudowaną sieć partnerską”. I samo to jest faktycznie prawdą. Jednak po zawarciu umowy okazuje się jednak, że dostawca oprogramowana standardowego mówi: “kastomizacje są nasze i my mamy do nich prawa autorskie majątkowe, więc jesteście Państwo z nami nieodwracalnie związani” co także jest prawdą, o ile ten dostawca sam wykonał analizę i sam zmodyfikował ten standardowy produkt (zrsztą wbrew zaleceniom producentów).

Jak uniknąć ‘vendor lock-in’? Jest tylko jeden sposób: oddzielić analizę i projektowanie od realizacji, i zagwarantować sobie w umowie z projektantem nabycie praw majątkowych do projektu.

Więcej w artykule Ochrona wartości intelektualnych i know-how.

Patrz także kolejny artykuł: Prawo autorskie w projektach IT.

Jarosław Żeliński

Jarosław Żeliński: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.