SPCG for FinTech (cz. 4) – Nabywanie praw do IP tworzonego dla instytucji finansowej przez zewnętrznych dostawców

SPCG for FinTech (cz. 4) – Nabywanie praw do IP tworzonego dla instytucji finansowej przez zewnętrznych dostawców

Czytaj: 4 min

Poprzedni wpis z cyklu SPCG for FinTech dotyczył nabywania przez instytucję finansową praw do IP tworzonego przez wewnętrzne zespoły. Tym razem skupiamy się na IP nabywanym przez instytucję finansową od zewnętrznych dostawców, a więc na przypadkach, gdy instytucja finansowa nie korzysta z ustawowych ułatwień nabywania praw od osób zatrudnionych na podstawie umowy o pracę.

W niektórych przypadkach nabycie IP od osób trzecich jest bardziej efektywne niż tworzenie go wewnątrz organizacji, zwłaszcza, gdy chodzi o oprogramowanie. Zewnętrzny dostawca może posiadać pracowników o kompetencjach, których w ramach instytucji finansowej jeszcze nie udało się wykształcić albo ich wykształcanie nie jest celowe (specjaliści o wąskich kompetencjach) – tacy pracownicy mogą zostać delegowani do instytucji finansowej w ramach body/team leasingu. Zewnętrzny dostawca może też dysponować gotowym produktem (off the shelf) lub dopiero stworzyć produkt na zamówienie instytucji finansowej – jednak szybciej niż w przypadku, gdyby instytucja chciała stworzyć go samodzielnie. W każdym z tych przypadków absolutnie kluczowe jest precyzyjne ustalenie, na jakich dokładnie zasadach instytucja finansowa będzie z pozyskanego IP korzystać. Czy będzie to licencja, czy nabycie IP oraz jak szeroki zakres będzie miała instytucja finansowa w używaniu kupionego produktu np. rozwijanie go na własną rękę.

Umowy z zewnętrznymi dostawcami

Zasady nabywania praw własności intelektualnej od zewnętrznych dostawców, na przykład software house’u, są analogiczne jak od osób współpracujących z instytucją finansową na podstawie innej umowy niż umowy o pracę (np. umowa zlecenia lub umowa o dzieło). Konieczne jest więc sprecyzowanie materiałów, do których prawa zostaną przeniesione (mogą być one określone w załączniku do umowy lub we właściwych zamówieniach) i zakresu przeniesienia praw – przedmiotowego (wyraża się on przez tzw. pola eksploatacji) oraz terytorialnego. Poza przeniesieniem praw do materiałów dostarczonych przez dostawcę należy też ustalić, czy instytucja finansowa będzie mogła wprowadzać do nich zmiany, a jeśli tak to w jakim zakresie. Przykładowo, zmiany w oprogramowaniu mogą ograniczać się do usuwania błędów, polegać na jego rozbudowie lub wręcz budowie kolejnych wersji programu na bazie wersji dostarczonej przez dostawcę. O ile przeniesienie na instytucję finansową praw do materiałów tworzonych na jej zamówienie przeważnie nie będzie budziło wątpliwości, to przed zawarciem umowy organizacja powinna jeszcze ustalić, czy dostawca będzie na potrzeby współpracy korzystał z wcześniej stworzonego przez siebie IP (tzw. background / existing IP). Rozstrzygnięcie tej kwestii ma szczególne znaczenie w przypadku, gdyby background IP miało zostać włączone do zamówionego rozwiązania, a nie jedynie stanowić narzędzie do jego stworzenia. Takie IP co do zasady pozostaje przy dostawcy (prawa nie są przenoszone na zamawiającego), więc potencjalnie może ograniczać swobodę instytucji w korzystaniu z zamówionego rozwiązania.

Podobnie jak w przypadku usługodawcy świadczącego body- lub team- leasing, także zewnętrzny dostawca powinien na żądanie instytucji finansowej, udostępnić do wglądu umowy z osobami, które faktycznie będą pisały zamówione oprogramowanie. Instytucja finansowa nie nabędzie od dostawcy praw własności intelektualnej w szerszym zakresie niż ten ostatni nabył je od twórców programu. Jednolite zasady przenoszenie praw na dostawcę a następnie na instytucję finansową powinny obejmować wszystkie osoby, które na przestrzeni realizacji projektu będą oddelegowane do zespołu pracującego dla wspomnianej instytucji.

Istotną kwestią umów z zewnętrznymi dostawcami jest odpowiedzialność za wady prawne dostarczonych materiałów np. oprogramowania. Instytucja finansowa ma bardzo ograniczone możliwości ustalenia, czy dostawca faktycznie – tak jak twierdzi – dysponuje pełnią majątkowych praw autorskich do utworów wykonanych w ramach współpracy. Tymczasem, jeśli instytucja będzie z takich materiałów, choćby nieświadomie korzystała, to i tak ponosi odpowiedzialność prawną. Osoba trzecia może domagać się od instytucji finansowej co najmniej zaniechania korzystania z materiałów, do których instytucja nie nabyła całości praw autorskich. W praktyce może to oznaczać przynajmniej czasowe zaprzestanie świadczenia klientom określonych usług i konieczność przeznaczenia środków na szybką „podmianę” spornych elementów na inne (o ile jest to w ogóle możliwe). Umowa powinna więc określać zarówno zasady przystąpienia przez dostawcę do ewentualnego postępowania przeciwko instytucji finansowej, naprawienia szkody, ale też zastąpienia spornych elementów innymi.

