Jak prawnie zabezpieczyć swoje oprogramowanie przed uzależnieniem od jego dostawcy lub jego nielojalnością?

Rozwój usług i produktów opartych o przetwarzanie danych, dostępność usług programistycznych na rynku i dostępność ceny, jaką płaci się za tworzenie oprogramowania sprawia, że coraz więcej podmiotów gospodarczych, w tym tych mniejszych, decyduje się na zamówienie oprogramowania dedykowanego, czyli oprogramowania szytego przez programistów na miarę, według zapotrzebowania klienta.

Zamówienie takiego oprogramowania, oprócz oczywistej zalety jaką jest uzyskanie narzędzia dostosowanego do zindywidualizowanych procesów biznesowych lub produktów klienta, jest związane również z zagrożeniami prawnymi z którymi trzeba się zmierzyć. Jest to istotne tym bardziej, im bardziej oprogramowanie będzie wpływało na krytyczne operacje przedsiębiorstwa i będzie niezbędne do kontynowania działalności gospodarczej. Poniżej wskazuję kilka takich zagrożeń.

 

Czy zawsze można żądać przeniesienia praw autorskich do programu komputerowego ?

Rosnąca w Polsce świadomość prawna przedsiębiorców sprawia, że nie trzeba już tłumaczyć podstawowej różnicy pomiędzy przeniesieniem autorskich praw majątkowych do oprogramowania, a licencją na korzystanie z tego oprogramownia. Przedsiębiorcy w ramach tworzenia dla nich dedykowanego oprogramowania intuicyjnie zażądają od software house’a trwałego przeniesienia praw autorskich do powstałego za ich pieniądze programu komputerowego. Co jednak w przypadku, gdy takie przeniesienie praw autorskich nie jest z prawnego lub gospodarczego punktu widzenia możliwe w całości ?

Trzeba bowiem kalkulować, że tworzone oprogramowanie często jest złożonym systemem, którego poszczególne elementy mają różny status prawny i gospodarczy. Część powstałego oprogramowania rzeczywiście powstanie na indywidualne zamówienie klienta i definitywny transfer praw autorskich do takiego modułu nie będzie stanowił problemu. W ramach uzyskanego oprogramowania można jednak otrzymać również moduły uniwersalne, których software house nie zechce się wyzbyć (lub wyzbycie wiązałoby się z nieakceptowalnymi dla klienta kosztami) w ramach definitywnego transferu praw autorskich, ponieważ stanowią one dla niego uniwersalne narzędzia do tworzenia różnych programów komputerowych. Mogą istnieć też moduły, których software house nie stworzył, w szczególności narzędzia licencjonowane przez niego od osób trzecich na zasadach licencji komercyjnych lub licencji typu open source.

Co zatem w takim wypadku ? Przedsiębiorca zamawiający takie złożone oprogramowanie  powinien w umowie z softwarehouse’m niewątpliwie zabezpieczyć swoje interesy związane z integralnością i możnością rozwoju oprogramowania. Można i należy to zrobić na kilka sposobów. Po pierwsze, jeśli techniczne jest to możliwe, to należy w umowie z software house ustalić, że dedykowane przedsiębiorcy moduły oprogramowania powinny stanowić samodzielny produkt, którego klient może używać na zasadzie własności prawnoautorskiej, bez konieczności korzystania z pozostałych modułów, do których nie uzyska praw autorskich. Po drugie, należy w umowie precyzyjnie zakreślić warunki licencji  na korzystanie z modułów – narzędzi własnych software house’a,  co do których przedsiębiorca nie uzyska definitywnego transferu praw autorskich. Mowa tu o takich warunkach jak przykładowo: czas trwania licencji, możliwości wypowiedzenia umowy licencyjnej (możliwie długie okresy wypowiedzenia), prawo do sublicencjonowania takich modułów i prawo ich aktualizacji i modyfikowania w ramach uzyskania zezwolenia na wykonywanie praw zależnych do stworzonego oprogramowania. Po trzecie, trzeba w umowie ustalić, że oprogramowanie zostanie stworzone w taki sposób, że ewentualne ograniczenia prawne w zakresie korzystania z  modułów oprogramowania licencjowanego przez software house od osób trzecich na zasadzie licencji komercyjnych i licencji typu open source nie będą stanowiły technicznej przeszkody do aktualizacji i rozwoju oprogramowania jako całości.

 

