Kod źródłowy, aplikacja lub wtyczka skopiowane przez konkurencję – jak chronić oprogramowanie prawem autorskim
Konkurent wypuścił aplikację o tych samych funkcjach, w kodzie pojawiły się Twoje komentarze albo były programista wykorzystuje rozwiązania z firmowego repozytorium? W takich sprawach samo podobieństwo produktu nie wystarcza. Trzeba ustalić, co dokładnie przejęto: kod, dokumentację, interfejs, tajemnicę przedsiębiorstwa, nazwę czy wyłącznie pomysł na działanie programu.
Oprogramowanie korzysta ze szczególnej ochrony przewidzianej w art. 74-77 prawa autorskiego. Chronione są formy wyrażenia programu, w tym kod źródłowy i wynikowy, ale nie sama funkcjonalność, język programowania, algorytm jako idea ani reguła biznesowa. Najlepsze wezwania nie zaczynają się więc od zdania „aplikacja wygląda podobnie”, lecz od uporządkowanego porównania praw, dostępu do kodu i technicznych śladów kopiowania.
Ochrona obejmuje różne formy wyrażenia programu. Skopiowanie kodu po jego dekompilacji może więc naruszać prawa nawet wtedy, gdy konkurent zmienił nazwy zmiennych, kolejność plików i formatowanie. Z drugiej strony identyczne krótkie instrukcje, deklaracje importów, standardowe konfiguracje i kod wygenerowany przez framework nie przesądzają kopiowania.
Materiały projektowe i dokumentacja
Specyfikacja, diagram architektury, dokumentacja API, instrukcja, baza testów i opis wdrożenia mogą być chronione jako odrębne utwory albo stanowić tajemnicę przedsiębiorstwa. Nie należy automatycznie nazywać całej dokumentacji programem komputerowym. W wezwaniu najlepiej rozdzielić kod od tekstów, grafik i poufnego know-how.
Masz repozytorium, raport podobieństwa albo podejrzenie byłego developera?
Podczas konsultacji telefonicznej przeanalizujemy Twój przypadek, umowy, historię dostępu, zakres podobieństw i możliwe roszczenia, a następnie ustalimy, czego nie ujawniać przed zabezpieczeniem dowodów.
Art. 74 ust. 2 prawa autorskiego chroni formy wyrażenia programu, ale wyłącza idee i zasady będące podstawą jego elementów, w tym zasady leżące u podstaw interfejsów. Trybunał Sprawiedliwości UE potwierdził również, że funkcjonalność programu i język programowania nie są same w sobie chronioną formą wyrażenia programu.
Konkurent może więc legalnie stworzyć drugą aplikację do rezerwacji wizyt, synchronizacji magazynu albo obsługi faktur. Może odwzorować zgodność z formatem danych i napisać niezależny kod, jeżeli nie przejmuje chronionych fragmentów ani poufnych informacji. Nie możesz uzyskać monopolu na samo „co program robi”.
Co przemawia za niezależną implementacją?
Własna architektura, inne biblioteki, odmienny podział modułów, inne błędy, własne komentarze i udokumentowany proces tworzenia przemawiają za niezależnością. Szczególnie ważne są wcześniejsze commity konkurenta, dokumentacja clean-room oraz brak dostępu jego zespołu do Twojego repozytorium.
Co przemawia za kopiowaniem?
W praktyce najbardziej przekonujące są podobieństwa, których nie wyjaśnia funkcja:
identyczne literówki i błędne komentarze;
te same nietypowe nazwy klas, metod i tabel;
powtarzające się martwe fragmenty kodu;
identyczne stałe, ukryte znaczniki i kolejność operacji;
ten sam nieoczywisty błąd lub luka bezpieczeństwa;
zbieżne komunikaty techniczne i wewnętrzne identyfikatory;
fragmenty historii projektu albo nazwy klientów pozostawione w kodzie;
podobieństwo obejmujące rozwiązania, których funkcja nie wymusza.
Nie ma jednego procentu podobieństwa, który automatycznie rozstrzyga spór. Dziesięć procent wyjątkowo charakterystycznego kodu może być ważniejsze niż osiemdziesiąt procent boilerplate wygenerowanego przez narzędzie.
Interfejs to osobna warstwa
Graficzny interfejs użytkownika nie jest formą wyrażenia programu w rozumieniu szczególnej ochrony software, ale może korzystać z ochrony jako utwór graficzny, jeżeli jest oryginalny. Warto wtedy porównać layout, ikony, animacje, ilustracje i kompozycję, a nie wyłącznie kod frontendu. Powiązane zasady opisuje artykuł o projekcie graficznym i identyfikacji wizualnej.
Trzy najczęstsze scenariusze sporu
Scenariusz 1: konkurent zobaczył produkt i napisał własną wersję
To najtrudniejszy przypadek dla właściciela wcześniejszej aplikacji. Podobna funkcjonalność, proces zakupowy i układ typowych ekranów nie wystarczą. Trzeba wykazać przejęcie konkretnej formy, grafiki, tekstów, chronionego układu albo czyn nieuczciwej konkurencji. Samo wejście na rynek z tańszym odpowiednikiem nie jest bezprawne.
Scenariusz 2: były pracownik lub wykonawca miał dostęp do repozytorium
Tutaj oprócz prawa autorskiego pojawia się tajemnica przedsiębiorstwa, umowa o poufności, zakres obowiązków i historia dostępu. Nie wystarczy stwierdzić, że nowa aplikacja „wygląda znajomo”. Zabezpiecz logi Git, logowania VPN, eksporty repozytorium, urządzenia służbowe, wiadomości i dokumenty związane z odejściem.
Nie przejmuj prywatnego konta byłego pracownika ani nie instaluj ukrytych narzędzi śledzących. Dowody pozyskane bezprawnie mogą stworzyć odrębny problem. Firma powinna korzystać z danych, do których ma legalny dostęp, i rozważyć formalne zabezpieczenie środka dowodowego.
Scenariusz 3: użyto komponentu open source
Kod open source nadal jest chroniony prawem autorskim. Licencja udziela jednak szerokiego zezwolenia na korzystanie, często również komercyjne. Naruszenie nie polega więc na samym zarabianiu na kodzie GPL, MIT lub Apache. Trzeba sprawdzić konkretną wersję licencji, sposób dystrybucji, obowiązek zachowania informacji o autorze, przekazania tekstu licencji, udostępnienia odpowiadającego kodu źródłowego albo zastosowania copyleft.
GPL i AGPL nie działają identycznie. Zwykłe używanie zmodyfikowanego programu GPL na własnym serwerze nie zawsze uruchamia obowiązek publikacji kodu, podczas gdy AGPL przewiduje dodatkowe obowiązki przy udostępnianiu funkcjonalności przez sieć. Nie wysyłaj wezwania opartego na haśle „użycie komercyjne jest zakazane”, bo w licencjach open source często jest dokładnie odwrotnie.
Komu przysługują prawa do kodu?
Przed porównaniem kodu sprawdź łańcuch praw. W praktyce wiele firm odkrywa problem dopiero wtedy, gdy trzeba podpisać wezwanie.
Program napisany przez pracownika
Art. 74 ust. 3 prawa autorskiego przewiduje szczególną regułę. Prawa majątkowe do programu stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy, chyba że umowa stanowi inaczej. Nie stosuje się tu identycznego mechanizmu przyjęcia utworu jak przy zwykłych utworach pracowniczych.
Trzeba jednak wykazać, że tworzenie programu należało do obowiązków pracowniczych. Kod napisany prywatnie, poza zakresem zatrudnienia i bez związku z powierzonym zadaniem, wymaga odrębnej oceny.
Freelancer, zlecenie i B2B
Zapłata faktury oraz przekazanie plików nie przenoszą automatycznie praw. Umowa przenosząca autorskie prawa majątkowe wymaga formy pisemnej pod rygorem nieważności i powinna wyraźnie wskazywać pola eksploatacji. Bez skutecznego przeniesienia zamawiający może posiadać licencję wynikającą z celu umowy, ale jej zakres może nie wystarczyć do samodzielnego zakazania każdej formy korzystania przez autora.
Sprawdź również prawo do zmian, sublicemnej pod rygorem nieważności i powinna wyraźencji, przekazywania kodu klientom, udostępniania SaaS i korzystania z komponentów osób trzecich. Ogólne zdanie „wszystkie prawa przechodzą na zamawiającego” bywa niewystarczające, jeżeli nie określa pól eksploatacji.
Kilku autorów
Jeżeli program jest utworem współautorskim, prawa przysługują współtwórcom wspólnie. Do korzystania z całości co do zasady potrzebna jest zgoda wszystkich. Inaczej wygląda dochodzenie roszczeń: art. 9 ust. 4 prawa autorskiego pozwala każdemu współtwórcy dochodzić roszczeń z tytułu naruszenia prawa do całości, a uzyskane świadczenie przypada współtwórcom stosownie do udziałów.
Nie jest więc prawdą, że przed każdym wezwaniem trzeba zawsze uzyskać podpis wszystkich programistów. Trzeba natomiast ustalić, czy adresat wezwania działa jako współtwórca całości, autor samodzielnego modułu, nabywca praw czy licencjobiorca.
Spółka kupiła projekt lub zorganizowaną część przedsiębiorstwa
Przejrzyj umowę transakcyjną, załączniki IP, protokoły przekazania repozytoriów i licencje. Sama sprzedaż udziałów nie zmienia właściciela aktywów spółki, natomiast sprzedaż przedsiębiorstwa może obejmować prawa wskazane w umowie. Nazwa produktu, domena, logo i kod mogą należeć do różnych podmiotów.
Skuteczna ochrona kodu źródłowego wtyczek i programów opiera się na przepisach prawa autorskiego.
Jak zbudować techniczny materiał dowodowy?
Raport z narzędzia porównującego kod to początek, nie koniec analizy. MOSS, JPlag, Codequiry i podobne rozwiązania mogą wykryć strukturalne podobieństwa, lecz wynik zależy od języka, konfiguracji, bibliotek i normalizacji. Sąd może potrzebować opinii biegłego, który wyjaśni, dlaczego podobieństwo jest nietypowe i dotyczy elementów twórczych.
Najpierw zabezpiecz własny projekt
Przygotuj kopię repozytorium wraz z pełną historią, tagami, gałęziami, pull requestami i podpisami commitów. Nie ograniczaj się do PDF z GitHuba. Zachowaj również pipeline CI/CD, zgłoszenia błędów, dokumentację projektową, korespondencję i pliki źródłowe. Obliczenie sum kontrolnych dla kopii pomaga później wykazać, że materiał nie został zmieniony.
Następnie zabezpiecz produkt konkurenta
Pobierz legalnie dostępną wersję aplikacji albo wtyczki i zachowaj instalator, pakiet, metadane, numer wersji, datę oraz adres pobrania. Nie omijaj zabezpieczeń i nie uzyskuj dostępu do panelu bez uprawnienia. Przy aplikacji webowej nagraj działanie, zasoby pobierane przez przeglądarkę i publicznie dostępne pliki JavaScript.
Porównanie powinno wyjaśniać, nie tylko podkreślać
Dobra tabela dowodowa obejmuje:
lokalizację fragmentu w Twoim repozytorium;
datę pierwszego commitu;
odpowiadający fragment produktu konkurenta;
rodzaj podobieństwa;
informację, czy fragment pochodzi z biblioteki lub generatora;
cechy nietypowe, komentarz, błąd lub ukryty znacznik;
możliwy legalny dostęp konkurenta do kodu;
wniosek techniczny sformułowany bez przesady.
Dostęp do kodu ma znaczenie
Podobieństwo jest bardziej przekonujące, gdy konkurent miał realny dostęp do repozytorium jako pracownik, wykonawca, partner wdrożeniowy albo nabywca licencji. Brak dostępu nie wyklucza naruszenia, jeśli kod wyciekł inną drogą, ale wymaga wskazania prawdopodobnego źródła.
Nie publikuj kodu w wezwaniu
Do pisma można dołączyć ograniczone fragmenty lub opis techniczny. Pełne repozytorium przekazane przeciwnikowi może ujawnić kolejne tajemnice i ułatwić modyfikację produktu. Warto przewidzieć bezpieczny tryb udostępnienia materiału biegłemu, sądowi lub pełnomocnikowi.
Reverse engineering i dekompilacja, gdzie przebiega granica?
Inżynieria odwrotna nie jest ani zawsze legalna, ani zawsze zakazana. Legalny użytkownik może obserwować, badać i testować funkcjonowanie programu w trakcie dozwolonego korzystania, aby poznać idee i zasady jego działania. Nie daje to jednak prawa do skopiowania formy wyrażenia.
Dekompilacja jest dopuszczalna w węższym zakresie, gdy jest niezbędna do uzyskania informacji koniecznych do współdziałania niezależnie stworzonego programu z innymi programami. Musi być wykonywana przez uprawnionego użytkownika albo na jego rzecz, dotyczyć tylko potrzebnych części i informacji wcześniej łatwo niedostępnych.
Uzyskanych informacji nie można wykorzystać do wytworzenia lub wprowadzenia na rynek programu o istotnie podobnej formie wyrażenia ani przekazywać ich poza potrzeby interoperacyjności. Umowa nie może skutecznie wyłączyć ustawowych wyjątków z art. 75 ust. 2 i 3.
Clean-room development
Przy tworzeniu produktu kompatybilnego warto rozdzielić zespół analizujący zachowanie programu od zespołu piszącego kod. Pierwszy przygotowuje neutralną specyfikację funkcjonalną, drugi nie ma dostępu do cudzego kodu. Taki proces nie gwarantuje wygranej, lecz ułatwia wykazanie niezależnej implementacji.
Tajemnica przedsiębiorstwa, interfejs i inne podstawy ochrony
Tajemnica przedsiębiorstwa nie powstaje od samej etykiety „confidential”
Art. 11 ustawy o zwalczaniu nieuczciwej konkurencji wymaga, aby informacja miała wartość gospodarczą, nie była powszechnie znana lub łatwo dostępna oraz była objęta działaniami zmierzającymi do utrzymania poufności. Kod źródłowy może spełniać te warunki, jeżeli firma stosuje kontrolę dostępów, NDA, ograniczenia repozytorium, procedury odejścia i zasady korzystania z urządzeń.
Publiczny kod, fragment opublikowany bez ograniczeń albo rozwiązanie łatwe do ustalenia przez legalne badanie produktu może nie korzystać z ochrony jako tajemnica. Ustawa wyraźnie dopuszcza niezależne odkrycie lub wytworzenie oraz, pod określonymi warunkami, obserwację i testowanie legalnie posiadanego lub publicznie dostępnego przedmiotu.
Były pracownik i odpowiedzialność karna
Wykorzystanie tajemnicy przedsiębiorstwa może rodzić roszczenia cywilne z art. 18 UZNK. W poważniejszych przypadkach art. 23 UZNK przewiduje również odpowiedzialność karną za ujawnienie lub wykorzystanie tajemnicy, jeżeli spełnione są ustawowe przesłanki. Nie każde przejście pracownika do konkurencji jest jednak bezprawne. Może on korzystać z własnego doświadczenia i umiejętności, o ile nie zabiera chronionych plików i poufnego know-how.
Interfejs, nazwa i ryzyko pomyłki
Jeżeli konkurent napisał własny kod, ale przejął ekran startowy, ikony, ilustracje i charakterystyczną kompozycję, możliwa jest ochrona elementów graficznych. Jeżeli używa podobnej nazwy lub logo, oceń także znaki towarowe oraz wprowadzanie klientów w błąd. Szczegóły znajdziesz w artykule o bezprawnym używaniu logo i nazwy firmy.
Art. 13 UZNK dotyczy naśladowania zewnętrznej postaci gotowego produktu za pomocą technicznych środków reprodukcji, gdy powstaje możliwość pomyłki co do producenta lub produktu. Nie chroni samych cech funkcjonalnych. Zastosowanie tego przepisu do konkretnego software i jego interfejsu wymaga ostrożnej oceny, dlatego nie powinien zastępować analizy kodu i grafiki.
Patent na rozwiązanie komputerowe
Algorytm i program komputerowy „jako taki” nie uzyskują patentu tylko dlatego, że są nowe. Możliwa jest natomiast ochrona wynalazku realizowanego komputerowo, jeżeli rozwiązuje problem techniczny i spełnia wymagania nowości, poziomu wynalazczego oraz przemysłowej stosowalności. Przykładem mogą być rozwiązania sterujące urządzeniem, bezpieczeństwem sprzętowym, kompresją lub przetwarzaniem sygnału.
Patent wymaga zgłoszenia przed ujawnieniem rozwiązania i nie zastępuje ochrony autorskiej istniejącego kodu. W sporze dotyczącym już opublikowanej funkcji może być za późno na skuteczne zgłoszenie, dlatego strategię patentową planuje się przed premierą.
Nie zapominaj o innych elementach produktu
Kopiowanie aplikacji często obejmuje teksty, regulamin, materiały marketingowe, logo i grafiki. W razie przejęcia zdjęć zastosuj poradnik o nieautoryzowanym wykorzystaniu fotografii. Przy muzyce lub grafice w materiałach promocyjnych pomocny będzie artykuł o sytuacji, gdy wykorzystano muzykę albo grafikę bez zgody. Jeżeli razem z wtyczką rozpowszechniana jest skopiowana instrukcja lub płatny plik, porównaj także zasady dotyczące pirackiego udostępniania e-booka.
Roszczenia i wycena naruszenia kodu
Art. 79 prawa autorskiego pozwala żądać zaniechania, usunięcia skutków, naprawienia szkody oraz wydania uzyskanych korzyści. W sprawie software trzeba przełożyć te ogólne roszczenia na działania techniczne.
Zaniechanie i usunięcie skutków
Żądanie może obejmować zatrzymanie dystrybucji wersji zawierającej skopiowany kod, usunięcie fragmentów z repozytorium, wstrzymanie aktualizacji, wycofanie wtyczki z marketplace oraz usunięcie publicznych kopii. Całkowite wyłączenie produktu nie zawsze jest proporcjonalne, jeżeli naruszenie dotyczy jednego możliwego do zastąpienia modułu.
Dwukrotność stosownego wynagrodzenia
Uprawniony może żądać dwukrotności wynagrodzenia, które byłoby należne za zgodę na ustalony sposób korzystania. Dopuszczalna dwukrotność nie zależy od wykazania winy. Trzykrotność została wyeliminowana jako niezgodna z Konstytucją i nie może być dochodzona nawet przy umyślnym kopiowaniu.
Jak określić stawkę?
Cena wykonania kodu nie zawsze jest równa cenie licencji. Przy wycenie uwzględnia się między innymi:
zakres i znaczenie przejętego modułu;
czas korzystania i liczbę wersji produktu;
terytorium oraz model SaaS, on-premise lub marketplace;
liczbę klientów i urządzeń;
prawo do modyfikacji i sublicencji;
wyłączność albo jej brak;
koszt odtworzenia funkcjonalności, ale bez automatycznego utożsamiania go z licencją;
Twoje wcześniejsze umowy i rynkowe stawki porównawcze.
Przychód konkurenta nie jest automatycznie wysokością szkody ani stosownego wynagrodzenia. Może jednak pomóc ocenić skalę korzystania i korzyści związane z naruszeniem.
Szkoda na zasadach ogólnych
Możesz dochodzić rzeczywistej straty i utraconych korzyści, jeżeli wykażesz związek przyczynowy. Utrata przetargu, odejście klientów albo konieczność przebudowy zabezpieczeń wymagają dokumentów, nie tylko założenia, że każdy klient konkurenta kupiłby Twój produkt.
Roszczenia z UZNK
Przy tajemnicy przedsiębiorstwa art. 18 UZNK przewiduje zaniechanie, usunięcie skutków, oświadczenie, odszkodowanie i wydanie korzyści. Ustawa przewiduje też szczególne rozwiązania dotyczące stosownego wynagrodzenia. Nie należy mechanicznie sumować kilku odszkodowań za ten sam ekonomiczny uszczerbek.
Czy potrafisz wykazać, że prawa przysługują Tobie lub Twojej firmie?
Które fragmenty są chronione, a które pochodzą z bibliotek, generatorów albo open source?
Czy konkurent miał dostęp do Twojego kodu?
Czy zabezpieczyłeś wersję jego produktu i własną historię repozytorium?
Jakiego rezultatu żądasz: usunięcia modułu, licencji, wycofania produktu czy rozliczenia przeszłości?
Co wpisać do wezwania?
Wskaż produkt, wersję, fragmenty, podstawę praw, łańcuch nabycia, dowód pierwszeństwa i sposób korzystania. Osobno opisz kod, tajemnicę, interfejs, logo i teksty. Zażądaj zachowania repozytoriów, logów, kopii wdrożeń oraz dokumentów dotyczących pochodzenia kodu. Niszczenie materiału po otrzymaniu pisma może mieć znaczenie procesowe.
Termin 14 dni nie jest ustawową regułą. Dystrybucję naruszającej wersji można żądać zatrzymać niezwłocznie, a na odpowiedź, przekazanie informacji i zapłatę wyznaczyć termin dostosowany do zakresu sprawy.
Zabezpieczenie środka dowodowego
Jeżeli istnieje ryzyko usunięcia repozytorium, zmiany wersji albo ukrycia danych, rozważ instrumenty przewidziane dla spraw własności intelektualnej: zabezpieczenie środka dowodowego, wyjawienie lub wydanie dowodu oraz wezwanie do udzielenia informacji. Wniosek powinien być precyzyjny i chronić tajemnice obu stron.
Zabezpieczenie roszczenia
Sąd może tymczasowo zakazać określonego korzystania przed końcem procesu, jeżeli uprawdopodobnisz roszczenie i interes prawny. Zakaz sprzedaży całej aplikacji jest środkiem daleko idącym. Czasem bardziej proporcjonalne będzie wstrzymanie konkretnej wersji, modułu albo publikacji w marketplace.
Ugoda lub licencja
Jeżeli produkt konkurenta zawiera wartościowy, ale możliwy do wydzielenia moduł, ugoda może przewidywać opłatę za wcześniejsze korzystanie, licencję na przyszłość, audyt, obowiązek usunięcia określonych fragmentów i karę umowną za dalsze naruszenia. Relację między etapami opisuje artykuł o wezwaniu i ugodzie sądowej.
Doręczenie i właściwy adresat
Sprawdź aktualne dane spółki w rejestrze, podmiot prowadzący marketplace, właściciela domeny i rzeczywistego wydawcę aplikacji. Pismo można równolegle wysłać e-mailem, ale zachowaj dowód treści oraz doręczenia. Praktyczne zasady znajdziesz w poradniku jak wysłać wezwanie do zaprzestania.
Kiedy przejść do pozwu?
Brak odpowiedzi, dalsze wydawanie wersji, zacieranie śladów i wysoka wartość rynku przemawiają za szybką analizą procesu. Porównanie kosztów i celów zawiera artykuł wezwanie do zaprzestania a pozew sądowy.
Krótki plan na pierwsze 48 godzin
Dzień pierwszy: wykonaj kopię repozytorium, zabezpiecz logi, pobierz legalnie produkt konkurenta i ogranicz dostęp do własnych systemów. Dzień drugi: uporządkuj umowy, przygotuj krótką tabelę podobieństw i ustal, czy potrzebny jest biegły przed wysłaniem pisma. Nie kontaktuj się impulsywnie z byłym pracownikiem, jeżeli może to doprowadzić do usunięcia dowodów.
Gotowy wzór pomaga uporządkować łańcuch praw, opisać skopiowane elementy, zażądać zatrzymania dystrybucji i przygotować podstawę do zabezpieczenia dowodów.
Wezwanie do zaprzestania naruszania praw autorskich
Najczęstsze pytania o ochronę kodu, aplikacji i wtyczek
Nie. Ochrona powstaje z chwilą ustalenia twórczego programu i nie wymaga rejestracji ani oznaczenia copyright. Rejestr, depozyt, repozytorium i znacznik czasu mogą jednak ułatwić wykazanie daty oraz treści konkretnej wersji.
Nie. Ochrona obejmuje formy wyrażenia programu, w tym kod źródłowy i wynikowy. Oddzielnie mogą być chronione dokumentacja, grafiki i teksty. Sama funkcjonalność oraz idee leżące u podstaw programu nie są chronioną formą kodu.
Zwykle nie wystarczy do zarzutu kopiowania programu. Funkcjonalność może zostać odtworzona niezależnie. Potrzebujesz podobieństw w chronionej formie, dostępu do kodu albo innych podstaw, na przykład przejęcia grafiki, tajemnicy przedsiębiorstwa lub oznaczeń.
Nie jako forma wyrażenia programu tylko dlatego, że są używane przez konkretny produkt. TSUE wskazał, że funkcjonalność, język programowania i formaty plików używane do wykorzystania funkcji nie są same w sobie chronione jak kod. Konkretna dokumentacja lub implementacja może być chroniona odrębnie.
Nie. Jeżeli zachowano strukturę i twórcze elementy, kosmetyczna zmiana nazw, formatowania i kolejności plików nie tworzy niezależnego programu. Biegły może normalizować kod i porównywać rozwiązania po usunięciu takich zmian.
Nie istnieje ustawowy próg. Narzędzia podają wskaźniki techniczne, ale wynik trzeba zinterpretować. Istotne są twórczość fragmentu, standardowe biblioteki, kod generowany, dostęp i nietypowe wspólne cechy.
Może być wartościowym materiałem, lecz zwykle nie zastępuje opinii biegłego. Raport powinien wskazywać metodę, wykluczenia i konkretne fragmenty. Sąd musi ocenić, czy podobieństwo dotyczy elementów chronionych, a nie standardu języka.
Pomaga wykazać istnienie kodu w określonym czasie, ale nie zawsze przesądza autorstwo i prawa. Commit mógł zawierać kod osoby trzeciej albo zostać zaimportowany. Połącz historię z umowami, pull requestami, zgłoszeniami i zeznaniami.
Dekompilacja jest dozwolona tylko w ustawowych granicach, przede wszystkim dla uzyskania informacji potrzebnych do interoperacyjności. Nie traktuj jej jako ogólnego prawa do pozyskania cudzego kodu dla procesu. Bezpieczniej skonsultować sposób zabezpieczenia produktu i wystąpić o dowód w postępowaniu.
Tak. Osoba uprawniona do korzystania może obserwować, badać i testować funkcjonowanie programu podczas dozwolonych czynności, aby poznać idee i zasady. Nie pozwala to kopiować chronionej formy ani obchodzić innych ograniczeń bez podstawy.
Nie daje automatycznego immunitetu, ale wzmacnia dowód niezależnego tworzenia. Zespół piszący kod powinien otrzymać neutralną specyfikację i nie mieć dostępu do cudzego kodu. Proces trzeba dokumentować od początku.
Gdy program powstał w wyniku wykonywania obowiązków ze stosunku pracy, art. 74 ust. 3 przyznaje prawa majątkowe pracodawcy, chyba że umowa stanowi inaczej. Kod niezwiązany z obowiązkami albo stworzony przed zatrudnieniem wymaga osobnej oceny.
Nie. Przeniesienie praw wymaga pisemnej umowy i wskazania pól eksploatacji. Faktura potwierdza rozliczenie, ale nie zastępuje umowy. Zleceniodawca może posiadać licencję wynikającą z celu współpracy, której zakres trzeba ustalić.
Tak. Każdy współtwórca może dochodzić roszczeń z tytułu naruszenia prawa do całości utworu. Uzyskane świadczenie przypada współtwórcom według udziałów. Inne zasady dotyczą zwykłego korzystania z całego wspólnego programu.
Może korzystać z ogólnego doświadczenia i umiejętności. Nie może zabrać kodu, dokumentacji ani poufnego know-how stanowiącego tajemnicę przedsiębiorstwa. Ustal, czy podobieństwo wynika z wiedzy zawodowej, standardu branżowego czy przejęcia konkretnych materiałów.
Kontrola dostępu, repozytoria prywatne, NDA, polityki bezpieczeństwa, logi, szyfrowanie, szkolenia i procedura odejścia. Sama klauzula poufności może być niewystarczająca, jeżeli firma w praktyce udostępnia kod bez ograniczeń.
Nie. UZNK dopuszcza niezależne odkrycie oraz obserwację, badanie i testowanie publicznie dostępnego lub legalnie posiadanego przedmiotu, jeżeli uprawnienie do pozyskania informacji nie było ograniczone. Równolegle trzeba przestrzegać szczególnych zasad dotyczących programów.
Tak, licencje open source pozwalają na użycie komercyjne. Trzeba zachować ich warunki. Zależnie od licencji mogą obejmować informacje o autorze, tekst licencji, źródło, copyleft albo obowiązki związane z dystrybucją.
Nie. Zwykłe prywatne lub wewnętrzne modyfikacje nie muszą być publikowane. Obowiązki GPL pojawiają się przede wszystkim przy przekazywaniu programu odbiorcom. AGPL dodatkowo reguluje udostępnianie zmodyfikowanego programu przez sieć.
Może prowadzić do utraty uprawnienia licencyjnego i roszczeń autorskich, ale zakres zależy od licencji, możliwości usunięcia naruszenia i prawa właściwego. Najpierw ustal właścicieli praw oraz dokładny obowiązek, którego nie wykonano.
Tak, jako utwór graficzny, jeżeli jest oryginalny. Ochrona może objąć kompozycję, ilustracje, ikony i animacje, lecz nie samą funkcję przycisku albo standardowy układ narzucony użytecznością.
Nie. Przepis dotyczy kopiowania zewnętrznej postaci gotowego produktu za pomocą technicznych środków reprodukcji i ryzyka pomyłki. Nie chroni cech funkcjonalnych. Zastosowanie do konkretnego software wymaga analizy produktu i rynku.
Algorytm lub program jako taki nie jest patentowany tylko dlatego, że jest nowy. Możliwy bywa patent na wynalazek realizowany komputerowo, który rozwiązuje problem techniczny i spełnia pozostałe przesłanki. Wymaga to specjalistycznej oceny przed ujawnieniem rozwiązania.
Tak. Dopuszczalna dwukrotność stosownego wynagrodzenia nie jest uzależniona od winy. Nadal trzeba udowodnić naruszenie oraz rynkową wysokość licencji odpowiadającej zakresowi korzystania.
Nie. Trzykrotność stosownego wynagrodzenia została uznana za niezgodną z Konstytucją. Przy umyślnym działaniu można analizować szkodę na zasadach ogólnych, korzyści, prawa osobiste i inne właściwe podstawy.
Nie zawsze. Koszt wytworzenia i wartość licencji to różne wielkości. Licencja zależy od zakresu użytkowników, czasu, terytorium, wyłączności, modyfikacji, sublicencji i modelu dystrybucji.
Można formułować takie żądanie, lecz powinno być proporcjonalne do zakresu naruszenia. Jeżeli skopiowano możliwy do zastąpienia moduł, sąd może oceniać środek węziej. Znaczenie ma możliwość skutecznego usunięcia kodu bez zatrzymania całego produktu.
Nie. Wystarczy wskazać reprezentatywne fragmenty i metodę porównania. Pełne repozytorium może ujawnić tajemnice. Materiał można przekazać w bezpiecznym trybie biegłemu, sądowi lub pełnomocnikom.
Nie. Aktywne naruszenie może wymagać niezwłocznego zatrzymania, a na techniczną odpowiedź i zapłatę można wyznaczyć 7, 14 lub 21 dni. Termin powinien być realny i odpowiadać żądaniom.
W sprawach własności intelektualnej można rozważyć zabezpieczenie środka dowodowego i inne instrumenty służące uzyskaniu informacji. Wniosek musi być konkretny, proporcjonalny i uwzględniać ochronę tajemnic przedsiębiorstwa obu stron.
Nie. Może je podpisać uprawniona firma, twórca albo pełnomocnik. Pomoc adwokata jest szczególnie przydatna przy niejasnym łańcuchu praw, byłym pracowniku, open source i potrzebie pilnego zabezpieczenia. Dostępna jest indywidualna konsultacja prawna.
Pobierz bezpłatny poradnik i dowiedz się jak skutecznie zareagować, krok po kroku, bez prawniczego żargonu.
Cookies
Obsługujemy pliki cookies. Jeśli uważasz, że to jest ok, po prostu kliknij "Akceptuj wszystko". Możesz też wybrać, jakie chcesz ciasteczka, klikając "Ustawienia".