Należy też zwrócić uwagę na zasady korzystania z materiałów, do których dostawca „świadomie” nie ma praw autorskich, w szczególności oprogramowania typu open source oraz standardowego oprogramowania licencjonowanego przez osoby trzecie (np. Oracle). Użycie takiego oprogramowania w ramach projektu powinno być ewidencjonowane przez dostawcę a jego zestawienie przekazane instytucji finansowej. Oprogramowanie typu open source jest co do zasady licencjonowane nieodpłatnie przez jego autora (licencja nie jest udzielana przez dostawcę, ale bezpośrednio przez autora programu), ale niektóre licencje open source są w ograniczonym stopniu przydatne dla projektów komercyjnych (np. zakaz komercyjnego użycia, zakaz wprowadzania zmian) albo zawierają postanowienia zobowiązujące do rozpowszechniania programów bazujących na oprogramowaniu open source na takiej samej licencji (tzw. klauzula copyleft). Z kolei w przypadku standardowego oprogramowania dostarczanego przez osoby trzecie ważna może się okazać wysokość wynagrodzenia – rekomendowane jest potwierdzenie, czy będzie je uiszczała instytucja finansowa czy dostawca. Oprogramowanie open source bywa też problematyczne pod kątem bezpieczeństwa (zwłaszcza w przypadku tzw. linkowania dynamicznego). Posługiwanie się materiałami osób trzecich jest standardem w przypadku agencji reklamowych. Są to zarówno materiały z różnego typu baz zdjęć i filmów, ale też materiały, których status należy dopiero potwierdzić (np. fakt wygaśnięcia praw autorskich do fotografii). W umowie dotyczącej akcji marketingowych usług finansowych opartych na rozwiązania FinTech należy więc sprecyzować przynajmniej obowiązek pozyskiwania przez agencję licencji o określonym zakresie.

Body/team leasing

W codziennej pracy wewnętrznych zespołów pracownicy zatrudnieni bezpośrednio przez instytucję finansową oraz osoby delegowane przez usługodawcę świadczącego usług body- bądź team- leasingu mogą wydawać się nieodróżnialne. Z punktu widzenia nabycia IP przez instytucję finansową są to jednak dwie zupełnie różne kategorie pracowników. Do osób zatrudnianych przez usługodawcę stosuje się oczywiście przedstawione w poprzednim wpisie zasady nabywania praw własności intelektualnej, ale działają one na linii pracownik-usługodawca a nie pracownik-instytucja. Prawa do własności intelektualnej stworzonej przez taką osobę muszą być więc najpierw nabyte przez usługodawcę a następnie przeniesione na instytucję finansową. Podmiot świadczący body- lub team- leasing jest więc z punktu widzenia instytucji finansowej, zewnętrznym dostawcą. Zakres przeniesienia przez niego praw na instytucję nie może być oczywiście węższy niż zakres nabycia tych praw przez usługodawcę. Dlatego rekomendowane jest zobowiązanie usługodawcy do uwzględniania w umowach z pracownikami klauzul przeniesienia praw własności intelektualnej o treści zaproponowanej przez instytucję (o ile to możliwe) oraz zapewnienie instytucji finansowej wglądu w treść tych umów.

Tworzenie, nabywanie oraz korzystanie z IP ściśle wiąże się z rozwiązaniami podatkowymi, które w swoich założeniach mają promować tworzenie innowacyjnych rozwiązań technologicznych przez przedsiębiorców. Nie ma znaczenia, czy te rozwiązania będą służyły świadczeniu usług finansowych, czy też innym celom, stąd również instytucje finansowe mogą z nich korzystać.

W następnym artykule z cyklu SPCG for FinTech opiszemy zasady stosowania 50% kosztów uzyskiwania przychodów, ulgi badawczo-rozwojowej oraz ulgi IP BOX.

 

Napisz do autora:

dr Marcin Balicki SPCG

dr Marcin Balicki

adwokat
Senior Associate

Dekompilacja oprogramowania w celu naprawy błędów

Dekompilacja oprogramowania w celu naprawy błędów

Czytaj: 3 min

Legalny użytkownik może dekompilować kod wynikowy oprogramowania na potrzeby naprawy błędów. Taki wniosek płynie z wyroku Trybunału Sprawiedliwości Unii Europejskiej („TSUE”) z dnia 6 października 2021 r. (sygn. C-13/20; „Wyrok”). Nie jest to jednak uprawnienie absolutne. Prawo do legalnej dekompilacji całości lub części oprogramowania jest obarczone kilkoma warunkami, które postaramy się Państwu przybliżyć w niniejszej publikacji.

Tło sprawy – dekompilacja oprogramowania bez zgody uprawnionego

Rozstrzygana sprawa dotyczyła sporu pomiędzy belgijską spółką Top System, oferującą rozwiązania IT oraz belgijskim organem administracji publicznej „Selor”. W ramach wieloletniej współpracy Top System dostarczyło Selor oprogramowanie, które składało się z oprogramowania standardowego „Top System Framework” („TFS”) oraz oprogramowania dedykowanego, skrojonego na potrzeby Selor. Selor korzystało z TFS na podstawie licencji, nie mając jednocześnie dostępu do kodu źródłowego rozwiązania. Z uwagi na pojawiające się błędy oprogramowania TFS, których Top System nie usunęło, Selor samodzielnie dokonało dekompilacji części dostarczonego oprogramowania w celu wyłączenia funkcji, która okazała się wadliwa. W odpowiedzi na zachowanie zamawiającego Top System złożyło skargę, zarzucając Selor naruszenie wyłącznych praw autorskich spółki. W ocenie dostawcy czynność dekompilacji oprogramowania w celu naprawienia jego błędów mogła zostać dokonana jedynie po uzyskaniu uprzedniej zgody uprawnionego z tytułu praw autorskich. Takiej zaś zgody Top System nie udzieliło.