Vendor lock in czyli jak zmusić klienta aby wrócił do dostawcy oprogramowania  

Software house’y tworzące oprogramowanie raczej niechętnie dzielą się swoją wiedzą na temat tworzonego oprogramowania i często oczekują, że oprogramowanie takie będzie korygowane, aktualizowane i rozwijane przez nie same, oczywiście za stosowną do okoliczności stawkę wynagrodzenia. Takie podejście jest oczywiście korzystne z pozycji software house’a, który w praktyce zamyka nabywcy oprogramowania drogę do jego rozwoju we własnym zakresie lub przy pomocy innych software house’ów.  Wiedza na temat powstałego oprogramowania i klucz do jego rozwoju lub aktualizacji czy naprawy są natomiast zaszyte w kodzie źródłowym. Kod źródłowy, czyli treść programu komputerowego napisana w danym języku programowania, która w przeciwieństwie do kodu wynikowego  „czytanego” przez komputer może być w racjonalnym nakładzie czasowym zinterpretowana przez programistę  tak, aby ten nauczył się jak działa oprogramowanie, zrozumiał jego strukturę, aby móc naprawić pojawiające się błędy oprogramowania, zaktualizować je lub rozwinąć oprogramowanie w kierunku pożądanym przez klienta.

Zatem zasadniczo elementem każdej umowy na stworzenie dedykowanego oprogramowania i przeniesienie do niego praw autorskich powinno być zobowiązanie co do wydanie kodu źródłowego, do czego zazwyczaj software house trzeba przymusić. Umowne zobowiązanie do wydania kodu źródłowego jest konieczne, bowiem taki obowiązek nie wynika ani z przepisów prawa autorskiego, ani z branżowych zwyczajów. Wydanie kodów źródłowych nie jest też niezbędne do eksploatacji oprogramowania jako takiego. Zresztą  podejście co do konieczności umownego uregulowania kwestii wydania kodu źródłowego popiera skromne orzecznictwo sądowe (Wyrok Sądu Apelacyjnego w Warszawie – I Wydział Cywilny z dnia 18 września 2014 r. I ACa 315/14).

Co ryzykujemy nie mając kodów źródłowych do własnego oprogramowania ? Będzie to oczywiście ścisłe związanie się z dostawcą oprogramowania (vendor lock in), który mając na wyłączność kod źródłowy i wiedzę jak powstało oprogramowanie będzie dyktował warunki co do jego aktualizacji i rozwoju.

Jak zatem opisać w umowie wydanie kodu źródłowego ? To pytanie, na które warto sobie odpowiedzieć nie tylko z prawnikiem ale też z programistą, którego zadaniem będzie odbiór i ewentualny audyt tworzonego oprogoramowania. Na pewno w ramach postanowienia o wydaniu  kodu źródłowego warto wskazać cel takiego zabiegu, a więc umożliwienie odbiorcy oprogramowania samodzielne jego zrozumienie i poddania modyfikacjom. Warto też wskazać jak Strony rozumieją, czym jest kod źródłowy, a także jakie narzędzia powinny być wydane wraz z kodem źródłowym, aby możliwe było jego prawidłowe wykorzystanie (np. opis procedury kompilacji, lista narzędzi do kompilacji,  komentarze i instrukcje do kodu źródłowego sporządzone przez programistę będącego twórcą oprogramowania, biblioteki danych niezbędne do edytowania oprogramowania).

Czasami zdarza się, że software house nie jest skory do wydania kodu źródłowego. W takim wypadku pomocna może okazać się konstrukcja depozytu kodu źródłowego, w ramach której strony umownie uzgadniają, że dana osoba trzecia (notariusz, kancelaria prawna lub najlepiej wyspecjalizowany podmiot z branży IT który zweryfikuje kompletność wydanego kodu źródłowego i dodatkowych narzędzi) będzie przechowywała kod źródłowy i wyda go nabywcy oprogramowania w odgórnie ustalonych przypadkach, np. w przypadku upadłości lub likwidacji softwarehouse’u lub w wypadku gdy software house nie chce lub nie potrafi naprawić błędów oprogramowania.

 

