Exercitation ullamco laboris nis aliquip sed conseqrure dolorn repreh deris ptate velit ecepteur duis.
Exercitation ullamco laboris nis aliquip sed conseqrure dolorn repreh deris ptate velit ecepteur duis.
W ostatnich latach w branży IT można zaobserwować rosnącą popularność tzw. pozapracowniczych form zatrudniania programistów (np. umów o dzieło lub umów o świadczenie usług). Zainteresowanie takimi formami współpracy istnieje zarówno po stronie pracodawców, którzy dzięki ich zastosowaniu mogą optymalizować koszty, jak również u programistów, którym formy te zapewniają większą elastyczność współpracy oraz wyższe dochody. Poniżej przedstawione zostały istotniejsze zagadnienia związane z tego typu umowami.
Sporządzając umowę, na której ma być oparta współpraca bądź analizując wzór takiej umowy dostarczony przez kontrahenta należy przede wszystkim dobrze zidentyfikować charakter prac, jakie mają być na jej podstawie wykonywane a następnie ustalić, jaki rodzaj umowy będzie w danym przypadku najodpowiedniejszy. Przykładowo, umowa o dzieło będzie właściwą formą dla jednorazowej współpracy, która ma na celu osiągnięcie konkretnego efektu, stanowiącego pewną zamkniętą całość (np. stworzenie aplikacji mobilnej). Z kolei, przy długotrwałej współpracy, podczas której firma informatyczna nie wyznacza programiście określonego rezultatu lecz jest zainteresowana wykonywaniem przez programistę określonych czynności, lepszym rozwiązaniem będzie umowa o świadczenie usług programistycznych, do której zastosowanie znajdą przepisy Kodeksu cywilnego o zleceniu. Specyficznym przypadkiem jest tzw. „umowa ramowa”, która z jednej strony ustanawia pomiędzy stronami stosunek o charakterze ciągłym, z drugiej jednak dzieli współpracę na mniejsze „odcinki”, których realizacja zależna jest od złożenia przez firmę informatyczną konkretnego zamówienia.
Bardzo częstym błędem spotykanym w umowach z programistami jest niewłaściwe opisanie przedmiotu umowy. Zapis umowny, zgodnie z którym programista zobowiązuje się ogólnie do świadczenia usług informatycznych bądź programistycznych bez szczegółowego określenia ich zakresu jest ryzykowny dla obydwu stron. Zapis taki pozostawia bowiem zbyt dużo miejsca na interpretację i spory dotyczące wzajemnych obowiązków stron. Przy umowie nakierowanej na efekt (np. stworzenie aplikacji lub jej części), za celowe należy uznać odwołanie się do dokumentacji technicznej zawierającej wymogi oraz specyfikację planowanych prac. Przy stałej współpracy stron pożądanym jest z kolei wymienienie konkretnych zadań jakie zobowiązany będzie realizować programista. Istotne jest przy tym, aby w umowie konsekwentnie posługiwać się przyjętymi wcześniej pojęciami (np. użytymi w dokumentacji technicznej). Nawet najlepszy opis prac nie uchroni nas bowiem przed sporem, jeżeli w umowie pojawi się chaos terminologiczny.
Wybór modelu wynagrodzenia powinien być determinowany przyjętymi przez strony zasadami współpracy. Przykładowo, jeżeli strony ustalają, że przedmiotem umowy ma być świadczenie przez programistę prac w ustalonym wymiarze czasu, to w większości przypadków właściwym modelem będzie wynagrodzenie ryczałtowe (tzw. fixed price). Przy pracach incydentalnych, bardziej właściwy wydaje się model time&material, zakładający dokonywanie rozliczeń pomiędzy stronami na podstawie rzeczywistego czasu pracy programisty. Problemy mogą pojawić się przypadku, gdy przedmiotem umowy jest realizacja określonego projektu, np. stworzenia nowej funkcjonalności programu. W takiej sytuacji wybór pomiędzy modelem fixed price a time&material nie jest oczywisty i może okazać się kością niezgody pomiędzy firmą informatyczną a programistą. W pewnych bowiem przypadkach konkretny model może być korzystniejszy dla jednej ze stron umowy.
Jedną z najistotniejszych kwestii związanych z realizacją projektu informatycznego jest odpowiednie określenie zakresu, w jakim programista udziela firmie informatycznej uprawnień do utworów stworzonych na podstawie umowy. Podpisując umowę należy przede wszystkim zwrócić uwagę na to, czy na jej podstawie dochodzi do przeniesienia autorskich praw majątkowych do utworów czy jedynie do udzielenia licencji. W pierwszym przypadku firma informatyczna uzyska wyłączne prawa majątkowe do utworów na określonych polach eksploatacji. Oznacza to, iż programista nie będzie mógł z utworu korzystać (co do zasady) ani udzielić na niego licencji lub przenieść autorskich praw majątkowych na rzecz innych podmiotów. W przypadku udzielenia licencji sytuacja jest odmienna. Wówczas to firma informatyczna będzie mogła korzystać z utworu w sposób ściśle określony. Programista natomiast zachowa swoje prawa do utworu, w szczególności będzie mógł je przenieść na inną osobę a w przypadku udzielenia licencji niewyłącznej, będzie również posiadał prawo do udzielenia licencji innym jeszcze podmiotom. W związku z powyższym, oczywistym staje się, że interesy programisty i firmy informatycznej w zakresie udzielenia uprawnień do korzystania z utworów będą z reguły sprzeczne – firma informatyczna będzie dążyła do uzyskania jak najszerszych uprawnień do utworów zaś programiście będzie zależało na utrzymaniu tych uprawnień przy sobie.
W tym miejscu warto również zasygnalizować kwestię osobistych praw autorskich. Prawa te chronią więź twórcy z utworem, są nieograniczone czasowo oraz nie podlegają zbyciu ani zrzeczeniu się. Przykładem takiego prawa jest prawo do decydowania o pierwszym udostępnieniu utworu. Brak uregulowania kwestii praw osobistych może prowadzić do wielu problemów. Przykładowo pomiędzy stronami może zawiązać się spór co do sposobu korzystania z utworu przez firmę informatyczną lub co do tego, jak utwór ma zostać oznaczony. Mimo niezbywalności osobistych praw autorskich istnieją konstrukcje prawne służące optymalnemu wyważenie interesów obu stron umowy.
Klauzula o zakazie konkurencji jest elementem wielu umów zawieranych pomiędzy firmą informatyczną a angażowanymi przez nią programistami. Jej głównym celem jest zabezpieczenie interesów firmy informatycznej na wypadek nielojalnego zachowania programisty lub działań podejmowanych przez klientów lub konkurentów tej firmy. Przykładowo klient firmy informatycznej może stwierdzić, iż lepszym rozwiązaniem będzie dla niego zatrudnienie u siebie programistów oddelegowanych do realizacji konkretnego projektu bez pośrednictwa tej firmy. W takim wypadku odpowiednio skonstruowana klauzula o zakazie konkurencji istotnie ograniczy ryzyko działań takiego klienta nakierowanych na pozyskanie programistów firmy informatycznej. Z drugiej jednak strony zapisy wspomnianej klauzuli mają też niebagatelne znaczenie dla samego programisty. W skrajnych przypadkach może on bowiem doznać istotnego ograniczenia możliwości funkcjonowania na rynku po rozwiązaniu umowy z firmą informatyczną.
Konkretna klauzula o zakazie konkurencji powinna być zweryfikowana nie tylko pod względem tego, czy należycie waży interesy obu stron. Analizy wymaga także to, czy postanowienia o zakazie konkurencji nie zawierają „luk” umożliwiających jej łatwe obejście oraz czy jej postanowienia będą zgodne z obowiązującymi przepisami prawa a tym samym wiążące dla stron.
Celem niniejszego artykułu było zasygnalizowanie obszarów wymagających szczególnej uwagi przy podpisywaniu umów dotyczących współpracy programisty i firmy informatycznej. Kwestie poruszone powyżej nie wyczerpują jednak całości problematyki z tym związanej. Dobra umowa wymaga bowiem uwzględnienia szeregu przesłanek biznesowych i prawnych, jak również okoliczności faktycznych konkretnego przypadku.