Sprawa trafiła do Sądu Apelacyjnego w Brukseli, który następnie postanowił zwrócić się do TUSE z dwoma pytaniami prejudycjalnymi, tj.:

  1. Czy art. 5 ust. 1 [dyrektywy 91/250] należy interpretować w ten sposób, że zezwala on uprawnionemu nabywcy programu komputerowego na dokonanie dekompilacji całości lub części tego programu, jeżeli dekompilacja ta jest konieczna, aby pozwolić mu na poprawienie błędów mających wpływ na funkcjonowanie tego programu, również w przypadku, gdy poprawka polega na wyłączeniu funkcji zakłócającej prawidłowe funkcjonowanie aplikacji, której program ten jest częścią?
  2. W przypadku udzielenia odpowiedzi twierdzącej na pytanie pierwsze, czy ponadto muszą zostać spełnione warunki określone w art. 6 dyrektywy lub jakieś inne warunki?

Treść wyroku

W ocenie TSUE dekompilacja całości lub części oprogramowania w celu naprawy jego błędów jest dopuszczalna, również bez zgody uprawnionego z tytułu praw autorskich. Taka możliwość wynika z art. 5 ust. 1 Dyrektywy Rady z dnia 14 maja 1991 r. w sprawie ochrony prawnej programów komputerowych („dyrektywa”), zgodnie z którym: „W braku szczególnych przepisów umownych czynności określone w art. 4 lit. a) i b) nie wymagają zezwolenia uprawnionego, jeżeli są konieczne do użycia programu przez uprawnionego nabywcę zgodnie z zamierzonym celem, włącznie z poprawianiem błędów[1].

Takiemu wnioskowaniu nie sprzeciwia się brzmienie art. 6 dyrektywy [2], który reguluje wymogi dekompilacji oprogramowania w celu osiągnięcia interoperacyjności stworzonych niezależenie programów. W ocenie Trybunału oba ww. przepisy są od siebie niezależne i spełnią inne cele. Celem art. 6 dyrektywy jest uregulowanie szczególnego przypadku dekompilacji, tj. dla zapewnienia interoperacyjności programów komputerowych (lex specialis). Natomiast art. 5 ust. 1 dyrektywy wprowadza generalną zasadę, która uprawnia legalnego nabywcę software’u do jego powielania, translacji, adaptacji, porządkowania i modyfikacji, jak też powielania wyników tych działań bez zgody uprawnionego, o ile jest to konieczne do korzystania z oprogramowania zgodnie z jego celem (lex generalis).

Dekompilacja oprogramowania w celu naprawy jego błędów nie jest nieograniczona. Nabywca oprogramowania (w tym przypadku licencjobiorca) powinien spełnić następujące wymogi:

  • dekompilacja jest przeprowadzona na potrzeby błędów rozumianych jako wady mające wpływ na program komputerowy, które są przyczyną jego niewłaściwego działania, oraz uniemożliwiają korzystanie z oprogramowania w sposób zgodny z zamierzonym celem;
  • dekompilacja musi być „konieczna”, by zapewnić nabywcy oprogramowania możliwość korzystania z produktu zgodnie z jego celem. Jeżeli błąd można naprawić w inny sposób, bez dokonywania dekompilacji, to czynność dekompilacji naruszy prawa wyłączne osoby uprawnionej (np. gdy licencjobiorca dysponuje kodem źródłowym rozwiązania);
  • nabywca oprogramowania nie może wykorzystać wyników dekompilacji do innych celów niż naprawa błędów.

Niezwykle istotnym dla praktyki (o ile nie najważniejszym) jest spostrzeżenie TSUE, zgodnie z którym strony nie mogą umownie wyłączyć jakiejkolwiek możliwości poprawiania błędów przez legalnego użytkownika. Strony mogą jedynie uregulować umownie zasady korzystania z tego uprawnienia.

Podsumowanie i wnioski dla praktyki

Wyrok ma praktyczne znaczenie zarówno dla dostawców i zamawiających, którzy w ramach relacji umownej uzgadniają zasady dostarczania oprogramowania standardowego, bez kodu źródłowego i bez prawa do modyfikacji oprogramowania. W takim przypadku legalny nabywca ma prawo, bez uprzedniej zgody uprawnionego, do dokonania dekompilacji części lub całości produktu, w celu usunięcia błędów mających wpływ na jego działanie, o ile taka czynność dekompilacji jest konieczna do zapewnienia zgodnego z celem korzystania z oprogramowania.

Strony powinny też pamiętać, że nie jest możliwe wyłączenie prawa legalnego użytkownika do poprawiania błędów oprogramowania. W świetle omawianego Wyroku takie klauzule należy uznać za nieważne. Trybunał dopuszcza jedynie możliwość umownego regulowania zasad korzystania z ww. uprawnienia, przy czym nie wskazuje jak daleko taka regulacja może sięgać. I tu pojawiają się wątpliwości – tj. czy odpłatna umowa serwisowa wyłącza prawo legalnego użytkownika do dokonania samodzielnej dekompilacji w celu usuwania błędów? Tego wątku Trybunał nie rozstrzyga. Niemniej warto mieć na uwadze omawiane orzeczenie TSUE przy konstruowaniu zobowiązań umownych stron w zakresie licencji oprogramowania.

Przypisy:

[1] Na gruncie prawa polskiego odpowiednikiem art. 5 ust. 1 dyrektywy jest art. 75 ust. 1) ustawy o prawie autorskim i prawach pokrewnych.

[2] Na gruncie prawa polskiego odpowiednikiem art. 5 dyrektywy jest art. 75 ust. 2 pkt 3) ustawy o prawie autorskim i prawach pokrewnych.

 

Napisz do autora:

Aleksandra Modzelewska SPCG

Aleksandra Modzelewska

adwokat
Associate

SPCG for FinTech (cz. 3) – Nabywanie praw do IP tworzonego wewnętrznie dla instytucji finansowej

SPCG for FinTech (cz. 3) – Nabywanie praw do IP tworzonego wewnętrznie dla instytucji finansowej

Czytaj: 4 min

