Prawo autorskie w IT bez żargonu: przewodnik po licencjach dla nieprogramistów

O co w ogóle chodzi w prawie autorskim w IT?

Czym jest „utwór” i dlaczego program to nie tylko „plik .exe”

Prawo autorskie nie chroni „programu” w potocznym rozumieniu, tylko utwór. Utwór to każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci. W IT takim utworem może być zarówno kod źródłowy, jak i graficzny interfejs użytkownika, projekt aplikacji, czy nawet niektóre pliki konfiguracyjne.

Ustawodawcy traktują program komputerowy jak utwór literacki. Brzmi dziwnie, ale chodzi o to, że jest zapisany w postaci „tekstu” – kodu, który można zapisać, odczytać, modyfikować. Oznacza to, że na program stosuje się większość zasad znanych z książek czy artykułów, z kilkoma wyjątkami przewidzianymi specjalnie dla oprogramowania.

Dla osoby nietechnicznej praktyczna konsekwencja jest prosta: program to utwór chroniony automatycznie, od chwili jego stworzenia. Nie potrzeba rejestracji, pieczątek, depozytów. Jeżeli ktoś tworzy aplikację w Twojej firmie – nawet prosty skrypt – wchodzi w grę prawo autorskie, a nie „niczyje” linijki kodu.

Idea, funkcjonalność, forma – co jest chronione, a co można kopiować

Jedna z ważniejszych granic w prawie autorskim to różnica między ideą a konkretną formą. Sama koncepcja systemu, ogólny pomysł biznesowy czy abstrakcyjny algorytm jako taki nie podlegają ochronie. Chronione jest to, jak ten pomysł został wyrażony: konkretny kod, konkretny tekst, konkretna grafika.

Przykład:

• Nie jest chronione: pomysł „aplikacji do rezerwacji wizyt u fryzjera z powiadomieniami SMS”. Ktoś inny może zrobić podobną usługę.
• Jest chronione: konkretny kod tej aplikacji, konkretny projekt interfejsu, teksty e‑maili, grafiki, baza ikon.

Z punktu widzenia biznesu w IT:

• funkcjonalność (co system robi) – co do zasady nie jest chroniona, konkurencja może stworzyć system robiący to samo, ale w inny sposób,
• forma (jak to jest zrobione i pokazane) – jest chroniona, kopiowanie kodu, layoutów, tekstów 1:1 lub w sposób zbyt podobny może naruszać prawa autorskie.

Dlatego software house, który odmawia przekazania kodu, zwykle ma do tego podstawę: chroni konkretny sposób realizacji Twojego pomysłu, a nie sam pomysł. Z drugiej strony, konkurent, który „inspiruje się” Twoim serwisem, ale przepisuje całe fragmenty frontendu lub tekstów, wchodzi już w strefę realnego ryzyka.

Co prawo autorskie chroni w IT oprócz kodu

Kod źródłowy to tylko jedna warstwa. W projektach IT pojawia się wiele elementów, które również są utworami lub są objęte pokrewną ochroną:

• grafika – logotypy, ikony, ilustracje, bannery, layouty ekranów, nawet proste „kafelki” interfejsu, jeśli są choć trochę oryginalne,
• UX/UI – układ elementów, charakterystyczne przejścia, animacje, oryginalne rozwiązania projektowe,
• teksty – treści w aplikacji, opisy funkcji, komunikaty błędów, maile transakcyjne, dokumentacja,
• bazy danych – struktura bazy (schema), zestawienie danych spełniające kryteria oryginalności, a nawet tzw. „baza danych sui generis”, gdzie chronione jest nie tyle autorstwo, co inwestycja w zebranie danych,
• pliki konfiguracyjne – jeśli są efektem twórczego wyboru i zestawienia ustawień, a nie najprostszej konfiguracji „z instrukcji”.

Do tego dochodzą:

• projekty graficzne i makiety (wireframes, mockupy),
• nagrania wideo – np. tutoriale produktowe,
• szablony dokumentów – umowy, regulaminy, polityki, tworzone na potrzeby systemu.

W praktyce, zamawiając system IT, warto jasno ustalić, czy nabywasz prawa albo licencje również do:

• layoutów i grafik,
• treści w systemie (np. tekstów automatycznych maili),
• struktury bazy danych i danych testowych,
• materiałów marketingowych wygenerowanych na potrzeby wdrożenia.

Kto jest „twórcą” w zespole IT i jak wygląda współautorstwo

W projektach IT rzadko mamy do czynienia z jednym autorem. Zwykle jest to zespół programistów, projektantów UX/UI, copywriterów, analityków. Prawo autorskie rozróżnia:

• współtwórców – osoby, które wnoszą własny wkład twórczy do jednego utworu (np. wspólnie tworzą kod aplikacji),
• twórców odrębnych części – kiedy każdy tworzy osobny utwór (np. osobny moduł, osobny zestaw ikon, osobny tekst).

Jeżeli kilka osób tworzy jeden utwór, mają współautorstwo i – co do zasady – wspólne prawa. Każdemu przysługuje udział (często po prostu równy, jeśli nic innego nie wynika z umowy). Do dysponowania takim utworem (np. sprzedaż, udzielenie licencji) zwykle potrzebna jest zgoda wszystkich współtwórców.

