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 publ