We wcześniejszym wpisie z cyklu SPCG for FinTech – Jakie IP powstaje w ramach projektów FinTech – przybliżaliśmy rodzaje IP, jakie powstaje w związku z realizacją projektów FinTech. Natomiast w tym artykule wyjaśnimy, jak uporządkować i „zautomatyzować” nabywanie przez instytucję finansową praw do tego IP, aby uniknąć powstania luk prawnych.

W przypadku skomplikowanych, długoletnich projektów lub bieżącej ich obsługi wkłady poszczególnych pracowników mogą być trudne do uchwycenia – zwłaszcza, gdy trzeba ustalić rolę danego pracownika po upływie kilkunastu miesięcy bądź kilku lat. Kolejne komplikacje rodzi rotacja w zespołach – skontaktowanie się z byłym pracownikiem i nabycie od niego „brakujących” praw własności intelektualnej często jest bardzo trudne. Dlatego rekomendujemy zmapowanie działów i stanowisk związanych z tworzeniem dla instytucji finansowej kluczowego IP a następnie wprowadzenie procedur i wzorów dokumentów tworzących system możliwie bezobsługowego i pełnego nabywania IP powstającego w ramach instytucji. Taki system będzie oczywiście opierał się mechanizmach już obecnych w obowiązujących przepisach, te mechanizmy opisujemy niżej.

Przede wszystkim, nabywanie praw własności intelektualnej do materiałów stworzonych przez zespół wewnętrzny będzie się różniło w zależności od tego, na podstawie jakiej umowy dana osoba współpracuje z instytucją finansową oraz jakie dobro materialne stworzyła. W każdym przypadku prawo przewiduje ułatwienia dla instytucji finansowej w nabywaniu praw do materiałów stworzonych przez współpracownika, ale zakres tych ułatwień będzie różny. Można wyróżnić trzy sytuacje:

  • programy komputerowe stworzone w ramach stosunku pracy;
  • inne niż programy komputerowe utwory chronione prawem autorskim stworzone w ramach stosunku pracy;
  • dobra własności przemysłowej stworzone na ramach stosunku pracy albo współpracy opartej na innych podstawach.

Ustawodawca preferuje zatrudnienie w oparciu o umowę o pracę, czemu daje wyraz w przepisach ułatwiających przejście z pracownika na pracodawcę praw autorskich do utworów stworzonych w ramach wykonywania obowiązków pracowniczych. Nabycie tych praw następuje z mocy prawa i ma charakter „automatyczny” albo „półautomatyczny”.

W przypadku dóbr własności przemysłowej takiego rozróżnienia ustawodawca nie wprowadza – nabycie praw własności przemysłowej następuje z mocy prawa i jest „automatyczne” niezależnie od tego, jaka umowa stanowi podstawę współpracy, może to być również umowa zlecenia lub umowa o dzieło.

Niezależnie od tego, na jakiej podstawie prawnej oparta jest współpraca między instytucją finansową a pracownikiem/współpracownikiem, nabycie praw przez instytucję obejmuje materiały stworzone w związku z wykonywaniem obowiązków wynikających z takiej umowy. W przypadku, gdy zakres obowiązków nie został w umowie określony, wskazówką może być charakter stanowiska pracy lub polecenie przełożonego. Fakt stworzenia jakiegoś materiału przez pracownika w godzinach pracy i na sprzęcie udostępnionym przez instytucję finansową nie oznacza automatycznie, że został on stworzony w związku z wykonywaniem obowiązków pracowniczych. Pracownik mógł po prostu realizować prywatny projekt naruszając tym samym swoje zobowiązania względem pracodawcy. Jednym słowem, pracownik poniesie konsekwencje naruszenia obowiązków pracowniczych, ale prawa własności intelektualnej do takiego materiału nie przejdą na instytucję finansową.

Osoby zatrudnione na podstawie umowy o pracę

Jeżeli ustawa lub umowa o pracę nie stanowią inaczej, pracodawca, którego pracownik stworzył utwór w wyniku wykonywania obowiązków ze stosunku pracy, nabywa z chwilą przyjęcia utworu autorskie prawa majątkowe w granicach wynikających z celu umowy o pracę i zgodnego zamiaru stron. Jeżeli pracodawca nie zawiadomi twórcy w terminie sześciu miesięcy od dostarczenia utworu o jego nieprzyjęciu lub uzależnieniu przyjęcia od dokonania określonych zmian w wyznaczonym terminie, uważa się, że utwór został przyjęty bez zastrzeżeń [1]. Pracownik i pracodawca mogą doprecyzować zasady nabywania praw autorskich przez pracodawcę, ale w „granicach rozsądku”, gdyż zmiany niekorzystne dla pracownika mogą zostać uznane za nieskuteczne. Istotnym doprecyzowaniem może być zwłaszcza wyraźne określenie celu umowy o pracę i potwierdzenia przez strony, że ich intencją jest, aby pracodawca nabywał autorskie prawa majątkowe w możliwie najszerszym zakresie. W umowie o pracę można też wymienić pola eksploatacji, na jakich pracodawca będzie mógł korzystać z utworów pracowniczych a także uregulować przejście prawa zezwalania na wykonywanie praw zależnych.

Rekomendujemy wdrożenie procedury rejestrowania prac kluczowych pracowników kreatywnych np. programistów, projektantów systemów IP, marketingowców i potwierdzania przyjęcia efektów ich pracy przez instytucję finansową. Taka procedura jest nie tylko zalecana, ale konieczna w przypadku korzystania przez pracowników z 50% kosztów uzyskania przychodów („50% KUP”). Dobrym rozwiązaniem jest również skrócenie okresu na potwierdzenie przez instytucję przyjęcia utworu pracowniczego lub nawet rozważenie przesunięcia chwili nabycia praw autorskich na chwilę ustalenia utworu.