Dla zleceniodawcy czy właściciela firmy oznacza to, że:

• jeśli pracujesz tylko z freelancerami, bez jasnej umowy przekazującej prawa lub licencję, możesz mieć kilka osób roszczących sobie prawa do fragmentów systemu,
• przy projektach z udziałem wielu podwykonawców lepiej zadbać o to, by wszystkie prawa majątkowe lub szerokie licencje trafiały do Ciebie, a nie były rozproszone.

Czego prawo autorskie w IT nie obejmuje

Lista rzeczy, których prawo autorskie nie chroni, jest równie ważna jak lista tego, co jest chronione. Do obszarów pozostających poza ochroną należą m.in.:

• procedury i metody działania – np. model obsługi klienta, proces realizacji zamówienia, metodologia wdrożeniowa,
• algorytmy jako idee – ogólna zasada działania mechanizmu, np. sposób obliczania rabatu, sama koncepcja mechanizmu rekomendacji,
• wiedza ogólna – know-how, praktyczne doświadczenia, umiejętności programistów (mogą być objęte tajemnicą przedsiębiorstwa, ale nie prawem autorskim jako takim),
• prostota i banał – bardzo proste rozwiązania, które nie spełniają progu „twórczości i indywidualności” (choć tu granica jest płynna).

Przewaga konkurencyjna w IT często wynika nie tyle z samego kodu, ile z:

• danych (np. modele ML trenowane na unikalnych zbiorach danych),
• organizacji procesów i umów z klientami,
• integracji z innymi systemami,
• skalowalnej infrastruktury.

Te elementy najczęściej chroni się nie tylko prawem autorskim, ale też tajemnicą przedsiębiorstwa, umowami o poufności (NDA) i technicznymi środkami zabezpieczeń. Samo powoływanie się wyłącznie na prawo autorskie bywa złudzeniem bezpieczeństwa.

Własność vs licencja: dlaczego „kupując program”, zwykle go nie masz

Egzemplarz programu a prawa autorskie – dwie różne rzeczy

Kupując książkę w księgarni, stajesz się właścicielem egzemplarza, ale nie zyskujesz prawa do:

• drukowania jej w tysiącach kopii i sprzedaży jako własnej,
• tłumaczenia i wydawania pod własnym nazwiskiem,
• publikowania w całości w internecie.

Identycznie jest z oprogramowaniem. Własność egzemplarza (plików zainstalowanych na komputerze, pudełka z płytą, sprzętu z wgranym systemem) to jedno, a prawa autorskie i licencja – drugie. Najczęściej:

• jesteś właścicielem komputera,
• masz status licencjobiorcy programu,
• właścicielem praw autorskich jest producent oprogramowania lub jego licencjodawca.

Jeżeli nie ma wyraźnego przeniesienia praw autorskich (w umowie lub na fakturze z odpowiednim zapisem), to niemal na pewno masz tylko licencję na korzystanie, często z konkretnymi ograniczeniami.

Co naprawdę oznacza „kupno” pudełka, subskrypcji i SaaS

W IT używa się słowa „kupuję” bardzo swobodnie. W praktyce można mieć do czynienia z trzema typowymi modelami:

• oprogramowanie pudełkowe / do pobrania – płacisz jednorazowo za licencję (czasem wieczystą, czasem ograniczoną), ale prawa do kodu i marki pozostają przy producencie,
• subskrypcja – płacisz za czasowy dostęp do programu lub usługi, po wygaśnięciu subskrypcji tracisz prawo korzystania, aktualizacji, często także prawo komercyjnego użycia,
• SaaS („oprogramowanie jako usługa”) – w ogóle nie dostajesz programu do instalacji; korzystasz z usługi online, najczęściej bez prawa do kopiowania, modyfikacji i odsprzedaży.

W modelu SaaS firma technologiczna zachowuje pełną kontrolę nad oprogramowaniem i danymi, a Ty kupujesz usługę dostępu i przechowywania danych. Dlatego:

• nie możesz „sprzedać dalej” dostępu do aplikacji (chyba że licencja przewiduje reselling, multi-tenant itp.),
• zwykle nie masz prawa domagać się kodu źródłowego,
• przestajesz mieć legalny dostęp do systemu po zakończeniu umowy (choć co do danych – sytuacja jest bardziej złożona).

Domyślna ochrona ustawowa: brak licencji ≠ wolno wszystko

Częste błędne założenie: „autor nie napisał nic o prawach, więc mogę używać, jak chcę”. W prawie autorskim jest dokładnie odwrotnie. Brak informacji o licencji oznacza pełną, domyślną ochronę ustawową. Czyli:

• bez wyraźnej zgody autorskiej nie wolno kopiować, modyfikować, publicznie udostępniać, sprzedawać,
• legalne jest co najwyżej dozwolone użytkowanie prywatne – bardzo wąskie, zwykle ograniczone do użytku osobistego, w kręgu rodziny i znajomych.

Do legalnego korzystania w firmie potrzebujesz:

• licencji (np. EULA, regulamin, opis na stronie, który określa zasady korzystania), lub
• umowy (np. z software housem, freelancerem, dystrybutorem).

Jeśli nie wiesz, na jakich zasadach korzystasz z programu lub treści cyfrowych, to sygnał, że wypada:

• sprawdzić dokumentację licencyjną,
• poszukać informacji na stronie producenta,
• w ostateczności – zapytać dostawcę albo prawnika.

Jak rozumieć „wieczystą licencję”, „czasową licencję” i EULA

Kilka popularnych pojęć licencyjnych bywa intuicyjnie rozumianych inaczej, niż zakładają autorzy licencji:

• licencja wieczysta – oznacza, że możesz korzystać z danej wersji programu bez ograniczenia czasowego. Nie znaczy to:
  • gwarancji wsparcia technicznego „na zawsze”,
  • nieograniczonego prawa do aktualizacji,
  • prawa do rozpowszechniania dalej.
• licencja czasowa – uprawnia do korzystania przez określony okres (np. rok). Po tym czasie:
  • sam program może przestać działać,
  • albo korzystanie staje się nielegalne (nawet jeśli technicznie wciąż działa).
• EULA (End User License Agreement) – umowa licencyjna użytkownika końcowego. To właśnie w niej jest opisane, co możesz, a czego nie możesz robić:
  • czy wolno instalować na kilku komputerach,
  • czy wolno używać komercyjnie,
  • czy wolno wirtualizować system,
  • czy można przenieść licencję na inny podmiot.

Bez sięgnięcia do EULA lub innego opisu licencji wszelkie domysły w stylu „na pewno można” są ryzykowne. W sporach sądowych często to właśnie treść EULA decyduje o wyniku.

Przykład z praktyki: „program na własność”, ale bez prawa do modyfikacji

Modelowa sytuacja: firma zamawia system CRM „szyty na miarę” u software house’u. Sprzedawca mówi: „Po wdrożeniu będziecie mieć program na własność”. W umowie znajduje się jednak zapis:

• „Zamawiający otrzymuje niewyłączną licencję na korzystanie z Systemu w wersji produkcyjnej, bez prawa modyfikacji i rozpowszechniania”.

„Na własność” w marketingu vs „licencja” w umowie

W marketingu dominuje prosty przekaz: „program na własność”, „kup raz, używaj zawsze”. W dokumentach prawnych ten sam produkt opisują już dużo bardziej precyzyjnie. Zderzenie tych dwóch światów prowadzi do rozczarowań.

Kilka typowych niespójności:

• hasło sprzedażowe: „system jest Państwa” → w umowie: „licencja niewyłączna, nieprzenoszalna, bez prawa modyfikacji”,
• obietnica handlowca: „możecie go dowolnie rozwijać” → w załączniku: zakaz dekompilacji, zakaz udostępniania kodu podwykonawcom,
• prezentacja: „integrujemy wszystko w jednym miejscu” → w licencji: ograniczenia liczby instancji, serwerów, środowisk testowych.

W sporze liczy się nie slajd sprzedażowy, ale konkretny zapis. Jeżeli coś ma dla Ciebie kluczowe znaczenie (np. prawo modyfikacji, rozwijania systemu innym dostawcą, instalacja w chmurze), powinno być:

• wprost wpisane do umowy lub zamówienia,
• albo ujęte w aneksie modyfikującym standardową EULA.

Przy większych wdrożeniach zdrowy odruch to porównanie: co mówi oferta handlowa, a co mówi par. „Licencja” w umowie. Jeżeli to się nie klei, lepiej wyjaśnić to przed podpisaniem, a nie po pierwszej fakturze serwisowej.

Licencja wyłączna, niewyłączna i sublicencja – co to realnie zmienia

Trzy pojęcia, które w praktyce biznesowej pojawiają się często, ale są rozumiane po omacku:

• licencja niewyłączna – typowy przypadek przy gotowym oprogramowaniu. Możesz korzystać na określonych polach eksploatacji, ale autor może:
  • udzielać takich samych licencji innym klientom,
  • sam dalej używać i rozwijać system,
  • sprzedawać konkurencji rozwiązanie bardzo podobne do Twojego.
• licencja wyłączna – dużo dalej idące uprawnienia. Autor zobowiązuje się, że:
  • nie udzieli takiej licencji innym podmiotom na danym obszarze (np. branża, terytorium),
  • sam nie będzie korzystał w sposób sprzeczny z Twoją wyłącznością.

  W praktyce wyłączność jest często ograniczona – np. tylko na określonym rynku albo przez konkretny czas.

• sublicencja – prawo do „podawania licencji dalej”. Masz licencję od autora i możesz udzielać dalszych licencji swoim klientom, zwykle w określonych ramach.

Jeżeli prowadzisz firmę IT, która:

• sprzedaje swoje rozwiązanie dalej partnerom,
• buduje system „white label” dla innych marek,
• planuje model franczyzowy,

bez jasnej zgody na sublicencjonowanie możesz po prostu nie mieć podstawy, aby legalnie „opakować” system i odsprzedawać dostęp.

Z drugiej strony, jako klient końcowy często nie potrzebujesz ani wyłączności, ani prawa do sublicencjonowania. Wystarcza solidna, ale niewyłączna licencja na czas nieokreślony, z:

• prawem do modyfikacji (np. przez innych dostawców),
• prawem do korzystania w różnych środowiskach (produkcja, testy, backup),
• jasnymi zasadami przy zmianie organizacji (fuzje, przejęcia, zmiana nazwy firmy).

