Najpierw kilka cytatów z poprzednich moich wpisów:
Pewien lider na rynku dostawców systemów ERP, ma zapis w umowie mówiący, że przejmuje prawa autorskie do całości pomysłów i kodu (funkcjonalności) jaki powstanie podczas prac z klientem nad dostosowaniem dostarczanego systemu ERP (czyli tak zwana kastomizacja). Czyli know-how zamawiającego idzie do konkurencji ? firma ta chwali się na rynku, że ma referencyjne branżowe rozwiązania ?
Byli bardzo zaskoczeni (i wściekli) gdy dowiedzieli się, że zgodnie z umową analizę i projekt implementacji (model PIM) nowych funkcjonalności, których nie ma ich ERP robię ja. Ich tłumaczenie, że tylko oni maja wiedzę by to robić bo to ich ERP było nie do obrony: pokazałem im opis ich własnego systemu, jego metodyki wdrożenia i informację, że jest wykonany znanym narzędziem obiektowym i w znanej technologii, i że projekt jaki ode mnie dostaną będzie wystarczający i prawidłowy by go zaimplementować w tym ERP. Niestety, tu nie przejęli wiedzy i pomysłów zamawiającego. Tak się da zrobić, trzeba nie dać się szantażować swojemu własnemu dostawcy. (za Prawo autorskie, szpiegostwo przemysłowe i projektowanie.)
Analiza biznesowa i i dokumentacja pomysłu (bo czym innym jest specyfikacja wymagań na oprogramowanie, to zapis naszego pomysłu na system) projektu, efekt naszej ciężkiej pracy, wypracowywania latami modelu biznesowego, własnych metoda zarządzania, tego co nie raz stanowi klucz przewagi konkurencyjnej.
Jeżeli prace te wykona dostawca oprogramowania z zasady staje się posiadaczem tego pomysłu. (za Kilka słów o kosztach analizy przedwdrożeniowej i prawie autorskim).
Tak więc problem jest i jest o czym pisać. Nie raz na spotkaniach i konferencjach jestem wręcz atakowany za powyższe “herezje”, jednak ataki producentów i dostawców maja uzasadnienie: mam rację. Większość tego typu problemów nie ogląda światła dziennego bo dostawcy wymuszają umowy o poufności zatajając wszelkie szczegóły swoich umów, więc trudno mi podawać jakieś przykłady, nawet jeśli o nich wiem mogę tylko opisać “zjawisko” co daje moim oponentom argument: “proszę podać jakiś konkretny przykład wystąpienia problemu”. No i mamy :):
Do sądu trafiła sprawa obsługi technicznej systemu ERP firmy Infor od ponad dekady wspierającego działalność amerykańskiego koncernu 3M. Spór jest wynikiem podjętej dwa lata temu decyzji o przekazanie opieki nad systemem zewnętrznej firmie. Zdaniem przedstawicieli koncernu Infor takie działanie wprost narusza warunki umowy. […] Zdaniem ekspertów spór w dużej mierze wynika z niejednoznaczności zapisów kontraktu, odmiennej interpretacji praw klienta oraz dostawcy systemu, a także konfliktu interesów związanego z wykorzystaniem niezależnych od producenta usług obsługi technicznej oprogramowania. […]
… warto pamiętać, że dostawcy oprogramowania zazwyczaj nie mają żadnych praw względem wprowadzonych przez klientów kastomizacji i modyfikacji systemu pod warunkiem, że nie ingerują one bezpośrednio w kod źródłowy” – podkreśla Ray Wang, właściciel firmy analitycznej Constellation Research. (za Producent systemu ERP chce 20 mln USD zadośćuczynienia od długoletniego klienta).
Nie raz od klientów słyszę, że walka z dostawcę nie ma sensu, ale nie jest to prawda. Na etapie zawierania umowy zależy dostawcy bardzo, i jest to czas (ostatni!) by negocjować. Tak więc po pierwsze warto zadbać o treść uwowy, po drugie zadbać o swój know-how, jak?
Dedykowane dla siebie funkcjonalności należy implementować, ale nie metodą ingerencji w pierwotny kod źródłowy (polecana przez dostawców kastomizacja, ona niestety uzależnia nas potem w 100% od tego dostawcy!) a poza nim, w postaci odrębnego projektu. Nawet jeżeli implementacja będzie miała miejsce w środowisku kupionej aplikacji to jednak nasz jest fragment kodu wytworzony od zera dla nas (jeżeli nie został zaprojektowany przez dostawcę pierwotnego systemu!) .
Czy mam racje? Bardzo prawdopdobne, ze mam:
Yves Bot, Rzecznik Generalny Trybunału Sprawiedliwości UE stwierdził, że funkcjonalność oprogramowania, rozumiana jako zbiór możliwości systemu, a więc usług oferowanych użytkownikom – nie kwalifikuje się do ochrony pod kątem prawa autorskich. “Jeśli przyjąć, że funkcjonalność programu komputerowego jako taka może podlegać ochronie z tytułu prawa autorskiego, to tego typu ochrona mogłaby spowodować powstanie monopolu idei, który zaszkodziłby postępowi technologicznemu i rozwojowi przemysłu” – uważa Yves Bot.
I na to powołują się dostawcy oprogramowania. Zresztą z tym argumentem także sie zgadzam. Jednak chodzi o szzcegóły, o cechy indywidualne:
Jednocześnie podkreśla on, że ochronie z tytułu prawa autorskiego w pełni podlegają mechanizmy, które stanowią bazę dla funkcjonalności oprogramowania. “Ochronie podlegają m.in. algorytmy i formuły, które odzwierciedlają inwencję i są efektem intelektualnej twórczości autora programu komputerowego” – zapewnia Yves Bot. Opinie Rzecznika Generalnego Trybunału Sprawiedliwości UE padły w kontekście sporu sądowego firm SAS Institute oraz World Programming. (za UE: Prawa autorskie nie chronią języków programowania i funkcji oprogramowania).
Tak więc konieczne jest, nie tylko spisanie wymagań, bo to jest jedynie funkcjonalność oprogramowania (patrz powyżej). Należy opracować model logiki czyli algorytmy i formuły co pozwoli zachować je dla siebie.
Ten artykuł (Prawa autorskie …) zawiera dokładny opis jak się chronić.