W przypadku utworów stanowiących programy komputerowe sytuacja pracodawcy jest jeszcze bardziej korzystna. Mianowicie, o ile umowa nie stanowi inaczej prawa majątkowe do programu komputerowego stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy. Nie ma więc potrzeby dokonywania przez pracodawcę „przyjęcia” utworu ani precyzowania pól eksploatacji, na których pracodawca uzyskał prawa autorskie – pracodawca nabywa te prawa „w pełni”. Z tym „błogosławieństwem” wiąże się dość nieoczekiwana „klątwa” w postaci utrudnień związanych z wdrożeniem rozliczenia 50% KUP, co wyjaśnimy szerzej we wpisie poświęconym podatkowym aspektom korzystania z IP.

Osoby współpracujące na podstawie innej umowy niż umowy o pracę

Biorąc pod uwagę, że zwłaszcza wielu programistów, jest zainteresowanych współpracą w oparciu nie o umowę o pracę, ale relację B2B (np. umowa o stałą współpracę), nabywanie praw autorskich do utworów stworzonych przez takich współpracowników trzeba rozwiązać inaczej. Dla takiego modelu współpracy ustawa o prawie autorskim nie przewiduje żadnych ułatwień i przejście praw autorskich, zakres tego przejścia i zasady, na jakich ono nastąpi, muszą być wyraźnie uzgodnione w umowie. Zasady są w tym przypadku takie same, jak przy nabywaniu praw autorskich od „zewnętrznych” dostawców np. od innej spółki. Przede wszystkim umowa obejmująca przeniesienie praw autorskich musi być umową zawartą na piśmie pod rygorem nieważności, precyzować zakres przeniesienia praw autorskich (pola eksploatacji, przeniesienie prawa zezwalania na wykonywanie praw zależnych, terytoria, na których nastąpi przeniesienie praw etc.). Tutaj nie ma jednak znaczenia czy utwory, do których instytucja finansowa będzie nabywała prawa, będą programami komputerowymi czy nie. Również dla takiego modelu współpracy zalecane jest ewidencjonowanie utworów stworzonych przez danego współpracownika, a przynajmniej projektów, w których uczestniczył. W razie braku ewidencji mogą się zrodzić wątpliwości, czy określony utwór został rzeczywiście wykonany w związku z wykonywaniem obowiązków z tej umowy np. współpracownik jest zdania, że określony program komputerowy miał być wykonany na podstawie odrębnej umowy i w zamian za odrębne wynagrodzenie.

Czasem nawet najlepszy zespół wewnętrzny potrzebuje wsparcia specjalistów z zewnątrz np. spółek doradczych lub software house’ów. Zwłaszcza, gdy na pewnym etapie projektu niezbędne są bardzo wąskie, specjalistyczne kompetencje. Innym razem, zlecenie zewnętrznemu dostawcy realizacji całości projektu jest rozwiązaniem optymalnym. W kolejnym artykule z cyklu SPCG for FinTech zwrócimy uwagę na kluczowe kwestie nabywania przez instytucję finansową IP właśnie od takich podmiotów.

Przypisy:

[1] Pracodawca i pracownik mogą ustalić inny termin niż 6 miesięcy np. krótszy.

 

Napisz do autorów:

dr Marcin Balicki SPCG

dr Marcin Balicki

adwokat
Senior Associate

Piotr Piotrowski

adwokat
Associate

SPCG for FinTech (cz. 2) – Jakie IP powstaje w ramach projektów FinTech?

SPCG for FinTech (cz. 2) – Jakie IP powstaje w ramach projektów FinTech?

Czytaj: 6 min

We wcześniejszym wpisie z cyklu SPCG for FinTech [Know your IP] podkreślaliśmy znaczenie praw własności intelektualnej, do rozwiązań technologicznych, z których korzysta instytucja finansowa. Jednak pod określeniem prawa własności intelektualnej kryją się różne rodzaje dóbr niematerialnych oraz różne mechanizmy powstawania tych praw. Świadomość tych różnic przekłada się na efektywniejsze planowanie strategii zarządzania własnością intelektualną instytucji finansowej – zarówno wytwarzanej wewnętrznie, jak i pozyskiwanej od kontrahentów.

Własność intelektualna („IP”), to w uproszczeniu dobra niematerialne, które ze względu na cechy nadanie im przez twórcę mogą podlegać ochronie za pomocą praw wyłącznych. Wyłączność prawna do tych dóbr niematerialnych oznacza, że „właściciel” prawa jako jedyny jest uprawniony do korzystania z tego dobra niematerialnego i decydowania, jaka osoba trzecia może z tego dobra korzystać. Na przykład, autor fotografii decyduje, czy zezwoli komukolwiek na tworzenie jej kopii oraz jej rozpowszechnianie w mediach społecznościowych.

Zarówno w Polsce, jak i w innych państwach, ochrona własności intelektualnej opiera się na dwóch podstawowych filarach – ochronie utworów za pomocą przepisów ustawy o prawie autorskim i prawach pokrewnych („prawo autorskie”) oraz ochronie dóbr własności przemysłowej (np. wynalazki, wzory przemysłowe, znaki towarowe) za pomocą przepisów ustawy prawo własności przemysłowej („prawa własności przemysłowej” to m.in. patent na wynalazek, prawo z rejestracji wzoru przemysłowego, prawo ochronne na znak towarowy). W ramach każdego z tych filarów możliwe jest uzyskanie ochrony na dobro niematerialne, ochrona ta będzie zasadniczo ograniczona czasowo oraz terytorialna. Jednak filozofia stojąca za uzyskiwaniem ochrony jest zdecydowanie różna.

Prawo autorskie

Utwór chroniony jest prawem autorskim od chwili jego ustalenia, chociażby miał postać nieukończoną, jeśli tylko spełnia warunki określone w ustawie (odznacza się oryginalnością oraz indywidualnym charakterem). Moment powstania utworu jest trudny do uchwycenia, zasadniczo chodzi tutaj o chwilę, gdy tworzony materiał jest oryginalny i odzwierciedla indywidualny charakter twórcy – zwłaszcza w kontekście programów komputerowych określa się te warunki łącznie, jako „własną intelektualną twórczość autora”.