Podstawowe rodzaje licencji oprogramowania w ludzkim języku

Licencje komercyjne: klasyczny model „płacisz – korzystasz”

Większość znanych programów biurowych, księgowych czy specjalistycznych działa na licencji komercyjnej. Mechanizm jest prosty:

• płacisz (jednorazowo lub w abonamencie),
• dostajesz określone prawo korzystania,
• nie dostajesz praw do kodu ani do dalszej dystrybucji.

W obrębie licencji komercyjnych występuje kilka podtypów:

• per urządzenie – płacisz za każdy komputer / serwer,
• per użytkownik (seat) – limituje się liczbę osób, które mogą korzystać,
• per instancja / środowisko – np. osobna licencja na produkcję, testy, staging,
• per zakres funkcji – wersje „basic”, „pro”, „enterprise” z różnymi modułami,
• per użycie – np. opłata za liczbę przetworzonych dokumentów, API calli, GB danych.

Najczęstsza pułapka: kupujesz „10 licencji”, a w praktyce:

• masz 10 użytkowników nazwanych, ale nie 10 równoczesnych logowań,
• lub odwrotnie – licencja dotyczy tylko liczby sesji na raz, ale kont może być setki.

Bez przeczytania definicji „użytkownika” w umowie łatwo źle oszacować koszty i wejść w niezamierzone naruszenia.

Freeware, trial, freemium – „za darmo”, ale na ilu warunkach

Programy „za darmo” też podlegają licencjom. To, że nie płacisz pieniędzmi, nie znaczy, że nie obowiązują reguły:

• freeware – oprogramowanie darmowe do użytku, ale:
  • często tylko prywatnego,
  • albo niekomercyjnego,
  • czasem z zakazem integracji w produktach komercyjnych.
• trial – wersja testowa:
  • ograniczona czasowo (np. 14 dni),
  • lub funkcjonalnie (np. watermark, brak eksportu, limit plików).

  Po okresie testowym korzystanie bez opłaty zwykle staje się bezprawne, nawet jeśli technicznie program działa.

• freemium – część funkcji za darmo, reszta płatna. Granica między „free” a „pro” bywa płynna i rozwijana razem z produktem, co powoduje, że to, co kiedyś było darmowe, po czasie może zostać przeniesione do płatnego planu.

Jeśli instalujesz „darmowy” program w firmie, szczególnie do celów zarobkowych, warto sprawdzić, czy darmowość obejmuje zastosowanie komercyjne. Zapis typu „wyłącznie do użytku osobistego” wyklucza wykorzystanie w działalności gospodarczej.

Open source: nie „no rules”, tylko „inne reguły”

Oprogramowanie open source nie jest „pozbawione prawa autorskiego”. Jest licencjonowane inaczej. Autor udziela daleko idących swobód, ale w zamian oczekuje określonych zachowań.

Dwie główne rodziny licencji open source, które prowadzą do różnych skutków:

• licencje „copyleft” (np. GPL) – pozwalają korzystać, modyfikować i rozpowszechniać kod, ale:
  • jeżeli rozpowszechniasz dalej program oparty na takim kodzie, musisz udostępnić swój kod źródłowy na tej samej licencji,
  • to dotyczy zwłaszcza sytuacji, gdy przekazujesz program użytkownikowi (sprzedaż, dystrybucja, wydanie instalatora).
• licencje „permisywne” (np. MIT, BSD, Apache 2.0) – dają szerokie prawo korzystania, włączania do kodu zamkniętego, także komercyjnie, ale:
  • zachowują wymóg informacji o autorach (copyright notice),
  • często wymagają dołączenia treści licencji do produktu,
  • zawierają zrzeczenie odpowiedzialności (brak gwarancji).

Różnica praktyczna:

• MIT: możesz wziąć kod, wkomponować w komercyjny, zamknięty produkt, nie ujawniać swojego kodu, ale musisz zachować informacje o autorach,
• GPL: użycie w sposób „łączący” Twoją aplikację z kodem GPL i jej dalsza dystrybucja może wymusić otwarcie całego pochodnego kodu na GPL (co dla wielu firm jest nieakceptowalne).

„Proste” licencje MIT, BSD, Apache – swobody i haczyki

Licencje permistywne są uznawane za „proste” i „biznesowo przyjazne”. I rzeczywiście – dają dużą elastyczność, ale nie są białą kartką.

Przykładowe, często ignorowane obowiązki:

• MIT – wymóg zachowania informacji o prawach autorskich i licencji w kopiach oprogramowania. Jeśli sprzedajesz własną aplikację zawierającą komponent MIT, raczej nie możesz „wyczyścić” całkowicie oznaczeń w dokumentacji czy plikach licencji.
• BSD (2- i 3-klauzulowa) – podobnie jak MIT, ale starsze warianty zawierały dodatkowe zastrzeżenia reklamowe; przy projektach z długą historią trzeba sprawdzić dokładną wersję licencji.
• Apache 2.0 – poza klasycznymi zapisami:
  • reguluje również kwestie patentów – możesz korzystać z kodu wraz z określoną licencją patentową, ale naruszenie warunków może tę licencję unieważnić,
  • wymaga czytelnego oznaczenia zmian, jeśli modyfikujesz kod.