Ochrona know how ujętego w dedykowanym programie komputerowym

Zlecając tworzenie oprogramowania opartego na know how swojego przedsiębiorstwa należy pamiętać o ograniczeniach w zakresie ochrony prawnoautorskiej programów komputerowych. Zgodnie z art. 74 ust. 2 ustawy o prawie autorskim i prawach pokrewnych idee i zasady będące podstawą jakiegokolwiek elementu programu komputerowego, w tym podstawą łączy, nie podlegają ochronie. Powyższe oznacza, że sam kod źródłowy, interfejs użytkownika, elementy graficzne i dźwiękowe oprogramowania będą chronione prawem autorskim ale co do zasady nie będą nim chronione pomysły na funkcjonalności oprogramowania czy niemającego twórczego charakteru mechanizmy organizacyjne lub obliczeniowe zaszyte w oprogramowaniu (zob. Wyroku Trybunału Sprawiedliwości z dnia 2 maja 2012 r. C-406/10, Wyrok Sądu Okręgowego w Łodzi – I Wydział Cywilny z dnia 7 marca 2014 r. w sprawie o sygn. akt I C 566/12). Jednocześnie dla wielu przedsiębiorców (np. z branży logistycznej czy branży produkcji przemysłowej) rzeczywistą wartość dodaną oprogramowania, decydującą o silnej pozycji konkurencyjnej, będą miały właśnie takie elementy oprogramowania niechronione prawem autorskim.

Pamiętać przy tym należy, że co do zasady nie da się rozszerzyć opisanej powyżej ochrony prawnoautorskiej programu komputerowego ochroną patentową  przewidzianą w polskim i europejskim prawie własności przemysłowej, bowiem programy komputerowe nie mają zdolności patentowej tj. zdolności do bycia patentem. Wyjątkowo, zgodnie z obecną praktyką urzędów patentowych i orzecznictwem, zdolność patentową posiadają jedynie programy komputerowe wywołujące „dalszy efekt techniczny”, tj. programy które skutkują technicznym efektem (skutkiem) w świecie realnym, czyli programy komputerowe mające sprzężenie ze światem realnym. Przykładowo zdolność patentową będzie mieć oprogramowanie komputerowe sprzężone z silnikiem samochodowym, dzięki któremu silnik samochodowy jest bardziej oszczędny lub oprogramowanie usprawniające działanie sieci wentylacyjnej, czy też oprogramowanie komputerowe służące wykrywaniu i korekcji błędów w transmisji danych albo oprogramowanie komputerowe służące do odczytywania głosu. Natomiast takiej zdolności nie będzie miało przykładowo oprogramowania sklepu internetowego służące organizacji i kontroli nad procesem zakupów lub oprogramowanie kojarzące online nabywców i dostawców określonych usług.

Jak zatem chronić swoje know how zaszyte w funkcjonalności czy w mechanizmach obliczeniowych lub organizacyjnych oprogramowania przed nielojalnym dostawcą oprogramowania, który zechce skopiować niepodlegające ochronie prawnoautorskiej pomysły  i „sprzedać” je konkurencji ?  Po za możnością powołania się na przepisy kodeksu cywilnego dotyczące poufności negocjacji, przepisy o ochronie tajemnicy przedsiębiorstwa przewidziane ustawą o zwalczaniu nieuczciwej konkurencji czy ochronę prawną przewidzianą w ustawie o bazach danych  należy tutaj przede wszystkim bazować na solidnej umowie o zachowaniu poufności i zakazie prowadzenia działalności konkurencyjnej zawartej z dostawcą oprogramowania. Umowa taka  powinna dokładnie wskazywać jakie dane są poufne z punktu widzenia przedsiębiorcy zlecającego stworzenie dedykowanego oprogramowania, jak posługiwać się danymi poufnych, a także jak ma wyglądać zakaz prowadzenia działalności konkurencyjnej, polegający na zakazie tworzenia oprogramownia tożsamego z oprogramowaniem dedykowanym, stworzonym według wymagań zamawiającego i na podstawie jego know how.

 

Autor wpisu: 27.04.2023 News Alerty