Wyłączność prawna, czyli w tym przypadku – prawa autorskie – powstaje bez konieczności dopełnienia żadnych formalności. Jednym słowem, prawa autorskie powstaną niezależnie od tego, czy twórca jest tym zainteresowany. Prawa autorskie do utworu powstają zarówno w Polsce, jak i w innych państwach świata, przy czym między zasadami prawnoautorskiej ochrony utworów w różnych państwach występują pewne różnice. Ochrona, przynajmniej w jej wymiarze majątkowym, trwa przez cały okres życia twórcy lub tego współtwórcy, który przeżył pozostałych a następnie przez 70 lat licząc od pierwszego pełnego roku po śmierci twórcy lub tego współtwórcy, który przeżył pozostałych [1]. Jednym słowem warunki powstania ochrony są prawnoautorskiej niewygórowane, obejmuje ona terytorium niemal wszystkich państw świata i trwa dosyć długo.

Prawa własności przemysłowej

Z niewielkimi wyjątkami, prawa własności przemysłowej powstają na mocy decyzji wydanej przez urząd patentowy właściwy dla terytorium, dla którego zgłaszający ubiega się o ochronę. Inaczej niż w przypadku prawa autorskiego, jeżeli zainteresowany – twórca lub osoba, która nabyła od twórcy prawo do dokonania zgłoszenia – nie wykaże inicjatywy, prawo wyłączne nie powstanie w ogóle albo tylko na wybranych terytoriach. Przykładowo, jeżeli twórca dokonał wynalazku [2], to musi przygotować dokumentację zgłoszeniową (podanie, opis wynalazku, zastrzeżenia patentowe), uiścić opłatę zgłoszeniową i przedłożyć całość urzędowi patentowemu. Urząd w pierwszej kolejności sprawdzi poprawność wniosku o udzielenie patentu a następnie ustali, czy zgłoszone rozwiązanie faktycznie jest przemysłowo stosowalne, nowe i ma poziom wynalazczy. W razie odpowiedzi pozytywnej, urząd wyda decyzję o przyznaniu patentu [3]. Na podobnych zasadach wydawane są decyzje odnośnie wzorów przemysłowych oraz znaków towarowych, przy czym zakres badania zgłoszenia może być odmienny np. w przypadku zgłoszenia wzoru przemysłowego Urząd Patentowy RP sprawdza głównie wymogi formalne. Taką operację należy przeprowadzić w każdym państwie, w którym chce się uzyskać ochronę np. przed Niemieckim Urzędem ds. Patentów i Znaków Towarowych, brytyjskim Urzędem ds. Własności Intelektualnej. W pewnym zakresie dostępne są prawa wyłączne o zakresie regionalnym (np. znak towarowy UE) albo międzynarodowe procedury, które ułatwiają uzyskanie praw własności przemysłowej w większej liczbie państw.

Sposób uzyskiwania praw własności przemysłowej sprawia, że – inaczej niż w przypadku utworów – bardzo łatwe jest ustalenie, czy jakieś dobro niematerialne jest chronione w danym państwie, czego dokładnie ono dotyczy oraz kto jest właścicielem prawa. Daje to możliwość zorientowania się przykładowo, czy:

  • rozwiązania, nad którymi pracuje Spółka zostały już opatentowane i korzystanie z nich może stanowić naruszenie patentu;
  • „wglądu” w technologie, które rozwijają konkurenci, nieraz zanim technologia zostanie udostępniona klientom jako dopracowany produkt.

 

IP w projektach FinTech

Rozwiązania FinTech opierają się przede wszystkim na oprogramowaniu, czy to udostępnianym klientowi (np. aplikacja mobilna banku), czy używanym jedynie wewnętrznie (np. program komputerowy służący do analizy danych dotyczących transakcji przeprowadzonych przez klientów). Fundamentalna rola funkcjonalności programów komputerowych – nazywanych czasem maszynami zbudowanymi ze słów – sprawia, że są one chronione dwojako. Z jednej strony treść programu komputerowego może być utworem, z drugiej strony, oferowana przez program funkcja może mieć znaczenie dla wynalazku.

W świetle przepisów prawa autorskiego programem komputerowym jest kod źródłowy lub wynikowy o określonej treści, a także, pod pewnymi warunkami, przygotowawcze materiały projektowe [4]. Dla ochrony prawem autorskim nie ma znaczenia czy program został ukończony, czy jest pozbawiony błędów bądź czy ma istotną wartość majątkową dla Spółki. Wystarczy, żeby programista piszący kod dokonał swobodnego wyboru ujęcia pewnych kwestii w kodzie, aby kod ten odzwierciedlał własną intelektualną twórczość tego programisty. Próg „własnej intelektualnej twórczości” jest dość łatwy do pokonania i dotyczy on także przypadków, w których programista nie koduje programu samodzielnie, ale jest członkiem większego zespołu rozwijającego oprogramowanie napisane pierwotnie przez inny zespół – np. wewnętrzny zespół banku rozwija oprogramowanie zakupione od zewnętrznego dostawcy.

Wyłączność prawna wynikająca z praw autorskich do programów komputerowych jest szersza niż w przypadku innych utworów i obejmuje ona m.in.:

  • tworzenie kopii programu, w tym kopii fragmentów programu w pamięci tymczasowej, co jest nieraz niezbędne do samego uruchomienia programu;
  • wprowadzanie jakichkolwiek zmian do programu komputerowego, w tym przysłowiowej zmiany jednego znaku w kodzie źródłowym.

Z tego powodu istotne jest nabywanie autorskich praw majątkowych od wszystkich osób zaangażowanych w proces powstawania oprogramowania dla Spółki. „Luki” w tym zakresie uniemożliwiają pełne korzystanie z programów komputerowych. Czasochłonnym wyzwaniem może być nawet samo ustalenie, co dokładnie stworzył dany pracownik – w rezultacie jak szeroka jest wspomniana luka i jakich systemów informatycznych Spółki ona dotyczy.