W praktyce, aby wdrażać biblioteki MIT/BSD/Apache w produkcie komercyjnym, przydaje się:

• lista użytych komponentów open source,
• mechanizm dołączania plików LICENSE / NOTICE w odpowiednim miejscu (np. w „O programie”, w dokumentacji lub jako osobny pakiet licencyjny),
• polityka aktualizowania i usuwania komponentów, których licencja się zmieniła lub wygasła dla danej wersji.

GPL i pokrewne: kiedy „za darmo” może kosztować najwięcej

Licencje z rodziny GPL (GPL, LGPL, AGPL) są najczęściej źle rozumiane przez biznes – właśnie dlatego, że są darmowe. Problemem nie jest cena, ale warunki.

Szkicowo:

• GPL (General Public License) – klasyczne „copyleft”. Jeżeli:
  • włączasz kod GPL do swojego programu w sposób „ściśle powiązany” (linkowanie, kompilacja itd.),
  • i ten program rozpowszechniasz (sprzedajesz, dajesz klientom do instalacji),

  to całość może być traktowana jako dzieło zależne i podlegać GPL, czyli:

  • musisz udostępnić kod źródłowy,
  • zezwolić innym na dalszą modyfikację i dystrybucję.
• LGPL (Lesser GPL) – łagodniejsza. Zwykle dotyczy bibliotek:
  • można je wykorzystywać w programach zamkniętych,
  • pod warunkiem m.in. możliwości podmiany biblioteki przez użytkownika (techniczne szczegóły są istotne).
• AGPL – „sieciowy” wariant GPL:
  • rozszerza obowiązki także na sytuacje, gdy program jest udostępniany jako usługa (SaaS),
  • czyli nawet jeśli nie przekazujesz kodu klientowi, ale umożliwiasz korzystanie przez sieć, możesz mieć obowiązek udostępnienia źródeł.

To nie są automatyczne „wyroki”; diabeł tkwi w szczegółach integracji. Jednak przy poważnych projektach komercyjnych włączenie komponentu GPL/AGPL bez analizy jest proszeniem się o problem:

• albo trzeba będzie otworzyć większą część stacku,
• albo później przepisywać newralgiczne moduły, żeby pozbyć się „toksycznego” komponentu.

Licencje Creative Commons: nie tylko zdjęcia i grafiki

Creative Commons (CC) kojarzy się głównie z fotografiami, grafikami i tekstami, ale w firmie IT pojawia się częściej, niż się wydaje – choćby w:

• dokumentacji produktowej,
• materiałach szkoleniowych i e-learningowych,
• szablonach prezentacji, ikonach, drobnych elementach UI.

Podstawowe warianty CC:

• CC BY – możesz używać, remiksować, także komercyjnie, ale z obowiązkowym wskazaniem autora.
• CC BY-SA – jak wyżej, ale z warunkiem „share alike”:
  • dzieła pochodne muszą być udostępniane na tej samej licencji,
  • to może być kłopotliwe np. przy tworzeniu płatnych materiałów szkoleniowych opartych na cudzych slajdach.
• CC BY-ND – zakaz tworzenia utworów zależnych („no derivatives”), czyli nie wolno modyfikować. Możesz udostępniać jako całość, z atrybucją.

CC BY-NC i CC BY-NC-SA – „niekomercyjnie”, czyli jak?

Oznaczenie „NC” (NonCommercial) brzmi prosto: nie wolno używać komercyjnie. W praktyce zaczynają się schody, bo interpretacja „komercyjności” nie zawsze jest oczywista.

• CC BY-NC – możesz korzystać i modyfikować, ale bez wykorzystania komercyjnego.
  • sprzedaż kursu, w którym są takie materiały, zwykle będzie komercją,
  • wrzucenie na blog firmowy obok reklam też może zostać uznane za użycie komercyjne,
  • użycie w intranecie firmy szkoleniowej pobierającej opłaty za szkolenia – także jest ryzykowne.
• CC BY-NC-SA – jak wyżej, z dodatkowym warunkiem „share alike” (ta sama licencja dla utworów zależnych).

CC celowo nie definiuje „komercyjności” w sposób księgowy. Chodzi raczej o kontekst: czy użycie ma związek z działalnością nastawioną na zysk, wizerunek, marketing. Spór pojawia się np. przy:

• organizacjach NGO finansowanych grantami – działają „nie dla zysku”, ale jednak realizują płatne projekty,
• uczelni prywatnej, która wykorzystuje slajdy w płatnych studiach podyplomowych – trudno bronić tezy, że to „niekomercyjne”.

Jeżeli materiał CC z klauzulą „NC” ma trafić do produktu, który w jakikolwiek sposób buduje przychód lub marketing firmy, lepiej przyjąć ostrożne założenie: to jest komercyjne użycie. Bezpieczniejsza jest wtedy inna licencja albo zakup materiału ze standardową licencją komercyjną.

CC0 i domena publiczna – kiedy „możesz wszystko” naprawdę oznacza prawie wszystko

Część twórców rezygnuje z większości praw i oznacza swoje materiały jako CC0 albo wskazuje, że znajdują się w domenie publicznej.

• CC0 – maksymalne zrzeczenie się praw, jakie prawo danego kraju dopuszcza:
  • możesz kopiować, modyfikować, sprzedawać,
  • bez obowiązku atrybucji (choć z powodów etycznych i śledzenia źródeł często warto ją i tak zostawić).
