Firmy IT dążą do zminimalizowania ryzyka prowadzenia działalności konkurencyjnej przez byłych pracowników. Jakie obowiązują w tym względzie regulacje prawne?

Migracja pracowników w firmach IT jest powszechną praktyką. Niektórzy nie kryją wręcz tego, że realizacja konkretnego projektu ma pomóc w znalezieniu atrakcyjniejszej posady. Pojawia się więc obawa, że doświadczenia zdobyte w trakcie realizacji konkretnego rozwiązania będą wykorzystane w działalności konkurencyjnej wobec byłego pracodawcy. Obawy potęguje fakt ponoszenia kosztów wyspecjalizowania pracownika (szkolenia, certyfikaty), obliczonych na długoterminową współpracę. Jak więc zabezpieczyć się przed działalnością konkurencyjną pracownika?

Czego nie wolno pracownikowi

Potencjalnych metod jest kilka. Wszystko zależy od tego, czy chodzi o zatamowanie konkurencji jeszcze podczas trwania stosunku pracy, czy też po zakończeniu współpracy. W obu przypadkach kodeks pracy przewiduje możliwość zawarcia umów o zakazie konkurencji.

Punktem wyjścia jest art. 101 kodeksu pracy zakładający, że "w zakresie określonym w odrębnej umowie, pracownik nie może prowadzić działalności konkurencyjnej wobec pracodawcy, ani też świadczyć pracy w ramach stosunku pracy lub na innej podstawie na rzecz podmiotu prowadzącego taką działalność". Sytuacja taka rozbudza oczekiwania pracodawców. Tyle że wskazanie na ogólny zakaz działalności konkurencyjnej w umowie może okazać się chybione.

Strony powinny dążyć do sprecyzowania aktywności, której nie będzie podejmować informatyk. W przeciwnym razie nie obejdzie się bez sporu sądowego, bo profil działalności firm IT jest z reguły niezwykle szeroki. Tym samym, zakaz konkurencji wyeliminowałby niemal całkowicie aktywność pracownika, a na to nikt nie wyrazi zgody. Zresztą, w przypadku informatyki problemy można mnożyć. Dla przykładu, wątpliwe jest, że programowanie i konsultacja w zakresie programowania to działalność bezpośrednio konkurencyjna. Dochodzi do tego wątpliwość, czy ogólnikowo ujętym zakazem konkurencji programisty będzie objęte programowanie, dotyczące zupełnie innego sektora rynku niż miało to miejsce u poprzedniego pracodawcy. W przytoczonych sytuacjach, z reguły zakazu nie będzie naruszać np. prowadzenie szkoleń z zakresu programowania. Istotą umów o zakazie konkurencji nie jest bowiem całkowite wyeliminowanie informatyka z zawodu.

Nie zawsze pomysł zawarcia klauzuli o zakazie konkurencji pojawia się już przy przyjęciu pracownika. Można jednak temu zaradzić. Z perspektywy przepisów prawa nie ma znaczenia, czy zakaz taki zostanie wprowadzony w tekst pierwotnej umowy o pracę, czy też porozumienie w tym względzie będzie zawarte z zatrudnionym już informatykiem.

Swoboda kontraktowania przewiduje możliwość zagwarantowania pracownikom dodatkowych profitów z tytułu zawartej umowy o zakazie konkurencji. Praktycznie rzecz biorąc, przypadki takie będą należeć do rzadkości, a informatyk zadowoli się tylko swoim zasadniczym wynagrodzeniem. Z drugiej jednak strony, dostrzegalna jest tendencja do wzmacniania interesów pracodawcy. Nie chodzi tylko o możliwość zwolnienia osoby, która naruszy zakaz konkurencji. Dotkliwą sankcją za naruszenie takiej klauzuli jest obowiązek zapłaty kary umownej przez pracownika. Warto dodać, że niektórzy pracodawcy korzystają z dodatkowych instrumentów prawnych, proponując zawarcie umów zastrzegających karę umowną na wypadek zwolnienia się pracownika przed zakończeniem projektu. Nie jest to czysta umowa o zakazie konkurencji, a jedynie dodatkowe zabezpieczenie realizacji zleconych prac. Można mieć wątpliwości, czy takie klauzule są w pełni skuteczne. Zwłaszcza, gdy wysokość ewentualnej kary umownej - głównie dla osiągnięcia celu psychologicznego wobec pracownika - przybiera monstrualną wielkość.

Czego nie może były pracownik

Dla wielu najistotniejsze jest jednak ograniczenie działalności konkurencyjnej byłego pracownika. Kodeks pracy zakłada możliwość umówienia się co do zakazu działań konkurencyjnych po zakończeniu współpracy. Dotyczy to głównie sytuacji, w których pracownik miał dostęp do informacji, których ujawnienie może narazić pracodawcę na szkodę. W istocie chodzi o know-how, np. wewnętrznie opracowane zasady audytu, reguły dotyczące zapewnienia kompatybilności oprogramowania. Umowa taka musi spełniać następujące warunki: określać czas trwania zakazu konkurencji oraz wysokość odszkodowania należnego pracownikowi z tego tytułu. W tym ostatnim przypadku, odszkodowanie nie może być niższe od 25% otrzymywanego wynagrodzenia.

Zakaz konkurencji po ustaniu stosunku pracy nie będzie więc nigdy nieodpłatny. W orzecznictwie sądowym panuje pogląd, że jeśli umowa nie zawiera wysokości odszkodowania, w grę będzie wchodzić wspomniane 25% płacy. Kontrakt taki wygasa nie tylko po upływie terminu jego trwania, lecz także w przypadku, gdy były pracodawca nie przekazuje ustalonego odszkodowania. Zależnie od woli stron, należność jest wypłacana bądź jednorazowo, bądź w ratach. Jeśli nie sprecyzowano konkretnych terminów, wypłaty powinny następować co miesiąc. Tutaj także trzeba zadbać o sprecyzowanie zakresu ograniczeń nakładanych na byłego pracownika. Wątpliwe jest, że ogólnie sformułowana umowa obejmie również profil działalności pracodawcy, który nie był wykorzystywany w chwili zakończenia współpracy.

Własne pomysły

Inną kwestią jest dopuszczalność korzystania z efektów pracy u poprzedniego pracodawcy podczas tworzenia nowych projektów. Chodzi głównie o zakres majątkowych praw autorskich do oprogramowania, a co za tym idzie, swobodę programisty w przenoszeniu własnych rozwiązań na nowe realizacje. Paradoksalnie, były pracownik nie ma całkowitej swobody w korzystaniu z efektów swojej dotychczasowej pracy.

Prawo autorskie przewiduje niezmiernie szeroki zakres majątkowych praw autorskich do oprogramowania, a więc i reprodukcji fragmentów kodu, zaś prerogatywy te przysługiwać będą z reguły poprzedniemu pracodawcy. Korzystanie z efektów własnych pomysłów po przejściu do nowej firmy jest więc ograniczone. Nie chodzi jednak o funkcje aplikacji, które nie będą objęte monopolem autorskim. W praktyce dochodzi do tego konieczność rozróżnienia między zdolnościami programisty, czy też stylem programowania, a chronionymi prawem autorskim fragmentami kodu. Zwłaszcza w przypadku prostych technik programowania mogą pojawiać się podobieństwa między kolejnymi rozwiązaniami tego samego autora.