Ważne jest określenie granic swobody pracy programistów, aby uniknąć sporów z byłym pracodawcą na tle majątkowych praw autorskich.

Ochrona oprogramowania komputerowego jawi się jako dość restrykcyjna, o czym świadczy chociażby konieczność autoryzowania niemal każdego aktu reprodukcji fragmentu bądź całości aplikacji [art. 74 ust. 4 ustawy]. Nie dziwi więc, że powstają pytania o możliwość korzystania z wypracowanych wcześniej rozwiązań wyrażanych w kodzie źródłowym. Analiza przepisów prawa autorskiego prowadzi do wniosku, że swoboda powielania finalnych wersji własnych pomysłów jest ograniczona. Twórca - o ile łączy go z firmą umowa o pracę, a nie o dzieło bądź zlecenia - zawsze będzie dysponował uprawnieniami autorskimi, lecz prawa majątkowe służyć będą pracodawcy [art. 74 ust. 3 ustawy]. Dotyczy to oprogramowania powstającego w wyniku wykonywania obowiązków pracowniczych - jeśli nie zawarto odmiennej klauzuli umownej.

Jest to rozwiązanie o tyle kłopotliwe, że pomocą przy programowaniu służą standardowe narzędzia, a w przypadku programowania obiektowego wyłaniają się "uniwersalne" klasy obiektów. Sprawia to, że poszczególne fragmenty kodów źródłowych tworzonych przez tego samego informatyka mogą być niemal identyczne. Mamy tu do czynienia z wykorzystywaniem nabytych umiejętności, do których były pracodawca nie może rościć sobie praw. Na etapie tworzenia oprogramowania nie ma możliwości wyrażania kreatywności tak jak w przypadku np. muzyki. Dobór metod rozwiązania konkretnego problemu IT wymaga znajomości aspektów technicznych. Jak więc uchronić się od zarzutów naruszenia majątkowych praw autorskich, wysuwanych przez byłego pracodawcę?

W pierwszym rzędzie prawo autorskie nie chroni umiejętności "dopasowywania" elementów IT, łatwości sięgania po zaawansowane języki programowania. Jeśli były pracodawca "zainwestował" w programistę szkoląc go, może zrekompensować sobie koszty wyłącznie przez klauzulę zakazu pracy u konkurencji po ustaniu stosunku pracy [mającą charakter odpłatny]. Jej zapisy muszą być precyzyjne. Zaznaczyć należy, że umowy takie w niektórych przypadkach można ominąć, zatrudniając programistę na stanowisku konsultanta w zakresie IT. Ponadto, niezrealizowane projekty IT, przedstawione byłemu pracodawcy w formie pomysłów, mogą być bez przeszkód wykorzystywane w nowym miejscu pracy.

Zbieżność komendnie wystarczy

Inna kwestia to zbliżenia strukturalne pomiędzy fragmentami kodów źródłowych. Na pozór mamy do czynienia z naruszeniem prawa do reprodukcji programu. Jednakże biorąc pod uwagę funkcjonalny charakter programów i specyfikę części z języków programowania, nie zawsze będziemy mieli do czynienia z taką sytuacją. Po pierwsze, nie zawsze możliwy będzie dostęp do samego kodu "podejrzanego" programu. Opieranie przekonania o naruszeniu majątkowych praw autorskich wyłącznie na porównaniu funkcji dwóch aplikacji nie będzie skuteczne w sądzie. Zresztą, nawet jeśli w kodzie wykorzystano te same komendy, to ich zapis nie musi być przedmiotem ochrony prawa autorskiego. Dzieje się tak głównie za sprawą tego, iż programista w wielu przypadkach nie ma dowolności w doborze komend, sposobów rozwiązania problemu technicznego. W amerykańskim prawie sformułowano wręcz teorię, w myśl której jeśli określony algorytm można wyrazić tylko w jeden sposób, to nie można w tym zakresie doszukiwać się ochrony prawno-autorskiej.

Zdarzyć się może ponadto, iż poszczególne fragmenty kodu przewijają się we wcześniejszych i kolejnych opracowaniach tego programisty. Dochodzi do tego możliwość sporządzania niektórych z takich rozwiązań na podstawie kontraktów odmiennych aniżeli umowa o pracę. Jeśli wcześniej w pracy programisty pojawiły się elementy chronione prawem autorskim, to ich pozyskanie przez pracodawcę wyłącznie z uwagi na przeniesienie tych fragmentów do kolejnego rozwiązania IT jest wielce wątpliwe. Prawo autorskie wspomina o nabyciu praw majątkowych do programów stworzonych w wyniku wykonywania obowiązków pracowniczych, a nie o uzyskiwaniu takich praw do wcześniej stworzonych zrębów aplikacji. Jest to o tyle istotne, że ochronie prawnej może podlegać też część programu. Niewykluczone staje się w takiej sytuacji "rozczłonkowanie" praw do programu w wymiarze ekonomicznym - częściowo będą one przysługiwać informatykowi, a częściowo zatrudniającej go firmie. Jeszcze większe problemy pojawią się, gdy wcześniej programista udzielił licencji na korzystanie z utworu, stworzonego na mocy kontraktu o dzieło. Zarówno poprzedni, jak i kolejni pracodawcy nie uzyskają w tym zakresie automatycznie żadnych praw majątkowych.

Współdziałające programy

Odejście do nowego pracodawcy może być sposobem zdyskontowania sukcesu aplikacji stworzonej w poprzedniej firmie. Dotyczy to w szczególności realizowania "nakładek" współdziałających z podstawowymi programami. W wielu przypadkach dojdzie więc do stworzenia utworów zależnych w rozumieniu prawa autorskiego, gdzie na rozpowszechnianie ich wymagana jest zgoda twórcy. Sam fakt, iż byłemu pracodawcy przysługują prawa autorskie nie będzie więc tu zawsze problemem.

Nie ma mowy o naruszeniu praw autorskich w przypadku inspiracji byłych pracowników projektami realizowanymi u dotychczasowego pracodawcy. W grę wchodzi tu wyłącznie ochrona tajemnicy - pod warunkiem odpowiedniego zabezpieczenia takich informacji przed dostępem osób postronnych. Dokument, do którego mają dostęp wszystkie osoby w firmie, w tym personel czysto usługowy, trudno uznać za prawidłowo chronioną tajemnicę handlową.

Jak widać, odejście z pracy w pewien sposób ogranicza dalszą swobodę twórczą programisty. Musi się on liczyć z tym, iż nie będzie w stanie powielać części opracowanych fragmentów kodu, co jest istotne w przypadku migracji do bezpośredniej konkurencji. Z drugiej strony, nigdy nie doprowadzi to do niemożności korzystania z umiejętności nabytych w trakcie zatrudnienia.