• Domena publiczna – wygasły majątkowe prawa autorskie (np. z powodu upływu czasu) lub nigdy nie powstały zgodnie z prawem danego kraju.

Typowe źródła nieporozumień:

• „domena publiczna” na jakimś portalu nie zawsze znaczy to samo, co prawna domena publiczna – czasem to tylko etykietka marketingowa,
• niektóre porządki prawne nie pozwalają twórcy na pełne zrzeczenie się praw osobistych (np. autorstwa), więc ktoś zawsze może chcieć być wskazany.

Przy wykorzystaniu zasobów oznaczonych jako CC0/domena publiczna dobrze jest:

• udokumentować źródło (zrzut ekranu z licencją w momencie pobrania),
• ustalić wewnętrzną regułę, że mimo braku obowiązku atrybucji, minimalne oznaczenie źródła i tak się pojawia – ułatwia to audyty i rozwiązywanie ewentualnych sporów.

Licencje w codziennej pracy biurowej: programy, pliki, multimedia

W większości firm IT największe ryzyko licencyjne nie wynika z jednego „toksycznego” komponentu, ale z tysięcy małych naruszeń w codziennych nawykach: kopiowaniu arkuszy, stocków, fontów, gotowych szablonów.

Oprogramowanie biurowe: więcej niż Word i Excel

Zestaw narzędzi „office” to dziś pakiet usług chmurowych, integracji i dodatków. Każdy z tych elementów ma swoją licencję, nawet jeśli sprzedawany jest pod jednym brandem.

Kilka punktów, które często przelatują pod radarem:

• subskrypcja przypisana do osoby – konto nie jest „ogólnofirmowe”:
  • logowanie jednym kontem przez kilka osób naraz to zwykle naruszenie,
  • przekazywanie hasła „bo tylko na tym koncie jest licencja” też jest zwykle zabronione.
• instalacje wielostanowiskowe – licencja bywa powiązana:
  • z liczbą urządzeń,
  • z liczbą użytkowników,
  • albo z konkretnym serwerem terminalowym.

  Bez przeczytania definicji „urządzenia” i „użytkownika” trudno poprawnie policzyć licencje.

• wtyczki i add-ony – dodatki do pakietu często mają osobne warunki:
  • darmowe dla jednego użytkownika, płatne przy wdrożeniu zespołowym,
  • czasem tylko do użytku wewnętrznego, bez prawa oferowania klientom jako elementu usługi.

Szablony, fonty, grafiki: pliki, które ludzie kopiują bez refleksji

Projektant wgrywa nowy font „kupiony na licencji komercyjnej”, dział marketingu powiela go w prezentacjach, a z czasem trafia on do materiałów klientów. Na końcu okazuje się, że licencja fontu obejmowała tylko jedną stację roboczą i brakowało zgody na osadzanie w PDF-ach do masowej dystrybucji.

Typowe obszary ryzyka:

• fonty:
  • część licencji obejmuje tylko użycie na określonej liczbie urządzeń,
  • część ogranicza embedowanie w dokumentach lub aplikacjach,
  • „free for personal use” nie przekłada się na prawo użycia w materiałach firmowych.
• stocki (zdjęcia, ikony, wideo):
  • licencja „standard” vs „extended” – często limituje liczbę kopii, format użycia (np. brak zgody na wykorzystanie w logo),
  • zabronione jest tworzenie produktów, które polegają głównie na tym stocku (np. sprzedawanie samego zdjęcia na koszulce bez istotnego przetworzenia).
• szablony prezentacji i dokumentów:
  • wiele marketplace’ów sprzedaje je z licencją na jednego „klienta końcowego”,
  • przerobienie szablonu i odsprzedaż klientowi jako „nasz firmowy template” bez odpowiedniej licencji może łamać warunki.

Minimum higieny to centralne repozytorium:

• z plikami dozwolonymi do użytku komercyjnego,
• z krótką notatką, skąd pochodzą i jaki typ licencji się z nimi wiąże.

Współdzielone dokumenty, arkusze i makra

Dzielenie się szablonem arkusza z makrami w zespole rzadko komukolwiek kojarzy się z prawem autorskim. Do czasu, aż taki arkusz zostanie dołączony do płatnego produktu jako „narzędzie analityczne”.

Kilka pytań, które dobrze sobie zadać:

• kto jest autorem szablonu/makra – pracownik, zleceniobiorca, podwykonawca?
• czy istnieje jakakolwiek umowa przenosząca prawa lub licencjonująca takie „drobne” utwory?
• czy ten arkusz zbudowano z wykorzystaniem cudzych fragmentów (np. kupionego template’u, kodu z forów, snippetów objętych licencją)?

Jeżeli firma zaczyna sprzedawać coś, co kiedyś powstało „wewnętrznie do użytku własnego”, przyda się weryfikacja:

• czy prawa autorskie do całości są uregulowane,
• czy nie wkradł się fragment kodu lub designu objętego licencją wykluczającą komercyjne użycie.

Projekty na zamówienie: kto ma prawa do stworzonego oprogramowania

