Co tak naprawdę jest „cudzą grafiką” i „fontem” w kontekście aplikacji
Jakie elementy UI podlegają ochronie prawnoautorskiej
W aplikacjach pojawia się wiele elementów wizualnych, które dla prawa autorskiego są utworami. Utwór to każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci. W praktyce oznacza to, że większość rzeczy przygotowanych przez grafika, ilustratora czy UI designera będzie chroniona.
Najczęściej chronione elementy w interfejsie aplikacji to między innymi:
Ikony – o ile nie są to proste strzałki czy kwadraty, ale autorskie zestawy ikon o rozpoznawalnym stylu.
Ilustracje – onboarding, puste stany, grafiki promocyjne wewnątrz aplikacji, grafiki w tutorialach.
Layouty ekranów – specyficzny, oryginalny układ elementów, nietypowe kompozycje, charakterystyczne połączenie kolorów i kształtów.
Ochrona nie dotyczy samej idei (np. „lista kart z zaokrąglonymi rogami”), ale tego, w jaki sposób jest zrealizowana. Dlatego dwa różne zespoły mogą stworzyć listę kart, ale jeśli jeden z nich skopiuje dokładnie wygląd drugiego – z marginesami, cieniami, kolorami i proporcjami – może to naruszać prawa autorskie.
Inaczej traktowane są elementy systemowe. Standardowe komponenty z bibliotek typu Material Design, Human Interface Guidelines czy Fluent UI zazwyczaj nie są same w sobie chronione jako dzieła (lub są udostępniane na otwartych zasadach przez dostawcę systemu). Ochronie mogą jednak podlegać konkretne zestawy ikon lub motywów graficznych, jeśli ich autor tak zdecydował i licencja to precyzuje.
Font vs plik graficzny – różne reżimy prawne
Font i grafika mogą wyglądać podobnie z perspektywy użytkownika (oba to „coś wizualnego”), ale prawnie bywają traktowane odmiennie. Font to w większości jurysdykcji rodzaj oprogramowania – pakiet plików TTF/OTF/WOFF zawierający zdefiniowane znaki, funkcje kerningu, ligatury i inne dane. Zazwyczaj jest objęty ochroną jak software, a do jego użycia stosuje się licencję EULA (End User License Agreement) specyficzną dla danego foundry.
Plik graficzny (PNG, JPG, SVG, WebP) to typowy utwór graficzny. Można nim zarządzać przez licencje podobne do licencji na fotografie czy ilustracje stockowe: licencje royalty-free, rights-managed, licencje CC, licencje niestandardowe od grafików. Nie ma tu pojęcia „instalacji” na urządzeniu, jest za to kwestia „pola eksploatacji”, czyli gdzie grafika może zostać użyta: w aplikacji mobilnej, na stronie, w kampanii reklamowej, w druku itd.
W kontekście aplikacji mobilnej lub webowej:
Dodanie pliku PNG/SVG do assets to dystrybucja utworu graficznego razem z oprogramowaniem.
Dodanie pliku fontu TTF/OTF/WOFF to dystrybucja oprogramowania (fontu) razem z aplikacją lub hostowanie go na serwerze (webfont).
Z tego wynika, że licencje na grafiki i licencje na fonty mają inne typowe ograniczenia. Fonty częściej zawierają limity dotyczące liczby instalacji, liczby aplikacji, liczby użytkowników, liczby „page views” czy sposobu embedowania. Grafiki częściej ograniczają możliwość użycia w produktach do dalszej odsprzedaży (templates, UI kits dla innych).
Elementy, które zazwyczaj nie są chronione oraz te z dużą „twórczością”
W UI istnieje grupa elementów, które zwykle nie korzystają z ochrony prawnoautorskiej, bo są zbyt proste lub typowe. Należą do nich między innymi:
Proste geometryczne kształty (prostokąty, okręgi, linie) bez oryginalnego stylu.
Bardzo standardowe przyciski, oparte wyłącznie na wytycznych systemu (np. podstawowy „Primary Button” z Material Design).
Ikony funkcyjne o całkowicie standardowej formie, powtarzającej się w dziesiątkach miejsc (np. klasyczna ikonka dyskietki na zapis, bez żadnej indywidualizacji).
Po drugiej stronie są elementy, w których twórczość jest widoczna na pierwszy rzut oka:
Autorskie zestawy ilustracji onboardingowych, zaprojektowane pod konkretną markę.
Ikony w unikalnym stylu (specyficzna grubość linii, sposób stylizacji postaci, charakterystyczne proporcje).
Nietypowe layouty i animacje, tworzące rozpoznawalny „signature look” aplikacji.
W pierwszej grupie proste zbliżenie się do istniejącego wzorca najpewniej nie narusza prawa. W drugiej – dosłowne kopiowanie jest wysoce ryzykowne. Z punktu widzenia devów bezpieczniej jest opierać się na bibliotekach i systemach designu, które są oficjalnie udostępnione na przejrzystych licencjach (np. Material Icons), niż kopiować coś przypadkowo znalezionego w innej aplikacji lub dribbble shotach.
Przykładowo: standardowy przycisk w stylu Material można odtworzyć w swojej aplikacji, bo opiera się na publicznym design systemie Google. Natomiast autorski zestaw ilustracji onboardingowych stworzony przez zewnętrznego grafika dla innej aplikacji jest jednoznacznie chroniony i nie wolno go kopiować ani „podkradać” z APK/UI kitów.
Podstawy prawa autorskiego, które dev musi ogarnąć (bez prawniczego żargonu)
Autorskie prawa osobiste i majątkowe w projekcie IT
Prawo autorskie dzieli się na osobiste i majątkowe. To rozróżnienie ma duże znaczenie, gdy korzystasz z cudzych grafik czy fontów.
Autorskie prawa osobiste to m.in. prawo do:
podpisywania utworu imieniem i nazwiskiem (autor ma prawo do autorstwa),
nienaruszalności formy i treści utworu (zakaz „niszczenia” dzieła),
decydowania o pierwszym udostępnieniu utworu publiczności.
Są niezbywalne. Nie można ich sprzedać, a jedynie zgodzić się na określone wykorzystanie utworu w umowie lub licencji. W praktyce aplikacyjnej częściej operujesz na autorskich prawach majątkowych, bo to one decydują, czy możesz w ogóle użyć grafiki lub fontu.
Autorskie prawa majątkowe to prawo do zarabiania na utworze. Autor (lub podmiot, który od niego te prawa kupił) decyduje:
gdzie utwór może się pojawić (np. w aplikacji mobilnej, w reklamie, na stronie),
na jak długo, w jakim zakresie terytorialnym, w jakiej liczbie egzemplarzy,
czy można tworzyć modyfikacje, przeróbki, adaptacje.
W projektach IT korzystasz najczęściej z licencji, czyli pozwolenia na korzystanie z cudzego utworu na ściśle określonych zasadach. Czasami (np. gdy zatrudniasz grafika na umowę o pracę lub podpisujesz umowę o przeniesienie praw) otrzymujesz pełne prawa majątkowe do utworu i możesz nim dysponować szerzej – ale tylko jeśli jest to wyraźnie zapisane.
Licencja vs przeniesienie praw – co masz „w ręku” jako dev
W relacjach z grafikami, UX designerami i dostawcami fontów powtarza się ten sam schemat: albo dostajesz licencję, albo przeniesienie praw (często nazywane „cesją”). To nie są synonimy.
Licencja – autor lub właściciel praw pozwala ci korzystać z utworu w określony sposób, ale dalej pozostaje jego właścicielem. W licencji mamy zdefiniowane pola eksploatacji (np. „w aplikacjach mobilnych, na całym świecie, bez limitu instalacji”), terytorium, czas, możliwość sublicencji, zasady modyfikacji itp.
Przeniesienie praw majątkowych – autor oddaje tobie (lub twojej firmie) swoje prawa majątkowe w określonym zakresie. Stajesz się właścicielem tych praw i możesz licencjonować utwór innym, sprzedawać go dalej, umieszczać w różnych produktach.
Z perspektywy dewelopera często wystarczy dobra licencja, nie ma potrzeby kupowania wszystkiego „na własność”, bo to kosztuje więcej. Przeniesienie praw bywa korzystne, gdy:
budujesz własny produkt SaaS,
chcesz używać danego zestawu ilustracji/fontów w wielu różnych projektach,
planujesz sprzedawać szablony, UI kity, biblioteki komponentów innym firmom.
Przy stockach (grafiki i fonty) dostajesz prawie zawsze licencję, nigdy przeniesienia praw. Licencja określa, czy możesz użyć zasobu w aplikacji komercyjnej, i w jaki sposób. Przy współpracy z freelancerem lub agencją graficzną możesz negocjować: albo licencja na produkt (tańsza), albo pełne przeniesienie praw (droższe, ale bardziej elastyczne w długim terminie).
„Dozwolony użytek”, cytat, parodia – dlaczego w komercyjnej aplikacji to iluzja bezpieczeństwa
W polskim (i europejskim) prawie funkcjonują pojęcia takie jak dozwolony użytek osobisty, prawo cytatu, parodia. W kontekście komercyjnych aplikacji najczęściej są bezużyteczne jako „parasol ochronny”.
Dozwolony użytek osobisty – pozwala na korzystanie z utworów w kręgu rodziny i bliskich znajomych, nie dotyczy działalności zarobkowej. Aplikacja sprzedawana w sklepach, SaaS czy nawet darmowa aplikacja z reklamami zdecydowanie wypadają poza ten zakres.
Prawo cytatu – pozwala na przytoczenie fragmentu utworu w ramach np. krytyki, analizy, nauczania. Wymaga spełnienia kilku warunków (cel, zakres, oznaczenie autorstwa). Użycie cudzej ilustracji lub ikony jako elementu UI nie ma charakteru cytatu.
Parodia – to specyficzna forma twórczości, bazująca na cudzym utworze, ale z celem humorystycznym. Interface aplikacji rzadko mieści się w tej kategorii.
Innymi słowy: jeżeli aplikacja ma choć minimalny aspekt komercyjny (przychody, promocja biznesu, dane użytkowników jako wartość), nie ma sensu liczyć na któryś z powyższych wyjątków. Podstawą musi być licencja lub posiadanie praw majątkowych.
Inspiracja vs kopiowanie – praktyczna granica dla devów
Inspiracja cudzym interfejsem, stylem ikon czy typografią jest normalna. Problem zaczyna się tam, gdzie inspiracja staje się kopiowaniem. W uproszczeniu: inspiracja to wykorzystanie idei i przepisanie jej własnym językiem wizualnym, a kopiowanie to przejęcie konkretnego wyrazu tej idei.
Przykłady:
„Chcemy, żeby nasza aplikacja miała onboarding w stylu X: lekkie ilustracje, pastelowe kolory, krótkie hasła.” – inspiracja. Robicie własny set ilustracji, być może na bazie darmowych bibliotek lub we współpracy z grafikiem.
„Podoba nam się onboarding z aplikacji Y, wyciągnij grafiki z APK i podmień logo.” – kopiowanie. To prosta droga do zarzutu naruszenia praw autorskich.
„Ikony mają być w duchu Material Icons, ale ciut grubsza linia, inny rozmiar siatki, trochę inne proporcje.” – inspiracja w nurcie stylistycznym.
„Ściągnij paczkę ikon z aplikacji konkurencji, przerób dwa piksele i użyj.” – kopiowanie, i to raczej łatwe do udowodnienia.
Bezpieczne podejście dla devów: korzystać wyłącznie z zasobów, do których są jasne licencje, lub z materiałów przygotowanych na zlecenie (z odpowiednio skonstruowaną umową). „Podoba mi się, więc to wezmę” w świecie digitalu zwykle kończy się źle, szczególnie przy rosnącej popularności narzędzi do wykrywania kopiowanych grafik czy fontów.
Źródło: Pexels | Autor: RDNE Stock project
Legalne źródła grafik: stocki, darmowe bazy, open source
Płatne stocki – gdzie są haczyki w regulaminach
Płatne banki zdjęć i ilustracji (Adobe Stock, Shutterstock, iStock, Envato, Creative Market i dziesiątki innych) są wygodnym źródłem grafik do aplikacji. Jednak licencje tych serwisów różnią się szczegółami. Kluczowe pytanie: czy konkretna licencja pozwala na wykorzystanie grafiki w aplikacji, a jeśli tak – w jakiej skali i formie.
Najczęściej spotykane typy licencji stockowych:
Standardowa licencja – pozwala na użycie w projektach komercyjnych, ale z ograniczeniami: brak możliwości dalszej odsprzedaży pliku „as is”, limity liczby egzemplarzy, brak zgody na użycie w aplikacjach, które pozwalają użytkownikom pobierać lub odtwarzać odrębne pliki graficzne.
Rozszerzona licencja, licencja aplikacyjna i „asset in a box”
Przy stockach grafiki do aplikacji problem zaczyna się wtedy, gdy twoja appka staje się czymś więcej niż tylko „miejscem wyświetlania obrazka”. Jeśli użytkownik może:
pobrać grafikę jako osobny plik,
użyć jej dalej (np. w swoich projektach, wydrukować, podmienić tekst),
eksportować elementy UI z twojej aplikacji,
to większość standardowych licencji będzie za słaba. Serwisy nazywają to różnie – „extended license”, „enhanced license”, „app license”, „multi-use license” – ale sens jest podobny: płacisz więcej, dostajesz więcej uprawnień.
Najczęstszy zapis, który powinien zapalić lampkę devowi:
„You may not use the asset in a product whose main value is the asset itself.”
Przykład z życia: budujesz prosty generator tapet na telefon. Użytkownik klika „generate”, wybiera gotowe ilustracje z biblioteki i zapisuje na dysku. Jeśli te ilustracje są ze stocka na standardowej licencji, bardzo łatwo złamać warunek „głównej wartości”. Wtedy trzeba kupić rozszerzoną licencję albo zrezygnować z takich zasobów i szukać pakietów z wyraźnym pozwoleniem na użycie w aplikacjach.
Bezpieczniejszy jest scenariusz, w którym stockowe grafiki są częścią interfejsu, a nie głównym „produktem” – onboarding, ilustracje w tutorialach, tła w zakładkach itp. Nawet wtedy opłaca się:
sprawdzić limit instalacji / użytkowników (czasem jest zapis o liczbie „end users”),
upewnić się, że licencja obejmuje aplikacje mobilne i webowe, a nie tylko „strony www”,
zapisać w dokumentacji projektu, z którego konta kupiono asset i jaką licencję wybrano (przy audycie po latach to złoto).
Darmowe bazy grafik – darmowe nie znaczy „bez warunków”
Freepik, Unsplash, Pexels, Pixabay i podobne serwisy to kuszący skrót: zero kosztu, ogromna baza. Problem jest jeden – każdy z nich ma własną licencję serwisową, która bywa ostrzejsza niż typowe licencje open source.
Kilka typowych ograniczeń w darmowych bazach:
zakaz używania grafik w logotypach i znakach towarowych,
zakaz tworzenia konkurencyjnych baz/stocków z wykorzystaniem tych materiałów,
wymóg przypisania (attribution) – np. nazwa autora + link do serwisu,
zakaz „standalone file download” – użytkownik nie może dostać samego pliku PNG/JPG z twojej aplikacji jako głównej wartości.
Jeśli robisz budżetową aplikację MVP, często rozsądniej jest:
wziąć prosty płatny pakiet ilustracji z jasną licencją app/web (np. z Envato Elements, UI8, Setproduct),
niż budować cały interfejs na „free-only” i potem sprzątać chaos licencyjny przy pierwszym poważnym kliencie.
Dla prostych case’ów (np. internal tool, aplikacja demonstracyjna na konferencję) darmowa baza jest OK, ale warto od razu:
prowadzić listę użytych grafik z linkami do źródeł,
zapisać, czy wymagają atrybucji i w jakiej formie (czasem wystarczy mention w „O aplikacji”).
Grafiki na licencjach open source / Creative Commons
Grafiki na licencjach Creative Commons i podobnych (np. niektóre zestawy ikon na GitHubie) da się używać w aplikacjach dość swobodnie, ale kluczowa jest konkretna odmiana licencji.
Najczęstsze warianty CC w kontekście grafik:
CC0 – praktycznie domena publiczna. Można używać komercyjnie, modyfikować, nie trzeba oznaczać autora (choć często jest to mile widziane). Idealne na start, gdy budżet jest zerowy.
CC BY – wymaga oznaczenia autorstwa. Trzeba gdzieś umieścić info o autorze i licencji, np. w sekcji „Credits”. W aplikacjach B2B to zwykle akceptowalne, w produktach mocno konsumenckich czasem nie pasuje do estetyki.
CC BY-SA – „share alike”, czyli jeśli zmodyfikujesz grafikę i ją rozpowszechniasz, musisz udostępnić ją dalej na tej samej licencji. W zwykłej aplikacji, gdzie grafiki są jedynie elementem interfejsu, rzadko stanowi to problem, ale przy pakietach UI lub „component libraries” sprzedawanych dalej robi się kłopot.
CC BY-NC – zakaz użycia komercyjnego. Dla aplikacji zarabiających choćby na reklamach, subskrypcjach czy sprzedaży danych – odpada.
Bezpieczny pattern dla devów:
do komercyjnych aplikacji brać CC0 lub CC BY,
unikać NC (Non-Commercial) oraz ND (No Derivatives), jeśli grafiki mają być zmieniane lub integrowane w bardziej złożony UI.
Jeśli grafika pochodzi z repo na GitHubie lub Figma Community, licencja bywa opisana w README lub opisie pliku. Brak licencji nie znaczy „free do what you want” – wtedy formalnie wszystkie prawa są zastrzeżone i taka grafika jest tak samo chroniona jak dowolna praca komercyjna.
Grafiki generowane przez AI – kto ma do nich prawa
Silniki typu Midjourney, DALL·E, Stable Diffusion i ich klony stają się tanią alternatywą dla stocków, ale dochodzi kolejna warstwa ryzyka: terms of service narzędzia + potencjalna inspiracja cudzymi pracami w datasetach.
W praktyce wygląda to tak:
większość komercyjnych narzędzi (Midjourney, DALL·E w płatnych planach) daje użytkownikowi szerokie prawo do wykorzystania wygenerowanych obrazów, także w produktach komercyjnych,
w modelach open source (Stable Diffusion) prawo do użycia wynika z licencji samego modelu oraz ewentualnych dodatków (checkpointy, LoRA),
niektóre platformy SaaS zachowują sobie prawo do używania twoich promptów i wygenerowanych obrazów w celach treningowych – z punktu widzenia devów zwykle to nie jest problem, ale dla NDA z dużym klientem już może.
Realny scenariusz niskobudżetowy: generujesz set ilustracji onboardingowych w AI, lekko je poprawiasz w edytorze i wprowadzasz do appki. Koszt: godzina czasu + tania subskrypcja. W większości przypadków tak powstałe grafiki możesz legalnie wykorzystać, pod warunkiem że:
sprawdzisz TOS narzędzia (czy masz pełne prawa komercyjne),
unikasz promptów wprost proszących o kopiowanie cudzych marek: „exact copy of [konkurencja app art] 1:1”,
nie korzystasz z publicznych modeli przeszkolonych na assetach, które same są objęte restrykcyjną licencją (np. płatne pakiety postawione nielegalnie w repozytum).
Kliencka biblioteka grafik – kto co posiada i co możesz z nią zrobić
Częsty przypadek: klient dostarcza paczkę zdjęć, ilustracji lub ikon „do użycia w aplikacji”. Dla devów brzmi to jak zielone światło, ale w tle są pytania:
czy klient faktycznie ma prawa/licencję pozwalającą na użycie w aplikacji,
czy ta licencja pozwala na hostowanie grafik na twoim serwerze / w CDN,
czy możesz użyć tych grafik w case study, portfolio, demkach.
Prosty mechanizm ochronny: w umowie z klientem wprowadzić klauzulę, że:
to klient odpowiada za legalność dostarczonych materiałów,
udziela tobie (software house / freelancerowi) licencji na wykorzystanie ich w aplikacji w konkretnym zakresie,
możesz wykorzystać screeny z aplikacji w portfolio (z ewentualnym wyłączeniem wrażliwych danych).
To przerzuca ryzyko naruszenia praw przez „podejrzane grafiki” na stronę, która je dostarczyła, i oszczędza nerwów, gdy po roku okazuje się, że ktoś użył przypadkowego obrazka z Google Images jako tła login screena.
Fonty: czym różni się licencja desktopowa, webfontowa i app‑owa
Dlaczego nie każdy font zainstalowany w systemie możesz wrzucić do aplikacji
Fonty to klasyczna pułapka: skoro masz go w systemie, Figma/Sketch go widzi, wszystko wygląda legalnie. Problem w tym, że sposób instalacji i renderowania fontu w twoim workflow (desktop) nie ma prawie nic wspólnego z licencją na dystrybucję w aplikacji.
Minimalne rozróżnienie:
font zainstalowany lokalnie – możesz go używać w dokumentach, projektach graficznych, ale zwykle nie możesz go dołączać do aplikacji jako plik TTF/OTF/WOFF,
font „systemowy” (OS) – licencja Apple/Google/Microsoft reguluje jego użycie razem z systemem, nie automatycznie w twoim produkcie.
Prosta analogia: posiadanie filmu na Blu‑ray nie znaczy, że możesz go dorzucić do swojej aplikacji VOD jako „bonus dla użytkowników”. Z fontami jest podobnie.
Licencja desktopowa – do projektowania, nie do embedowania
Licencja desktopowa (czasem nazywana „desktop use” albo „print/screen use”) pozwala ci:
zainstalować font na określonej liczbie stanowisk,
używać go w dokumentach, grafikach, prezentacjach,
osadzać go w plikach PDF w sposób ograniczony (subsetting, embedded, ale nie jako odrębny asset).
Czego zazwyczaj nie możesz na podstawie samej licencji desktopowej:
wrzucić fontu jako pliku do APK/IPA i renderować nim UI,
udostępniać fontu użytkownikom końcowym tak, by mogli go pobrać i zainstalować,
hostować go jako webfont na publicznym serwerze (chyba że licencja wprost to dopuszcza).
Dlatego pakiet „Super Fancy Font – Desktop License, 3 seats” z marketplace’u typograficznego rozwiązuje problem projektowania w Figmie, ale nie rozwiązuje legalności w buildzie aplikacji. Do tego jest potrzebna osobna licencja.
Licencja webfontowa – dla stron i SPA, nie zawsze dla natywnych appek
Webfonty (WOFF/WOFF2) mają swoje własne zasady. Kupując licencję webfontową, zazwyczaj dostajesz prawo do:
hostowania fontu na wskazanych domenach,
użycia go w CSS (np. poprzez @font-face),
obsługi określonej liczby page views miesięcznie lub unikalnych użytkowników.
Z punktu widzenia devów istotne są dwie rzeczy:
limit jest zwykle liczony w page views albo requests, co w dużym SaaS‑ie może szybko podbić koszt,
część foundry wyklucza wykorzystanie webfontu w hybrydowych aplikacjach (Electron, React Native, Cordova) – traktuje to jako osobną licencję app‑ową.
W prostym SPA/landing page’ach webfontowa licencja wystarcza. Gdy jednak ładowany jest ten sam font w:
webowej appce (SPA),
desktopowym kliencie Electron,
mobilnej hybrydzie (np. Capacitor),
często wychodzisz poza standardowy zakres webfontu. Wtedy albo negocjuje się licencję „multi‑platform”, albo przesiada na font wolny (np. Google Fonts) i ma się spokój.
Licencja app‑owa – embed w pliku instalacyjnym
Licencja aplikacyjna (app license, mobile app, OEM) dotyczy sytuacji, w której font jest zaszyty w binarce – jako plik w paczce APK/IPA/EXE, albo w zasobach frameworka (np. Resources/fonts w .NET MAUI).
Typowe modele rozliczeń:
per app – płacisz za konkretny tytuł aplikacji (często bez limitu instalacji),
per platform – jedna stawka za iOS, osobna za Androida, osobna za desktop,
per volume – cena rośnie wraz z liczbą użytkowników / instalacji.
Przy mniejszych projektach najczęściej spotyka się model „per app/per platform” – droższy niż desktop/web, ale wciąż akceptowalny, gdy mowa o jednym ładnym kroju w całym produkcie. Schody zaczynają się, gdy UI kit wymaga 5–6 egzotycznych fontów premium – wtedy koszt licencji rośnie nieproporcjonalnie do efektu.
Bardziej budżetowe podejście:
w produktach masowych (B2C) trzymać się 1–2 krojów z rodziny open source lub Google Fonts,
płatne, charakterystyczne fonty rezerwować na logotyp i materiały marketingowe (desktop + web), bez embedowania w samym appce.
Google Fonts i inne darmowe fonty – gdzie są granice swobody
Google Fonts to najczęściej wybierany „no‑brainer” – fonty na licencji OFL (SIL Open Font License) albo podobnych. Dla devów oznacza to w praktyce:
OFL, open source i mity o „całkowitej” wolności
Większość krojów w Google Fonts jest na licencji OFL, która jest bardzo liberalna, ale ma kilka haczyków. Daje ci prawo do:
użycia fontu w komercyjnych i niekomercyjnych projektach,
embedowania w aplikacjach, stronach, dokumentach,
modyfikowania kroju (tworzenia forków).
Ograniczenia są głównie dwa:
zazwyczaj nie możesz używać tej samej nazwy fontu, jeśli go modyfikujesz (trzeba zmienić nazwę rodziny),
nie możesz „zamknąć” fontu – fork nadal musi być udostępniony na tej samej lub kompatybilnej licencji.
W praktyce dla devów oznacza to, że:
możesz bez stresu wrzucić pliki WOFF/TTF do apk/ipa,
możesz hostować font samodzielnie, nie tylko przez CDN Google,
możesz zrobić subset (np. tylko Latin+Digits) i też go wrzucić do paczki aplikacji.
Mit, który często się przewija: „skoro font jest darmowy, mogę go odsprzedawać jako część własnego zestawu assetów”. Technicznie możesz wziąć oryginalny plik, dodać go do płatnego UI kita i sprzedawać, ale kupujący dalej ma do niego prawa z OFL. Krótko: nie zrobisz z darmowego fontu prywatnej „złotej kury”, możesz co najwyżej zarobić na integracji, konfiguracji i gotowym systemie designu.
Samohostowanie Google Fonts vs CDN – prywatność, wydajność i compliance
Z poziomu licencji OFL możesz wybrać, czy ciągniesz fonty z CDN (fonts.googleapis.com), czy pakujesz je do własnego hostingu. Decyzja ma skutki techniczne i prawne.
CDN Google Fonts daje:
cache’owanie po stronie przeglądarki między różnymi stronami,
brak konieczności martwienia się o formaty (WOFF2/WOFF) i warianty.
Ale pojawiają się też problemy:
w niektórych jurysdykcjach (np. część krajów UE) wysyłanie requestów do Google może być traktowane jako przekazanie danych osobowych (IP, user agent), co bywa problemem compliance,
brak pełnej kontroli nad dostępnością – jeśli polityka firmy wymaga minimalizowania zależności zewnętrznych, CDN bywa blokowany.
Samohostowanie jest korzystne, gdy:
masz aplikację B2B z wrażliwymi klientami (banki, sektor publiczny),
chcesz mieć powtarzalne buildy bez ryzyka, że CDN coś zmieni lub padnie,
celujesz w rynek, gdzie RODO/GPDR jest traktowane bardzo serio i audyt pyta o każdy zewnętrzny request.
Od strony devów koszt jest niewielki: pobranie fontu (np. przez Google Webfonts Helper), wrzucenie do repo, konfiguracja @font-face. Jednorazowa godzina pracy, a masz święty spokój i kontrolę wersji.
„Darmowy font z randomowego bloga” vs sprawdzone źródła
Najtańszy scenariusz bywa kuszący: ktoś wkleja na forum linka do „mega paczki darmowych fontów 2GB” albo blog z „1000 free fonts for designers”. Na poziomie kosztów wygląda to dobrze, na poziomie ryzyka – już niekoniecznie.
Problemy pojawiają się w trzech obszarach:
brak jasnej licencji – nie wiadomo, czy font jest freeware do prywatnego użytku, czy open source,
brak źródła – nie masz jak potwierdzić, kto jest autorem i gdzie jest oryginalny zapis zasad użycia,
sklejone paczki – w jednym ZIP-ie masz mieszankę: część fontów jest na OFL, część „personal use only”, część piracka.
Bezpieczniejsze źródła darmowych krojów:
Google Fonts,
GitHub (repozytoria oficjalnych projektów typograficznych, np. Inter, Roboto, JetBrains Mono),
strony foundry, które jawnie oferują darmowe fonty do użytku komercyjnego (np. na OFL, Apache, MIT).
Z perspektywy budżetu: lepiej poświęcić 30 minut na szukanie fontu w legalnym źródle, niż potem pół dnia na tłumaczenie się przed klientem, że ktoś wyłapał plagiat kroju w ich nowym produkcie.
Font w logo, brandbooku i UI – trzy różne światy licencyjne
Często jedna decyzja projektowa z backendu brandingu rozlewa się na całe środowisko: designer wybiera premium font do logotypu, a potem ten sam font ma być w całym UI. Dla licencji to są trzy różne przypadki użycia:
logo – najczęściej wystarczy licencja desktopowa dla studia, które logo projektuje; font w finalnym logo jest spłaszczony do krzywych,
materiały marketingowe – licencja desktop/web (w zależności od formy publikacji),
sam interfejs aplikacji – licencja app‑owa lub webfontowa/desktopowa rozszerzona o embed w aplikacji.
Praktyczna, tania opcja: użyć jednego specyficznego, płatnego kroju tylko w logotypie i key visualach, a w samym UI oprzeć się na spokrewnionym lub podobnym kroju z Google Fonts. Użytkownik końcowy patrzy na spójność ogólnego stylu, nie na szczegóły krzywych w literze „g”.
Jeżeli klient nalega, by „wszędzie był ten sam font co w logo”, poproś o:
dostęp do zakupionych licencji lub kontakt do foundry,
jasne oświadczenie, że kupią odpowiadającą licencję app‑ową, jeśli będzie wymagana.
Sklejenie tego na start oszczędza późniejszych przepychanek: kto ma dopłacić do nowej licencji, gdy aplikacja jednak rośnie.
Fonty systemowe jako kompromis: San Francisco, Roboto, Segoe UI
Najbardziej budżetowy wariant: korzystać z fontów systemowych użytkownika, zamiast embedować własne pliki. Na iOS będzie to np. San Francisco, na Androidzie – Roboto / Noto Sans, na Windows – Segoe UI, a w przeglądarce – domyślne sans‑serif.
Zalet jest kilka:
zero kosztów licencyjnych po twojej stronie – prawo do użycia kroju wynika z licencji systemu użytkownika,
lepsza wydajność – brak ładowania dodatkowych zasobów fontów,
bardziej „naturne” odczucie interfejsu – UI wygląda jak część systemu.
Minusem jest mniejsza kontrola nad wyglądem, zwłaszcza w podejściu „one design to rule them all”. Najprostszy kompromis:
w natywnych aplikacjach trzymać się systemowych fontów (iOS/Android/desktop),
spójność budować kolorem, spacingiem, gridem, a nie konkretną rodziną krojów,
ten sam custom font wprowadzić tylko w webowej wersji produktu, gdzie licencja webfontowa jest tańsza i prostsza.
To rozwiązanie szczególnie sensowne w MVP i projektach, które dopiero walidują rynek. W razie sukcesu można w kolejnych release’ach wprowadzić droższe, customowe fonty z pełną licencją.
Case: frameworki UI, komponenty i gotowe szablony
Bootstrap, Material UI, Tailwind UI czy płatne zestawy komponentów często mają zaszyte domyślne fonty – czasem własne, czasem z Google Fonts, czasem płatne. Z punktu widzenia licencji istotne jest, co dokładnie ciągniesz razem z paczką.
Przygotowując projekt produkcyjny:
sprawdź, czy domyślny font w theme jest open source (np. Inter, Roboto, Poppins),
jeśli szablon korzysta z premium fontu, dopytaj sprzedawcy, czy licencja obejmuje też embed w twojej aplikacji,
rozważ natychmiastową podmianę na kroje z Google Fonts, żeby przeciąć temat licencji na starcie.
Częsty scenariusz: kupujesz ładny template admina z ThemeForest, w którym użyto płatnego kroju, ale tak naprawdę projekt bezboleśnie wygląda na Roboto czy Inter. Jednorazowa godzina zmiany stylów w zamian za brak konieczności kupowania osobnej licencji na font – rozsądny trade‑off.
Co dokumentować, żeby nie wracać do tego za pół roku
Największy koszt licencyjny pojawia się wtedy, gdy po czasie nikt nie pamięta, skąd jest dany font. W repo i w narzędziach devowych warto mieć minimalny „log pochodzenia”:
krótki plik FONTS.md w repo, z listą krojów: nazwa, źródło, typ licencji, link do strony foundry,
folder /licenses/fonts z kopiami plików licencyjnych (OFL.txt itp.),
w Figmie/Sketchu naming styli tekstowych tak, aby oddzielać „brand font (logo only)” od „UI font (app‑ready)”.
Dla małego projektu to dodatkowe 15–20 minut. Dla większego – zabezpieczenie na lata, gdy zespół się zmienia, a projekt przechodzi z jednej firmy do drugiej. Ktoś za dwa lata zada pytanie: „czy my w ogóle mamy licencję na ten font?”, a odpowiedź będzie w jednym pliku zamiast w archiwum maili byłego designera.
Najczęściej zadawane pytania (FAQ)
Czy mogę skopiować ładny ekran lub layout z innej aplikacji, jeśli trochę go zmienię?
Jeśli kopiujesz konkretny układ elementów, proporcje, kolory i charakterystyczne rozwiązania wizualne, to nawet po „drobnych zmianach” nadal możesz naruszać prawa autorskie. Prawo nie chroni samego pomysłu listy czy karty, ale konkretne, twórcze wykonanie.
Bezpieczniej jest potraktować cudzy layout jako inspirację konceptualną: przeanalizować, co działa (np. hierarchia informacji), po czym zaprojektować własny ekran od zera albo oprzeć się na publicznych design systemach (Material, HIG, Fluent). To zwykle tańsze i mniej ryzykowne niż ewentualny spór prawny.
Czy ikony z Material Design, Fluent UI albo iOS mogę używać w komercyjnej aplikacji?
Większość systemowych ikon (np. Material Icons od Google) jest udostępniana na jasnych, dość liberalnych licencjach i można ich używać w komercyjnych projektach bez dodatkowych opłat. Warunkiem jest przestrzeganie konkretnej licencji: czasem wymagane jest oznaczenie autora, czasem są ograniczenia co do modyfikacji lub dalszej odsprzedaży jako osobny produkt.
Przed wrzuceniem paczki ikon do projektu sprawdź stronę źródłową: typ licencji (np. Apache, MIT, własna EULA), czy dopuszcza użycie komercyjne, czy zabrania tworzenia konkurencyjnych bibliotek/packów. To 5 minut roboty, które może oszczędzić godzin konsultacji z prawnikiem.
Czy font systemowy (np. Roboto, SF Pro, Segoe UI) mogę zaincludować w swojej aplikacji lub hostować jako webfont?
To zależy od licencji konkretnego fontu. Część fontów systemowych (np. Roboto) jest udostępniana na otwartych licencjach, które pozwalają na embedowanie w aplikacjach i stronach. Inne (np. SF Pro od Apple) bywają ograniczone do użycia w produktach konkretnego ekosystemu albo zabraniają hostowania poza określonym zakresem.
Najszybszy i najtańszy sposób weryfikacji to: sprawdzić oficjalną stronę fontu lub dokumentację systemu (Android, iOS, Windows) i poszukać sekcji „License” lub „Font usage”. Jeśli licencja jest niejasna, prościej sięgnąć po alternatywny, otwarty font (np. z Google Fonts) niż ryzykować.
Czy grafiki ze stocka (np. Freepik, Shutterstock) mogę wrzucić do aplikacji bez kupowania rozszerzonej licencji?
Standardowe licencje stockowe często pozwalają na użycie w aplikacjach, ale mają limity i zakazy. Typowe ograniczenia to m.in.: zakaz użycia w produktach do dalszej odsprzedaży (np. szablony, UI kity), limity liczby użytkowników/instalacji lub wymóg, by grafika była „wtopiona” w projekt i nie do łatwego wyciągnięcia.
Jeżeli budujesz jedną aplikację SaaS lub produkt B2C i nie sprzedajesz samego UI jako szablonu, zazwyczaj wystarcza standardowa licencja. Gdy chcesz robić motywy, marketplace z szablonami czy komponenty dla innych devów, trzeba już sprawdzić, czy nie jest potrzebna licencja rozszerzona – inaczej może się to skończyć banem konta na stocku lub roszczeniem.
Jaka jest różnica między licencją na font a przeniesieniem praw do fontu czy grafiki?
Licencja daje ci prawo używać fontu/grafiki na określonych polach eksploatacji (np. w jednej aplikacji mobilnej, bez limitu instalacji, na całym świecie), ale właścicielem praw nadal pozostaje autor lub foundry. Nie możesz swobodnie odsprzedawać fontu ani sublicencjonować go innym, jeśli licencja tego wprost nie przewiduje.
Przeniesienie praw majątkowych (cesja) oznacza, że to ty lub twoja firma stajecie się właścicielem praw. To opłaca się, gdy chcesz wykorzystywać dany zestaw ilustracji czy ikon w wielu produktach, sprzedawać UI kity albo budować własny brand na lata. W większości „budżetowych” projektów wystarczy jednak dobra, jasno opisana licencja – tańsza i szybsza w ogarnięciu.
Czy proste kształty i standardowe przyciski mogę kopiować bez limitu?
Proste formy – prostokąty, okręgi, klasyczny „primary button” zgodny 1:1 z Material Design – zazwyczaj nie są traktowane jako utwory, bo brakuje im indywidualnego charakteru. Możesz je spokojnie odtwarzać w swoim UI, korzystając z dokumentacji design systemów.
Problem zaczyna się, gdy standardowy element jest częścią rozpoznawalnego, mocno autorskiego stylu (unikalne gradienty, specyficzne animacje, nietypowa kompozycja). Wtedy kopiowanie całego „looku” może już podpaść pod naruszenie. Zdrowy skrót: podstawowe komponenty – tak; charakterystyczny styl innej aplikacji – projektuj własny.
Czy mogę użyć darmowego fontu z internetu w aplikacji komercyjnej?
Samo słowo „darmowy” nie oznacza automatycznie „do wszystkiego”. Darmowe fonty mogą mieć różne EULA: część pozwala na komercyjne użycie w aplikacjach bez opłat, inne ograniczają użycie tylko do projektów niekomercyjnych albo wymagają wykupienia licencji przy określonej skali (np. powyżej X użytkowników lub przy embedowaniu w aplikacji).
Minimalny bezpieczny workflow to: pobierasz font wyłącznie ze strony autora lub z zaufanego serwisu (np. Google Fonts), sprawdzasz punkt „Commercial use / App embedding / Webfont license” i robisz zrzut licencji do repo lub dokumentacji projektu. To kilkanaście minut jednorazowo, a chroni cię przy audycie lub sprzedaży projektu dalej.
