Cel jest prosty: sprawdzić, czy elementy użyte przy tworzeniu strony WWW (szablon/motyw, fonty, ikony, biblioteki JS/CSS) są użyte legalnie, na jakiej licencji i z jakimi obowiązkami. Najwięcej problemów powstaje nie dlatego, że ktoś „kradnie”, tylko dlatego, że myli zakup z nabyciem praw, a „darmowe” z „bez warunków”.
Realne pytania, które zwykle padają przed publikacją strony: czy licencja motywu pozwala na użycie u klienta, ile wdrożeń obejmuje, czy wolno modyfikować i dalej sprzedawać, czy font można osadzić jako webfont i hostować samemu, czy ikony wymagają atrybucji i czy można ich użyć w logo, oraz co zrobić, żeby mieć dowody legalności, gdy ktoś zgłosi roszczenie.
Frazy pomocnicze: licencja motywu WordPress, single site vs unlimited sites, przeniesienie praw a licencja, fonty webfont vs desktop, self-hosting fontów a CDN, biblioteki ikon a atrybucja, ikony w logo licencja, licencje open source JS CSS, plik NOTICE i zachowanie copyright, audyt licencji strony internetowej, client work end product, dokumentacja licencji dla klienta
Najbezpieczniej przejść stronę „warstwami”, bo każda warstwa ma inne reguły licencyjne i inne typowe pułapki. Zacznij od tego, co najczęściej jest licencjonowane „na sztuki”: motyw/szablon (zwłaszcza z marketplace) i fonty (bo licencje webfont bywają inne niż desktop). Potem przejdź do ikon (w tym zestawów „free”) i bibliotek JS/CSS (licencje open source i obowiązek zachowania informacji).
Na końcu zostaw „materiały klienta”: logo, zdjęcia, teksty, mockupy. To osobna ścieżka, bo tu często wchodzą stocki, prawa do znaków, umowy z fotografem i zgody na wizerunek. W praktyce: nawet jeśli motyw i biblioteki są legalne, jedna grafika z wyszukiwarki potrafi zrujnować spokój projektu.
Dwa pytania kontrolne, które oszczędzają większość pomyłek
1) Czy to jest licencja czy przeniesienie praw? Zakup motywu, fontu czy zestawu ikon to zwykle licencja (czyli pozwolenie na użycie na określonych warunkach), a nie przeniesienie autorskich praw majątkowych. Z kolei umowa z wykonawcą strony może przewidywać przeniesienie praw do autorskiej warstwy (np. kodu i projektu UI stworzonego od zera), ale to nie „wchłania” praw do cudzych składników.
2) Czy wchodzisz w dystrybucję, czy tylko w wdrożenie/usługę? Wiele licencji dopuszcza użycie w projekcie klienta (client work / end product), ale zakazuje redystrybucji plików źródłowych jako produktu (np. odsprzedaż motywu, wrzucenie na własny marketplace, udostępnienie paczki „starter theme”). To rozróżnienie ma znaczenie nawet wtedy, gdy zmieniasz motyw „w połowie” — modyfikacja nie zawsze daje prawo do dalszej sprzedaży.
Szybkie mapowanie źródeł: skąd w ogóle pochodzą pliki
W 30 minut da się zwykle ustalić, skąd pochodzą kluczowe elementy i na jakich licencjach stoją. Najczęstsze źródła to: marketplace’y z motywami, repozytoria (GitHub), paczki (NPM), CDN, Google Fonts, oraz „gotowce” z kreatorów i page builderów. W praktyce mapowanie wygląda tak: sprawdzasz dokumentację projektu i repozytorium, a potem narzędziami przeglądarki identyfikujesz, co jest ładowane z zewnątrz.
Technicznie pomaga:
podgląd źródła strony i zakładka Network (czy fonty/ikony/biblioteki idą z CDN),
repozytorium (czy są pliki LICENSE, NOTICE, informacje o zależnościach),
panel CMS (jakie motywy/wtyczki są zainstalowane i skąd pochodzą),
faktury/potwierdzenia zakupów (czy licencja jest przypisana do wykonawcy czy klienta).
Najczęściej mylone założenia, które podbijają ryzyko
„Kupiłem = mam pełne prawa”. Kupno najczęściej oznacza licencję z ograniczeniami (np. liczba instalacji, zakaz sublicencji, obowiązek atrybucji). „Darmowe = bez warunków”. „Free” bywa „free with attribution”, „free for personal use”, albo „free” tylko w ograniczonym zakresie (np. brak prawa do użycia w logo). „Zmieniłem dużo = to już moje”. Duża liczba zmian nie kasuje praw autora pierwowzoru ani warunków licencji, zwłaszcza jeśli nadal wykorzystujesz istotne elementy.
Prawa autorskie do projektu strony vs licencje na elementy — praktyczne rozróżnienie
Licencja a przeniesienie autorskich praw majątkowych: co realnie zmienia
Licencja to zgoda na korzystanie z utworu na warunkach określonych przez licencjodawcę: pola eksploatacji, liczba instalacji, ograniczenia dystrybucji, czas, terytorium, obowiązek zachowania informacji o autorze i licencji. W realiach webowych licencja często mówi: „możesz wdrożyć na jednej domenie”, „możesz użyć w projekcie klienta”, „nie możesz odsprzedawać plików”.
Przeniesienie autorskich praw majątkowych (w relacji wykonawca–klient) dotyczy tego, co wykonawca faktycznie stworzył i może przenieść. Dobrze napisana umowa potrafi przenieść prawa do autorskiego layoutu i kodu, ale nie przeniesie praw do fontu kupionego na zewnętrznej licencji ani do ikon z biblioteki. Te elementy trzeba „przenieść” w inny sposób: poprzez przekazanie licencji, re-licencjonowanie, zakup na klienta albo udokumentowanie, że licencja obejmuje końcowego użytkownika.
Źródło: Pexels | Autor: Bibek ghosh
W praktyce warto rozróżniać: co jest utworem stworzonym w projekcie (np. autorski kod, customowe komponenty) a co jest włączone z zewnątrz (motyw, framework, font, ikony). To drugie rządzi się licencją, nawet jeśli jest „w paczce” i „działa razem”.
„Strona jako miks”: prawa do całości nie kasują licencji do części
Strona WWW to zwykle kompozycja: motyw + wtyczki + biblioteki JS + fonty + ikony + grafiki. Nawet jeśli wykonawca przenosi prawa do swojej pracy, to nie oznacza automatycznie, że klient dostaje prawo do każdego elementu w nieograniczonym zakresie. Klient dostaje to, co wynika z umowy i licencji elementów zewnętrznych.
Typowy błąd w komunikacji: „kupiliśmy stronę na własność”. Dla klienta to brzmi jak pełnia praw; prawnie to zwykle oznacza co najwyżej: przeniesienie praw do części autorskiej wykonawcy plus licencje do komponentów (często ograniczone). To nie musi być problem, o ile jest jasno opisane i udokumentowane.
Dwa podejścia do budowy strony i ich konsekwencje dla klienta
Podejście A: budowa na komponentach licencjonowanych (motyw/UI kit/biblioteki). Plusy: szybciej, taniej, przewidywalnie. Minusy: zależność od licencji, limity instalacji, czasem brak prawa do przeniesienia licencji, ryzyko „niedopasowania” licencji do modelu biznesowego klienta (np. wdrożenia wielodomenowe).
Podejście B: autorska warstwa wykonawcy + osobne licencje do zasobów. Plusy: klarownie da się rozdzielić prawa do kodu od licencji zasobów; łatwiej negocjować przeniesienie praw do autorskich elementów. Minusy: więcej formalności (kto kupuje fonty, kto trzyma dowody), czasem wyższy koszt, bo mniej „gotowca”.
Nie ma jednego „lepszego” modelu. Dla agencji ryzyko spada, gdy licencje są przypisane do projektów i klient dostaje paczkę dokumentów. Dla klienta komfort rośnie, gdy wie, co jest jego (autorskie elementy) a co jest licencjonowane (motyw/fonty/ikony) i jakie są ograniczenia.
Zapisy, które powinny paść w umowie lub protokole przekazania
Bez rozbudowanych paragrafów da się zabezpieczyć kluczowe kwestie. W praktyce w umowie/protokole warto mieć: kto odpowiada za zakup licencji do motywów/fontów/ikon, czy licencje są kupowane na wykonawcę czy na klienta, gdzie przechowywana jest dokumentacja oraz co z materiałami dostarczonymi przez klienta (oświadczenie, że ma prawa/licencje).
Jeżeli strona ma być rozwijana przez innego wykonawcę, opłaca się dodać zapis o przekazaniu: listy użytych komponentów, wersji, źródeł i licencji. To nie tylko „papiery” — to ułatwia aktualizacje i ogranicza ryzyko, że ktoś nieświadomie dołoży element na niekompatybilnej licencji.
Szablony i motywy (WordPress, HTML, UI kits): limity, praca dla klienta, modyfikacje i dystrybucja
Jak czytać licencję motywu, żeby wiedzieć, czy wolno użyć u klienta
Licencje motywów i szablonów bywają proste, ale klucz tkwi w słowach, które rozstrzygają, czy wolno i na jaką skalę. Szukaj wprost fraz typu: commercial use (użytek komercyjny), client work (praca dla klienta), end product (produkt końcowy), single site/single application (jedna instalacja), unlimited sites, agency/extended license, redistribution/resale (redystrybucja/odsprzedaż), sublicense (sublicencja), SaaS (użycie w usługach/produktach abonamentowych).
Jeżeli licencja mówi „single site”, to najczęściej oznacza jedną domenę (lub jedną instancję). Jeśli budujesz dla klienta i jednocześnie prowadzisz staging/development, sprawdź, czy licencja dopuszcza środowiska testowe albo „jedną produkcyjną instalację”. Niektóre licencje są tu liberalne, inne wymagają dodatkowych stanowisk/instalacji.
Osobna rzecz: regulamin marketplace a licencja produktu. Platforma może mieć swój model licencyjny (np. „standard/extended”), ale twórca może mieć dodatkowe warunki w paczce lub dokumentacji. Bezpieczniej traktować je łącznie: obowiązuje to, co jest wiążące dla danego zakupu i nie jest ze sobą sprzeczne. Gdy jest sprzeczność — rośnie ryzyko, że licencja jest niejasna, a wtedy lepiej doprecyzować u sprzedawcy albo zmienić komponent.
Single site vs unlimited sites vs extended/agency: kiedy dopłata ma sens
Single site jest OK, gdy robisz pojedynczą stronę dla jednego klienta i masz dobrą praktykę przypisywania licencji do projektu. Unlimited sites bywa lepsze dla agencji, która wdraża ten sam motyw wielokrotnie, ale tylko jeśli licencja rzeczywiście obejmuje client work i nie zabrania przeniesienia projektu jako „end product”. Extended/agency przydaje się, gdy licencja standardowa ma ograniczenia typu „tylko dla własnych projektów”, „bez projektów dla klientów”, albo gdy dopuszczasz model, który zahacza o dystrybucję (np. sprzedajesz gotowe pakiety stron).
Najprostsze kryterium: jeżeli motyw jest elementem „pipeline’u” (powtarzalny komponent w wielu realizacjach), to opłaca się mieć licencję, która ten model dopuszcza. Jeżeli motyw jest jednorazowy, single site jest zwykle wystarczające — pod warunkiem, że kupujesz osobną licencję per klient/per domena, zgodnie z warunkami.
W realnym wdrożeniu dopłata ma też sens wtedy, gdy klient oczekuje „swobody operacyjnej”: kilka domen (np. marka + landing), klon strony pod różne kraje, równoległe środowiska (dev/stage/prod) albo przejęcie projektu przez inny zespół. Tania licencja „single site” potrafi być świetna, dopóki nikt nie wpada na pomysł przeniesienia strony na drugą domenę „tymczasowo” albo uruchomienia kopii do A/B testów. Licencja nie pyta, czy to było na chwilę.
Różnicę robi też model przekazania. Są motywy, które pozwalają wykonać pracę dla klienta i oddać gotową stronę jako „end product”, ale zabraniają przekazywania samych plików motywu jako zasobu (np. paczki do dalszej odsprzedaży). Innymi słowy: klient może dostać działający serwis, ale niekoniecznie prawo do swobodnego wyciągania motywu i używania go w kolejnych projektach. Jeżeli klient chce mieć pełną kontrolę i „posiadanie” licencji na siebie, często najprościej jest kupić licencję bezpośrednio na konto klienta, a wykonawca działa wtedy jako implementator.
Praktyczny przykład z życia projektów: sklep na WooCommerce startuje na domenie testowej, potem wchodzi produkcja na właściwej domenie, a po miesiącu dochodzi subdomena kampanijna z tym samym motywem. W zależności od warunków licencji to może być nadal „jedna instalacja” albo już naruszenie (druga domena/instancja). Jeśli wiesz, że taki scenariusz jest realny, licencja „unlimited” lub „agency” jest często tańsza niż gaszenie pożaru po fakcie.
Gdy licencja jest niejednoznaczna, rozstrzygające bywa proste pytanie: czy klient ma być „licensed end user” i czy wolno mu kontynuować użycie bez wykonawcy. Jeśli odpowiedź brzmi „tak”, dopnij to na poziomie zakupu i dokumentów. A jeśli sprzedawca odpisuje wymijająco — to sygnał ostrzegawczy, że lepiej wybrać inny motyw niż budować na piasku.
Mini-checklista na domknięcie tematu: sprawdź, kto jest licencjobiorcą (wy czy klient), ile instalacji i domen obejmuje zakup, czy dozwolone są staging/dev, czy wolno przekazać projekt klientowi jako „end product” bez przekazywania samych plików do dalszej dystrybucji, oraz czy masz w jednym miejscu dowody zakupu i tekst licencji dla motywu, fontów i ikon.
Modyfikacje motywu a „moja wersja”: kiedy to dalej jest ten sam utwór
W praktyce większość wdrożeń polega na modyfikacji gotowego motywu: zmiana układu nagłówka, nowe komponenty, podmiana styli, dopisanie JS. To rodzi naturalne pytanie: czy po takich zmianach motyw staje się „mój” i mogę nim dysponować swobodniej?
Najbezpieczniejsze podejście jest proste: modyfikacje nie kasują oryginalnej licencji. Jeśli bazujesz na cudzym motywie, to nawet po dużych przeróbkach wciąż korzystasz z elementów chronionych (układ plików, kod, fragmenty CSS/JS, czasem grafiki). Możesz mieć prawa do własnych dopisków (jako osobnej warstwy), ale całość nadal podlega warunkom licencji bazowej.
Różnicę w ocenie ryzyka robi to, co faktycznie chcesz zrobić z przerobionym motywem:
Użycie u klienta jako „end product” – zwykle dozwolone, jeśli licencja pozwala na client work i nie przekraczasz limitów instalacji.
Wielokrotne użycie tej samej przeróbki – wchodzi temat „unlimited/agency” albo konieczność kupowania licencji per projekt.
Dystrybucja/sprzedaż dalej (np. jako własny motyw) – to najczęściej obszar zakazany w standardowych licencjach marketplace’ów, nawet jeśli „przerobiłeś wszystko”.
Jeżeli Twoim celem jest produkt do dalszej odsprzedaży lub udostępniania, opłaca się od razu wybrać bazę, której licencja to przewiduje (albo pisać motyw od zera). Przerabianie „pod dystrybucję” komponentu, który nie pozwala na redistribution, kończy się zwykle przepychanką mailową i nerwowym przepinaniem frontu na inny szkielet.
Motywy z elementami „w pakiecie”: slider, zdjęcia stockowe i ikony w paczce
Motyw może zawierać zasoby, które mają osobne licencje: fonty, ikony, zdjęcia demonstracyjne, a nawet płatne wtyczki „bundled”. To jest częsty punkt zapalny, bo kupujący zakłada: „skoro jest w paczce, to mogę używać”. Niestety, bywa odwrotnie: dema i assety są tylko do prezentacji, a komercyjne użycie wymaga osobnego zakupu.
Najpraktyczniejsza metoda weryfikacji to szybki przegląd plików motywu: license.txt, readme, katalogi typu assets, fonts, icons, a także dokumentacja online. Jeśli są zdjęcia stockowe, a w licencji jest zdanie w stylu „images are for preview only” – traktuj je jak rekwizyty. Zastąp je materiałami klienta albo własnymi, z jasną licencją.
Podobnie z „dołączoną” wtyczką premium: czasem jest legalnie dołączona do działania motywu, ale nie daje klientowi prawa do aktualizacji i supportu na własnym koncie. Z perspektywy zgodności prawnej to może być OK, ale z perspektywy utrzymania i bezpieczeństwa – już niekoniecznie. W protokole przekazania projektu dobrze rozdzielić: co jest „częścią wdrożenia”, a co jest „licencją klienta na update/support”.
Fonty na stronie: webfont vs desktop, self-hosting vs Google Fonts/CDN i ograniczenia w logo
Dwa światy licencjonowania: „desktop” a „webfont”
Fonty są jednym z najczęściej źle licencjonowanych elementów w projektach WWW, bo te same kroje występują w kilku modelach licencji. Najważniejsze rozróżnienie jest praktyczne, nie akademickie:
Licencja desktop dotyczy zwykle instalacji fontu na komputerze (np. do projektowania w Figma/Adobe) i używania go do tworzenia statycznych materiałów (grafiki, PDF, banery). Licencja webfont dotyczy osadzania fontu na stronie i serwowania go użytkownikom (czyli udostępniania plików .woff/.woff2 w przeglądarce).
To, że kupiłeś font „do użytku komercyjnego”, nie przesądza, że wolno Ci wrzucić go na serwer i dodać w CSS. W licencjach komercyjnych często webfont jest osobną pozycją (czasem liczona od domen, czasem od miesięcznych odsłon, czasem od „aplikacji”).
Self-hosting czy zewnętrzne hostowanie: jak to wpływa na zgodność
Technicznie można podpiąć fonty na dwa popularne sposoby: self-hosting (pliki fontów w repo/na serwerze klienta) albo hosting zewnętrzny (np. Google Fonts lub CDN dostawcy). Prawnie różnią się detalami, ale w audycie licencji liczą się trzy kwestie: czy licencja dopuszcza web embedding, czy wolno modyfikować pliki fontów (np. subsetting), i czy wolno je dalej rozpowszechniać.
Self-hosting daje kontrolę: łatwiej „zamrozić” wersję, spełnić wymagania prywatności i uniezależnić się od zmian u dostawcy. Z drugiej strony w self-hostingu częściej wchodzisz w obszar, w którym licencja wymaga spełnienia warunków dystrybucji (np. dołączenia pliku licencji do paczki, nieudostępniania fontu jako „standalone”).
Google Fonts (i podobne katalogi) są wygodne, bo typowo masz jasną informację o licencji (często SIL OFL lub Apache). Trzeba jednak sprawdzić dwa „haczyki praktyczne”: czy wybrany krój na pewno jest na licencji pozwalającej na użycie komercyjne i web embedding oraz czy sposób podpięcia (np. import z domeny zewnętrznej) jest akceptowalny u klienta z perspektywy polityki bezpieczeństwa/prywatności. To nie zawsze jest stricte problem prawa autorskiego, ale wpływa na to, jak finalnie wdrożysz fonty.
OFL, komercyjne EULA i „free for personal use”: szybkie rozpoznanie ryzyka
W projektach WWW najczęściej spotkasz trzy typy sytuacji:
1) SIL Open Font License (OFL). Zwykle bezpieczna do użycia komercyjnego i web, często dopuszcza modyfikacje (np. subsetting), ale ma warunki dotyczące nazewnictwa przy wersjach zmodyfikowanych i dystrybucji fontu. W praktyce: zachowaj plik licencji w projekcie i nie próbuj sprzedawać samego fontu jako produktu.
2) Komercyjne EULA od foundry. Najczęściej precyzuje: ile domen/aplikacji, czy wolno self-hostować, czy wolno użyć w logo, czy wolno przekazać pliki podwykonawcy. Tu nie ma skrótów – trzeba czytać warunki, bo różnice między EULA bywają większe niż różnice między samymi fontami.
3) „Free for personal use”. To czerwone światło w pracy dla klienta. Nawet jeśli font „ładnie wygląda” i „wszyscy go używają”, to personal use zwykle nie obejmuje strony firmowej, sklepu ani kampanii. Najprościej: wymienić na font z jasną licencją (OFL/Apache/komercyjną web).
Źródło: Pexels | Autor: Tranmautritam
Font w logo i identyfikacji: inna rozmowa niż font w CSS
Użycie fontu na stronie (renderowanie tekstu w przeglądarce) i użycie fontu do zbudowania znaku/logo to dwie różne półki ryzyka. Część licencji komercyjnych ma osobne zapisy o logo/trademark albo ogranicza tworzenie znaków opartych na kroju (np. wymóg modyfikacji liter, zakaz rejestrowania jako znaku towarowego bez zgody). W OFL zwykle możesz stworzyć logo, ale to nie rozwiązuje problemu podobieństwa do istniejących znaków – to już kwestia kolizji na rynku.
Jeśli klient zamawia logo i jednocześnie chcesz, by strona używała tego samego kroju jako webfont, najlepiej rozdzielić to w dokumentacji: jakiego fontu użyto w identyfikacji (projekt graficzny) i jakie fonty są osadzone na stronie (wdrożenie). Zdarza się, że dla logo kupuje się licencję desktop (projektant), a dla strony trzeba dokupić webfont (wdrożeniowiec). Brak tego rozdziału to klasyczny „niby wszystko jest kupione, ale nie to”.
Krótki przykład wdrożeniowy: font z Figmy a font na produkcji
Typowy scenariusz: projekt UI powstaje w Figmie na kroju, który projektant ma „na komputerze”, a front-end wchodzi w implementację i pobiera pliki z pierwszego lepszego źródła w sieci. Efekt: wizualnie jest dobrze, prawnie bywa źle – bo pliki użyte na produkcji nie mają nic wspólnego z licencją projektanta, albo pochodzą z miejsca, które nie daje prawa do komercyjnego web embed.
Prosty nawyk ogranicza problem: zanim font trafi do repozytorium, zapisz źródło (sklep/strona projektu), typ licencji (OFL/komercyjna), zakres (web/self-hosting/domeny) i dowód (faktura, mail, zrzut licencji z datą). To zajmuje kilka minut, a zwykle oszczędza wiele godzin „archeologii” po miesiącach.
Najczęściej zadawane pytania (FAQ)
Czy kupno motywu WordPress oznacza, że mam do niego pełne prawa?
Najczęściej nie. Kupno motywu zwykle daje licencję (pozwolenie na korzystanie na konkretnych warunkach), a nie przeniesienie autorskich praw majątkowych. To różnica jak między „mogę jeździć tym autem” a „jestem producentem i mogę sprzedawać kopie”.
W praktyce licencja może ograniczać liczbę wdrożeń, sposób użycia u klienta (client work / end product) i zakazywać redystrybucji plików źródłowych (np. wrzucenia motywu do własnej paczki starterowej).
Licencja motywu: co oznacza „single site” a co „unlimited sites”?
„Single site” (albo „1 site / 1 domain”) to zazwyczaj prawo do użycia na jednej instalacji lub jednej domenie. „Unlimited sites” pozwala wdrażać ten sam motyw wielokrotnie, ale nadal w ramach warunków licencji (np. zakaz dalszej odsprzedaży plików motywu).
Pułapka: czasem „unlimited” dotyczy tylko wdrożeń wykonawcy, a nie przenoszenia licencji na klientów. Jeśli strona ma zmieniać wykonawcę albo być kopiowana na kilka domen klienta, warto sprawdzić, czy licencja to obejmuje.
Czy mogę modyfikować motyw i potem sprzedawać go dalej jako swój?
Zależy od licencji, ale bardzo często odpowiedź brzmi: możesz modyfikować na potrzeby wdrożenia, natomiast nie możesz dystrybuować plików motywu jako produktu (np. sprzedać „przerobionej wersji” lub udostępniać paczki do pobrania).
Samo „dużo zmian” nie kasuje praw autora pierwowzoru ani ograniczeń licencyjnych. Krytyczne rozróżnienie to: wdrożenie/usługa vs redystrybucja (sprzedaż, publikacja, udostępnianie źródeł).
Czy font mogę legalnie osadzić jako webfont i hostować samemu (self-hosting), czy tylko z CDN?
To zależy od licencji fontu. Część fontów ma osobną licencję na desktop (np. do projektów w aplikacjach) i osobną na webfont (osadzanie na stronie przez CSS i serwowanie użytkownikom). To, że font działa technicznie jako webfont, nie znaczy jeszcze, że licencja na to pozwala.
Różnica self-hosting vs CDN bywa drugorzędna wobec kluczowego pytania: czy licencja dopuszcza publiczne udostępnianie plików fontu w ramach działania strony. Przy fontach „free” zdarza się też ograniczenie typu „free for personal use” albo zakaz użycia w znaku/logo.
Czy darmowe ikony trzeba podpisywać (atrybucja) i gdzie to wstawić na stronie?
„Free” często oznacza „bez opłaty”, ale z warunkami. Najczęstszy warunek to atrybucja, czyli podanie autora/źródła i licencji. Jeśli licencja tego wymaga, brak podpisu może być naruszeniem mimo legalnego pobrania.
Gdzie to umieścić? Zależy od warunków, ale w praktyce spotyka się:
stopkę (np. link do biblioteki ikon i licencji),
podstronę „Licencje” / „Credits”,
plik w repozytorium typu NOTICE lub sekcję w README (gdy to projekt webowy rozwijany w zespole).
Czy mogę użyć ikon z biblioteki (np. „free pack”) w logo firmy?
Często nie jest to takie proste. Wiele zestawów ikon pozwala na użycie w interfejsie strony, ale wyłącza użycie w znakach towarowych/logo albo nakłada dodatkowe warunki. Dla logo ryzyko jest większe, bo wchodzi też temat identyfikacji marki i ewentualnej rejestracji znaku.
Jeśli ikona ma być elementem logo, bezpieczniejsze są dwa podejścia: (1) kupno licencji, która wprost dopuszcza użycie w logo, albo (2) zaprojektowanie autorskiego znaku od zera i przeniesienie praw w umowie z projektantem.
Jak w 30 minut zrobić szybki audyt licencji strony i mieć dowody legalności?
Najlepiej iść „warstwami”: motyw → fonty → ikony → biblioteki JS/CSS → materiały klienta. Celem jest ustalenie źródeł i licencji oraz zebranie dowodów, zanim pojawi się zgłoszenie roszczeń.
Mini-checklista (do odhaczenia):
Sprawdź w panelu CMS/repo: skąd jest motyw/wtyczki, czy są pliki LICENSE/NOTICE.
W DevTools (Network / Source) zobacz, co leci z CDN (fonty, ikony, biblioteki) i z jakich domen.
Zbierz potwierdzenia: faktury, maile, ID zamówień, screen licencji/warunków (ważne: licencja często się zmienia).
Zapisz listę komponentów z wersjami i licencjami; jeśli biblioteka wymaga zachowania informacji copyright, dodaj NOTICE lub odpowiednią sekcję w dokumentacji.
Od klienta weź oświadczenie, że ma prawa do dostarczonych materiałów (logo, zdjęcia, teksty) albo że przekazał licencje/zgody.
Najważniejsze wnioski
Sprawdzanie legalności składników strony działa najlepiej „warstwami”: motyw/szablon → fonty → ikony → biblioteki JS/CSS → materiały klienta; każda warstwa ma inne typowe pułapki i inne obowiązki licencyjne.
Zakup prawie zawsze oznacza licencję, nie przeniesienie autorskich praw majątkowych — a licencja bywa ograniczona (np. jedna domena vs unlimited sites, określone pola eksploatacji, zakaz sublicencji).
Kluczowe rozróżnienie to wdrożenie/usługa vs dystrybucja: wiele licencji pozwala zrobić „end product” dla klienta, ale zabrania odsprzedaży paczki źródłowej (np. starter theme, motyw wrzucony na własny marketplace), nawet jeśli motyw był mocno zmieniany.
„Free” nie znaczy „bez warunków”: zestaw ikon może wymagać atrybucji albo zabraniać użycia w logo, a font może mieć osobne zasady dla desktop vs webfont (osadzanie, self-hosting, limit odsłon, zakaz użycia przez CDN).
Zmiany w kodzie lub grafice nie kasują cudzych praw: duża modyfikacja nie daje automatycznie prawa do dalszej sprzedaży ani do ignorowania warunków licencji pierwowzoru.
Dowody legalności są równie ważne jak sama licencja: trzymaj faktury/potwierdzenia, zapis licencji (LICENSE/NOTICE), źródła pobrania i informację, czy licencja jest na wykonawcę czy na klienta — to zwykle rozstrzyga spór szybciej niż dyskusja „kto miał rację”.
Źródła informacji
Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. ISAP – Kancelaria Sejmu RP – Podstawy: utwór, licencje, przeniesienie praw, pola eksploatacji, dozwolony użytek.
Dyrektywa 2009/24/WE Parlamentu Europejskiego i Rady z dnia 23 kwietnia 2009 r. w sprawie ochrony prawnej programów komputerowych. EUR-Lex (2009) – Zasady ochrony i licencjonowania oprogramowania; istotne dla bibliotek JS/CSS.
GNU General Public License, version 2. Free Software Foundation (1991) – Warunki GPLv2: dystrybucja, obowiązki licencyjne, zachowanie informacji o prawach.
The MIT License. Open Source Initiative – Treść licencji MIT; typowa dla bibliotek webowych, obowiązek zachowania copyright.