Ochrona patentowa oprogramowania jest dużo bardziej złożona niż ochrona prawem autorskim a możliwość jej uzyskania różni się w zależności od terytorium. W uproszczeniu, w USA patentowanie programów komputerowych jest generalnie łatwiejsze niż w Europie. Europejskie wątpliwości wynikają przede wszystkim z faktu, że program komputerowy jako taki nie ma charakteru technicznego [5] i patentowanie programów komputerowych „jako takich” jest wprost wyłączone w krajowych przepisach np. w Polsce. Zmusza to zgłaszających do pewnej ekwilibrystyki w zgłaszaniu rozwiązań, które dotyczą procesów lub urządzeń „wspomaganych komputerowo” bądź programów komputerowych wywołujących tzw. dalszy skutek techniczny [6]. Europejski Urząd Patentowy udzielił na przykład patentu na „elektroniczne uwierzytelnienie podpisu odręcznego, moduł i oprogramowanie komputerowe” (EP2474937), „sposób i urządzenie do wykrywania ryzyka transakcji” (EP3242236) oraz „bezpieczne transakcje na urządzeniach mobilnych” (EP3114599).

Skoro patentowanie programów komputerowych stanowi wyzwanie a one same są i tak chronione prawem autorskim, to jaki sens ma staranie się o ochronę patentową? Prawo autorskie chroni utwór o określonym sposobie wyrażenia np. program komputerowy o konkretnym kodzie źródłowym. Program komputerowy nawet tym samym językiem programowanie, ale inaczej nie będzie naruszał praw autorskich do oryginalnego programu. Nie ma znaczenia, że drugi program oferuje użytkownikowi te same funkcje, co pierwszy. Patent jest natomiast udzielany na rozwiązanie techniczne np. bardziej efektywne przetwarzanie danych przez system zarządzania bazą danych [7] wynikające z zastosowania nowego programu komputerowego. Nie ma znaczenia, jaką dokładnie treść ma kod źródłowy. Dlatego stosowanie chronionego rozwiązania będzie naruszało patent niezależnie od tego, jaki dokładnie program komputerowy zostanie użyty przez naruszającego.

Inne elementy produktu opartego o rozwiązania FinTech również mogą stanowić własność intelektualną. Zarówno taką, która jest automatycznie chroniona prawem autorskim, jak i taką, dla której można uzyskać prawa własności przemysłowej. Te pierwsze to przede wszystkim wszystkie elementy tekstowe i graficzne np. podręcznik, graficzny interfejs użytkownika aplikacji mobilnej lub serwisu internetowego, ulotki informacyjne, a te drugie to znak towarowy dla logotypu albo wzór przemysłowy dla ikon i wspomnianego już interfejsu użytkownika.

W kolejnych wpisach z cyklu SPCG for FinTech wyjaśnimy, jak zorganizować proces nabywania praw do IP tworzonego wewnętrznie przez instytucję finansową oraz IP nabywanego od kontrahentów np. software house’ów – tak aby instytucja uzyskała te prawa w możliwie najszerszym zakresie.

Przypisy:

[1] W niektórych przypadkach ten okres jest liczony odmiennie. Tytułem przykładu, dla pracowniczych programów komputerowych czas ochrony liczony jest od daty rozpowszechnienia takiego programu, a gdy program nie został rozpowszechniony, to od daty jego stworzenia.

[2] Wynalazek to rozwiązanie techniczne, które jest przemysłowo stosowalne, nowe i ma poziom wynalazczy.

[3] Maksymalny czas ochrony to 20 lat od daty zgłoszenia.

[4] Chodzi tutaj o materiały, które bez dodatkowego wysiłku można „przełożyć” na kod źródłowy lub wynikowy.

[5] Technika jest rozumiana zasadniczo jako oddziaływanie ma świat materialny za pomocą narzędzi stosowanych nauk przyrodniczych.

[6] Dalszy skutek techniczny to skutek wykraczający poza normalne oddziaływanie programu komputerowego i komputera.

[7] A tym samym niższe użycie pamięci komputera.

 

Napisz do autora:

dr Marcin Balicki SPCG

dr Marcin Balicki

adwokat
Senior Associate

SPCG for FinTech (cz. 1) – Know your IP

SPCG for FinTech (cz. 1) – Know your IP

Czytaj: 3 min

Niejedna regulacja prawna nakłada na instytucje finansowe obwiązek wdrożenia i stosowania procedur polegających na identyfikowaniu swoich klientów i uzyskiwaniu pewnych, odpowiednich oraz trafnych informacji na ich temat (know your customer). Żadne przepisy nie obligują jednak instytucji finansowych do dbałości o skuteczne nabywanie i efektywne zarządzanie własnością intelektualną.

Tymczasem, współcześnie najważniejszym aspektem usług finansowych mogą być nowoczesne rozwiązania technologiczne (FinTech), oparte przykładowo na zrobotyzowanej automatyzacji procesów bądź korzystaniu z baz danych blockchain. W rezultacie, z wyjątkiem złożonej z plastiku, chipa i paska magnetycznego karty płatniczej, usługi i produkty FinTech składają się wyłącznie z własności intelektualnej (IP). Świadomość, jakimi dokładnie zasobami IP dysponuje instytucja finansowa przekłada się bezpośrednio na jakość i bezpieczeństwo świadczonych usług, a także na wyniki finansowe. Przykładowo oprogramowanie dostarczane na „standardowych” licencjach przez korporacje technologiczne może służyć do obiegu skanów dokumentów przesyłanych przez klientów. Brak pewności, co do liczby i typu posiadanych licencji może prowadzić do sporu z dostawcą i konieczności zapłaty przeważnie bardzo wysokiego dodatkowego wynagrodzenia albo do nabywania licencji „na zapas” ponad rzeczywiste zapotrzebowanie. To tylko jeden z przykładów, jak znajomość używanego IP bezpośrednio przekłada się na biznes. Dlatego IP powinno być przez instytucję finansową ewidencjonowane nie mniej dokładnie niż środki klientów.