Największe nieporozumienia pojawiają się tam, gdzie są trzy strony: klient, wykonawca i prawo. Klient zwykle zakłada, że „płaci, więc ma”, wykonawca zakłada, że „pisze, więc ma”, a prawo podpowiada trzecią odpowiedź: „to zależy od umowy i przepisów szczególnych”.

Utwór pracowniczy a dzieło podwykonawcy

Inaczej traktuje się kod napisany przez etatowego pracownika, a inaczej przez freelancera lub firmę zewnętrzną.

• Pracownik etatowy (umowa o pracę):
  • w wielu jurysdykcjach, przy utworach stworzonych w ramach obowiązków służbowych, majątkowe prawa autorskie przysługują z automatu pracodawcy (z zastrzeżeniem pól eksploatacji),
  • jednak nie zawsze dotyczy to wszystkich pól – np. dystrybucji na nowe media, modeli biznesowych nieznanych w chwili tworzenia,
  • bez jasnych zapisów w umowie pracodawca może mieć ograniczenia przy komercjalizacji w nowych kanałach.
• Podwykonawca / freelancer:
  • domyślnie zachowuje prawa autorskie, a klient dostaje tylko licencję w zakresie opisanym w umowie,
  • jeśli umowa milczy o przeniesieniu praw lub szerokiej licencji, klient może mieć tylko prawo do jednego sposobu użycia (np. wdrożenia dla siebie, bez dalszej odsprzedaży).

Stwierdzenie w umowie: „wykonawca przekazuje oprogramowanie” nie załatwia kwestii praw autorskich. Potrzebne są konkrety: czy następuje przeniesienie praw, czy tylko licencja, na jakich polach eksploatacji, w jakim zakresie terytorialnym i czasowym.

Przeniesienie praw vs licencja – dwa różne światy

Przy projektach „pod klienta” często miesza się dwa pojęcia: przeniesienie praw i udzielenie licencji. Z punktu widzenia prawa i biznesu to zasadnicza różnica.

• Przeniesienie praw majątkowych:
  • klient staje się właścicielem praw (w określonym zakresie – zależnie od umowy),
  • wykonawca traci możliwość korzystania z kodu jak z własnego aktywa (chyba że zastrzeżono licencję zwrotną),
  • zwykle wymaga formy pisemnej i wyraźnego wymienienia pól eksploatacji.
• Licencja:
  • wykonawca zachowuje prawa,
  • klient otrzymuje prawo korzystania w określony sposób (np. tylko wewnętrznie, tylko w jednym produkcie, bez sublicencji),
  • może być wyłączna lub niewyłączna; wyłączność dramatycznie zmienia wycenę i możliwości wykonawcy.

W praktyce:

• gdy klient chce bazować na oprogramowaniu jako na fundamencie własnego produktu SaaS – zwykle dąży do przeniesienia praw lub bardzo szerokiej, wyłącznej licencji,
• gdy kupuje rozwiązanie wdrożeniowe (np. CRM szyty pod niego), często wystarczy mu szeroka licencja na użytek własny – bez potrzeby „posiadania” kodu.

Standardowe komponenty vs „część dedykowana”

Większość firm software’owych ma własne biblioteki, moduły, frameworki, które wykorzystuje w wielu projektach. Do tego dochodzą komponenty open source. Klient z kolei zwykle oczekuje, że skoro płaci, to dostaje wszystko „na własność”.

Rozsądnym kompromisem jest rozwarstwienie:

• Komponenty własne wykonawcy – „klocki”, z których składa się projekt:
  • wykonawca zachowuje do nich prawa,
  • klient dostaje licencję (często niewyłączną) na korzystanie w ramach konkretnego systemu/produktu,
  • dzięki temu wykonawca może używać tych samych klocków w innych projektach.
• Część dedykowana – logika specyficzna dla klienta, integracje, konfiguracja:
  • tu częściej dochodzi do przeniesienia praw lub udzielenia szerszej licencji,
  • bo właśnie ta część tworzy unikalną wartość biznesową klienta.

Jeżeli umowa uznaje całość kodu za „utwór stworzony na zamówienie”, bez rozróżnienia warstw, wykonawca może przypadkiem oddać klientowi prawa do całego własnego stacku. To zwykle ani nie było intencją, ani nie jest wliczone w wycenę.

Open source w projektach na zamówienie

Jeśli w projekcie pojawiają się biblioteki open source, dochodzi kolejna warstwa: licencja autora biblioteki. Niezależnie od tego, jak umówią się klient z wykonawcą, nie mogą postanowieniami umownymi „unieważnić” licencji open source.

Kilka praktycznych scenariuszy:

• wykonawca używa biblioteki MIT:
  • może przenieść prawa do własnego kodu na klienta,
  • ale dołączona biblioteka nadal pozostaje na MIT, z obowiązkiem zachowania informacji o autorach,

  Najczęściej zadawane pytania (FAQ)

  Czy każdy program komputerowy jest automatycznie chroniony prawem autorskim?

  Tak, co do zasady program komputerowy jest chroniony od chwili jego stworzenia, o ile spełnia minimalny próg twórczości i indywidualności. Nie jest potrzebna żadna rejestracja ani „pieczątka z urzędu” – ochrona powstaje z mocy prawa.

  Wyjątkiem są sytuacje graniczne, gdy program jest banalnie prosty i sprowadza się do oczywistego rozwiązania, np. kilku linijek kodu „z tutoriala” przepisanych 1:1. W większości komercyjnych projektów IT nie ma jednak wątpliwości, że mamy do czynienia z utworem chronionym.

  Co dokładnie jest chronione w oprogramowaniu: pomysł, funkcjonalność czy kod?

  Prawo autorskie chroni konkretną formę wyrażenia, a nie sam pomysł czy funkcjonalność. Innymi słowy: chroniony jest kod źródłowy, konkretny projekt graficzny, teksty, grafiki, oryginalny układ interfejsu – czyli to, co można skopiować „piksel w piksel” lub „linijka w linijkę”.

  Nie są chronione same idee i ogólne rozwiązania biznesowe, np. „aplikacja do umawiania wizyt u fryzjera z powiadomieniem SMS”. Konkurencja może stworzyć system robiący dokładnie to samo, jeśli zrealizuje to innym kodem, innym interfejsem i własnymi treściami. Problem pojawia się wtedy, gdy podobieństwo jest tak duże, że wygląda na kopiowanie, a nie niezależne opracowanie.

  Czy kupując program lub dostęp SaaS „staję się właścicielem” oprogramowania?

  Najczęściej nie. Kupujesz egzemplarz (plik, dostęp do usługi, pudełko) i otrzymujesz licencję na korzystanie, ale prawa autorskie zostają przy producencie lub innym uprawnionym. To samo dotyczy SaaS – płacisz za usługę działającą na cudzej infrastrukturze, nie za kod jako taki.

  Żeby faktycznie stać się właścicielem autorskich praw majątkowych do programu, potrzebna jest wyraźna umowa przenosząca prawa, z wyszczególnieniem pól eksploatacji. Zwykła faktura z opisem „licencja na system X” zazwyczaj oznacza tylko prawo używania, nie pełną własność kodu.

  Kto jest właścicielem praw autorskich do programu stworzonego przez pracownika lub freelancera?

  W przypadku pracownika etatowego, przy spełnieniu ustawowych warunków, co do zasady autorskie prawa majątkowe do programu komputerowego przechodzą na pracodawcę w zakresie wynikającym z umowy o pracę i obowiązków służbowych. Mimo to dobrze jest to doprecyzować w dokumentach, bo szczegóły potrafią być sporne.

  Przy freelancerach i podwykonawcach nic nie „przechodzi automatycznie”. Jeśli w umowie nie ma klauzuli o przeniesieniu praw lub udzieleniu odpowiednio szerokiej licencji, prawa zostają u wykonawcy. Zleceniodawca ma wtedy bardzo ograniczone możliwości modyfikacji, dalszej odsprzedaży czy rozwijania systemu z inną firmą.

  Czy mogę skopiować layout, UX albo teksty z innej aplikacji, jeśli przepiszę kod samodzielnie?

  Samodzielne przepisanie kodu nie „oczyszcza” sprawy, jeśli kopiujesz chronione elementy formy. Layout ekranu, charakterystyczny interfejs, grafiki czy teksty to również utwory. Jeżeli bierzesz je praktycznie 1:1 lub w zbyt podobnej postaci, nadal możesz naruszać cudze prawa, nawet jeśli linijki kodu są Twojego autorstwa.

  Bezpieczniej jest traktować cudzą aplikację jako inspirację na poziomie idei i funkcjonalności: sprawdzić, co robi, ale projekt graficzny, treści oraz konkretny układ zaprojektować od zera. Im bardziej „rozpoznawalny” i oryginalny jest cudzy interfejs, tym niższa tolerancja na podobieństwa.

  Czy struktura bazy danych i pliki konfiguracyjne też podlegają ochronie?

  Mogą podlegać. Struktura bazy danych (schema) może być utworem, jeśli stanowi efekt twórczego, indywidualnego doboru i ułożenia elementów. Dodatkowo istnieje odrębna ochrona tzw. bazy danych sui generis, która nie dotyczy autorstwa, ale inwestycji w zebranie i utrzymanie danych.

  Pliki konfiguracyjne bywają na granicy: banalna konfiguracja według instrukcji zwykle nie jest utworem. Jednak złożone zestawienia ustawień, stworzone w wyniku eksperymentów i świadomych wyborów, mogą już podlegać ochronie. Przy istotnych projektach lepiej uregulować w umowie, kto ma prawa do schematu bazy, konfiguracji i danych testowych.

  Czego prawo autorskie w IT na pewno nie chroni i czym to zabezpieczać?

  Prawo autorskie nie obejmuje m.in. czystych idei, procedur i metod działania, ogólnych algorytmów w sensie koncepcji, wiedzy i doświadczenia zespołu (know-how) oraz rozwiązań tak prostych, że brak im cechy twórczości. To są najczęstsze obszary błędnych oczekiwań – wiele osób próbuje „opatentować” proces obsługi klienta prawem autorskim, co zwyczajnie nie działa.

  Te elementy zwykle zabezpiecza się inaczej: umowami o poufności (NDA), ochroną tajemnicy przedsiębiorstwa, ograniczaniem dostępu do wrażliwych informacji oraz rozwiązaniami technicznymi (np. kontrola dostępu, audyty). Prawo autorskie jest tylko jednym z klocków układanki, a nie uniwersalną tarczą na wszystko.