Przygotowanie dokumentacji oraz wdrożenie procesów wewnętrznych pozwalających na zarządzenie własnością intelektualną tworzoną wewnętrznie w instytucji finansowej jest zalecane z co najmniej kilku powodów:

  • unikanie luk w prawach własności intelektualnej do produktów lub usług, z których instytucja finansowa korzysta na własne potrzeby lub które udostępnia osobom trzecim (możliwość wykazania nabycia stosownych praw od pracownika lub współpracownika);
  • możliwość stosowania preferencyjnych 50% kosztów uzyskania przychodów oraz ulgi IP BOX, odróżnianie projektów, do których stosowana jest ulga badawczo-rozwojowa a ulga IP BOX;
  • dokumentacja obejmująca techniczne lub technologiczne tajemnice przedsiębiorstwa będzie mogła zostać w przyszłości zgłoszona do depozytu prowadzonego przez Urząd Patentowy RP

W przypadku własności intelektualnej nabytej lub licencjonowanej od osób trzecich ewidencjonowanie własności intelektualnej jest istotne z następujących powodów:

  • unikanie luk w prawach własności intelektualnej do produktów lub usług, z których instytucja finansowa korzysta na własne potrzeby lub które udostępnia osobom trzecim (możliwość wykazania nabycia lub licencjonowania stosownych praw od podwykonawcy lub dostawcy);
  • zarządzanie licencjami na oprogramowanie oraz optymalizacja ich wykorzystania przez instytucję finansową, w tym przygotowanie do ewentualnego audytu licencjodawcy bądź odsprzedaż zbędnych licencji;
  • ustalenia, jakie elementy większej całości (np. systemu informatycznego) zostały stworzone przez osobę trzecią i osoba ta ponosi za nie odpowiedzialność (np. w razie wykrycia wad prawnych);
  • określenie w jakim zakresie instytucja finansowa korzysta z własności intelektualnej w oparciu o tzw. wolne licencje, zwłaszcza z oprogramowania open source. Może być to istotne np. w przypadku wykrycia lub powstania luki bezpieczeństwa w takim oprogramowaniu.

Kompletne i prawidłowe informacje o własności intelektualnej używanej przez instytucję finansową jest też ważne przy budowaniu strategii zarządzania IP np. kalkulowania kosztów wymiany oprogramowania licencjonowanego na stworzone wewnętrznie lub odwrotnie. Taka ewidencja pozwala też wychwycić ewentualne ryzyka w tym zakresie – np. plan udostępnienia klientom usługi bazującej na oprogramowania, do którego instytucja finansowa może nie mieć pełni praw.

Zewidencjonowanie własności intelektualnej instytucji finansowej jest pierwszym krokiem do ustalenia pełni korzyści, jakie może ona przynieść. Po pierwsze, określenie silnych i słabych stron instytucji w poszczególnych obszarach – np. oparcia kluczowych wewnętrznych procesów na oprogramowaniu własnym lub zoptymalizowanym kosztowo oprogramowaniu licencjonowanym, ale jednocześnie wątpliwości odnośnie prawidłowego nabycia praw do kluczowych elementów usługi świadczonej klientom. Po drugie, zidentyfikowanie kierunków dalszej ekspansji technologicznej instytucji finansowej – docelowo nawet wypracowanie technologicznie unikalnej usługi i osiągnięcie przewagi konkurencyjnej nad konkurentami lub pozycji negocjacyjnej do wzajemnego licencjonowania technologii z konkurentami lub spółkami technologicznymi. Po trzecie, dokonanie wyceny kluczowego IP, w szczególności znaków towarowych, wynalazków i oprogramowania, a w rezultacie– ich ostatecznego wpływu na wartość całej instytucji. Po czwarte, budowanie wizerunku instytucji finansowej jako dysponującej zasobami do samodzielnego budowania usług opartych na nowych technologiach.

W kolejnych wpisach cyklu SPCG for FinTech przybliżymy zasady, na jakich możliwa jest ochrona własności intelektualnej rozwiązań FinTech oraz jak zorganizować możliwie najbardziej efektywne i pełne nabycie takiej własności intelektualnej przez instytucję finansową. Przedstawiane przez nas rozwiązania będą służyły przede wszystkim zwiększeniu bezpieczeństwa prawnego oraz efektywności zarządzania własnością intelektualną w instytucji finansowej oraz obniżeniu kosztów prowadzenia działalności – czy to przez korzystanie z preferencji podatkowych, czy optymalizację używanych licencji.

Instytucje finansowe nie działają jednak w regulacyjnej próżni – wręcz przeciwnie. Niemal każda nowa istotna technologia zaprzęgnięta do świadczenia usług finansowych to pytania o zgodność działania instytucji finansowej z przepisami prawa i stanowiskami polskiego i europejskich regulatorów. W tym kontekście szczególną uwagę należy zwrócić na przepisy i oczekiwania nadzorcze w obszarze outsourcingu regulowanego i zarządzania ryzykiem w instytucji finansowej.

Podsumowując, rozwiązanie technologiczne, które ma stać się usługą dla klienta instytucji finansowej to nie tylko wyzwania inżynieryjne i programistyczne, ale i prawne. Liczymy, że cykl SPCG for FinTech ułatwi instytucjom finansowym mierzenie się z tymi wyzwaniami.

 

Napisz do autorów:

dr Marcin Balicki SPCG

dr Marcin Balicki

adwokat
Senior Associate

Malwina Przyborowska SPCG

Malwina Przyborowska

radca prawny
Senior Associate

Pin It on Pinterest