Jak legalnie używać stockowych zdjęć i ikon w projektach aplikacji i stron WWW

licencja na zdjęcia stockowe, legalne użycie ikon, atrybucja autora, użycie komercyjne w aplikacji, redystrybucja assetów, rozszerzona licencja, Figma community licencja, UI kit a prawa autorskie, stock photo w landing page, dokumentacja licencji, sublicencja dla klienta, modyfikacja ikon i zdjęć

Najdroższe błędy przy stockowych zdjęciach i ikonach rzadko zaczynają się od jawnego piractwa. Zwykle wszystko wygląda poprawnie: plik pobrano z legalnego źródła, konto zostało opłacone albo asset miał etykietę „free”, a projekt działa już na stronie czy w aplikacji. Problem pojawia się później, gdy ten sam plik trafia do repozytorium, paczki dla klienta, UI kitu, szablonu sprzedawanego dalej albo kampanii reklamowej. Wtedy okazuje się, że legalne pobranie nie daje automatycznie prawa do każdego sposobu użycia.

Przy projektach WWW i aplikacji trzeba patrzeć nie tylko na to, skąd pochodzi zdjęcie lub ikona, ale też jak asset jest wdrażany, kto jest odbiorcą końcowym, czy plik da się wyodrębnić i użyć ponownie oraz czy produkt ma charakter komercyjny. To właśnie te szczegóły najczęściej decydują o zgodności z licencją.

Legalne pobranie to nie to samo co legalne użycie

Trzy warstwy, które trzeba rozdzielić: prawa autorskie, licencja, zgoda na konkretny sposób użycia

W praktyce mieszają się trzy różne kwestie. Po pierwsze są prawa autorskie, które co do zasady pozostają przy twórcy zdjęcia, ilustracji lub zestawu ikon albo przy podmiocie, który tymi prawami zarządza. Po drugie jest licencja, czyli zakres uprawnień przyznanych użytkownikowi. Po trzecie jest konkretny scenariusz użycia: strona firmowa, aplikacja mobilna, panel klienta, kampania reklamowa, szablon do odsprzedaży albo biblioteka komponentów przekazywana dalej.

Jeśli asset został pobrany zgodnie z regulaminem serwisu, to znaczy tylko tyle, że dostęp do pliku był legalny. Nie znaczy to jeszcze, że wolno go umieścić w dowolnym produkcie, modyfikować bez ograniczeń, przekazać klientowi w źródłach albo osadzić w szablonie sprzedawanym setkom użytkowników. Użytkownik zwykle nie nabywa własności pliku, tylko dostaje warunkowe prawo korzystania z niego w określonym zakresie.

To rozróżnienie ma duże znaczenie przy ikonach i zdjęciach stockowych używanych w projektach aplikacji i stron WWW. Ikona pobrana z darmowego zestawu może być zgodnie z licencją wyświetlana w gotowym interfejsie, ale już niekoniecznie wolno jej dołączyć do paczki SVG przekazywanej klientowi lub osadzić w design systemie, który ma obsługiwać wiele przyszłych projektów. Źródło pliku jest legalne, a mimo to konkretny model wdrożenia może naruszać warunki licencyjne.

Dlaczego etykiety „free” i „royalty-free” bywają mylące

Jedna z najczęstszych pułapek bierze się z marketingowych etykiet. Free download, royalty-free, for commercial use albo no attribution brzmią wygodnie, ale bez pełnej treści licencji znaczą niewiele. „Royalty-free” zwykle oznacza brak opłat od każdego wyświetlenia lub użycia, a nie brak ograniczeń. „Commercial use” może obejmować publikację na stronie firmowej, ale już nie sprzedaż szablonu z osadzonym plikiem. „Free” bywa ograniczone do użytku osobistego, jednego projektu, niskiej rozdzielczości albo zastosowań bez redystrybucji.

Jeśli opis przy przycisku pobierania mówi jedno, a regulamin albo osobna licencja mówi coś innego, liczy się dokument prawny, nie skrót marketingowy. To szczególnie ważne przy assetach z agregatorów, marketplace’ów, bibliotek Figma Community i darmowych repozytoriów, gdzie karta podglądu bywa uproszczona, a pełne warunki ukryte są kilka kliknięć dalej.

Krótki przykład pułapki już na starcie

Typowy przypadek wygląda tak: projektant pobiera darmową ikonę, wdraża ją do komercyjnej aplikacji i wszystko wydaje się poprawne. Później ten sam plik trafia do UI kitu przekazanego klientowi wraz z komponentami, wariantami i eksportami SVG. W tym momencie problemem nie jest już samo wyświetlanie ikony w aplikacji, ale redystrybucja assetu i umożliwienie dalszego użycia przez inny podmiot. Dla wielu licencji to dwa różne światy.

Jak czytać licencję pod kątem aplikacji i stron WWW

Zapisy, które realnie zmieniają zakres ryzyka

Najważniejsze ograniczenia nie są zwykle ukryte w skomplikowanym języku prawnym, tylko zapisane dość wprost. Trzeba sprawdzić przede wszystkim, czy licencja dopuszcza użycie komercyjne, czy wymaga atrybucji autora, czy pozwala na modyfikację, czy zakazuje redystrybucji, czy wyłącza sublicencję oraz czy zawiera osobne zasady dla szablonów, produktów do odsprzedaży, logo i znaków towarowych. To właśnie te punkty najczęściej decydują, czy zdjęcie lub ikona może trafić do konkretnego produktu cyfrowego.

Przy aplikacjach i stronach WWW pojęcie użycia komercyjnego trzeba rozumieć szeroko. Jeśli strona wspiera sprzedaż, buduje markę firmy, zbiera leady, promuje usługę lub produkt, to zazwyczaj mówimy o użyciu komercyjnym. Tak samo będzie z aplikacją abonamentową, panelem klienta, SaaS-em, płatnym onboardingiem, landing page’em kampanii i dashboardem dla użytkowników biznesowych. Komercyjność nie zależy tylko od tego, czy sprzedajesz sam asset. Wystarczy, że asset pracuje na rzecz działalności zarobkowej albo biznesowej.

Atrybucja też nie sprowadza się do pytania „czy trzeba podać autora”. Trzeba jeszcze ustalić jak, gdzie i przy jakim typie publikacji. Czasem licencja wskazuje konkretną formułę oznaczenia, czasem wymaga linku do źródła, a czasem dopuszcza oznaczenie w creditsach lub dokumentacji. Stopka strony nie zawsze rozwiązuje sprawę, zwłaszcza jeśli asset jest używany w aplikacji mobilnej, zamkniętym panelu lub materiale, w którym użytkownik nie widzi standardowej stopki.

Pięć pytań kontrolnych, które pozwalają szybko ocenić licencję

Zanim zdjęcie stockowe albo ikona trafi do wdrożenia, dobrze zatrzymać się przy kilku bardzo konkretnych pytaniach. Kto publikuje produkt: osoba prywatna, firma, agencja, klient? Gdzie asset będzie widoczny: na stronie, w aplikacji, w reklamie, w panelu klienta, w szablonie? Czy produkt zarabia albo wspiera sprzedaż? Czy plik źródłowy trafi do innych osób: deweloperów, klienta, podwykonawców, użytkowników końcowych? Czy odbiorca ma prawo używać assetu dalej samodzielnie? I wreszcie: czy licencja wymaga oznaczenia autora lub źródła?

Jeśli na któreś z tych pytań odpowiedź zmienia się w trakcie projektu, trzeba ponownie sprawdzić licencję. To częsty moment ryzyka. Asset dobrany do jednego celu bywa później użyty szerzej, bo zespół uznaje to za naturalne rozszerzenie projektu. Z perspektywy prawa to jednak może być nowy sposób eksploatacji.

Modyfikacja nie zawsze oznacza to samo

Wiele licencji dopuszcza podstawowe przeróbki: kadrowanie zdjęcia, kompresję, zmianę rozdzielczości, korektę barw, dopasowanie ikony do motywu kolorystycznego, zmianę grubości linii albo scalenie z komponentem UI. Taki zakres modyfikacji często mieści się w normalnym użyciu projektowym. Problem zaczyna się wtedy, gdy z cudzych assetów powstaje samodzielny zestaw pochodny, który ma dalej krążyć między projektami albo zostać przekazany odbiorcy jako osobny zasób.

Zmiana koloru jednej ikony użytej w menu aplikacji to nie to samo co zebranie trzydziestu ikon z różnych źródeł, ujednolicenie ich wizualnie i dołączenie do firmowego design systemu jako biblioteki wielokrotnego użycia. W pierwszym przypadku mówimy zwykle o modyfikacji w ramach wdrożenia. W drugim łatwo wejść w obszar redystrybucji, tworzenia utworu pochodnego i dalszego udostępniania.

Zdjęcia i ikony rządzą się inną logiką licencyjną

Zdjęcia stockowe — nie tylko prawa autora, ale też kontekst użycia

Przy zdjęciach stockowych sama licencja od autora lub platformy to często nie cały obraz sytuacji. Fotografia może przedstawiać ludzi, wnętrza, budynki, dzieła sztuki, oznaczenia marek, produkty lub miejsca o szczególnych ograniczeniach. Dlatego przy zdjęciach znaczenie ma nie tylko pytanie „czy mogę użyć tego pliku na stronie”, lecz także w jakim kontekście komunikacyjnym zdjęcie zostanie pokazane.

Największa ostrożność jest potrzebna wtedy, gdy fotografia może sugerować coś o osobie przedstawionej na zdjęciu: stan zdrowia, problemy finansowe, uzależnienia, poglądy polityczne, orientację, przynależność religijną albo inne wrażliwe cechy. Nawet jeśli platforma stockowa legalnie udostępniła plik, warunki mogą ograniczać użycie w kontekstach, które tworzą takie skojarzenia. Na stronie kliniki, kancelarii oddłużeniowej albo kampanii dotyczącej zdrowia psychicznego to ma bardzo praktyczne znaczenie.

W projektach stron WWW często zakłada się, że zdjęcie hero albo fotografia do sekcji „o nas” jest bezpieczna, skoro pochodzi z dużego banku zdjęć. Czasem tak, ale nie zawsze. Jeśli na fotografii widać rozpoznawalny znak towarowy, charakterystyczne dzieło, prywatną własność albo osobę w sytuacji, którą łatwo odczytać jako wrażliwą, trzeba czytać warunki dokładniej. Zdjęcie legalne jako ilustracja ogólna nie zawsze będzie legalne jako nośnik konkretnego, potencjalnie wrażliwego przekazu.

Ikony i zestawy UI — większe ryzyko przy bibliotekach, komponentach i plikach źródłowych

Przy ikonach główny problem bywa inny. Rzadziej chodzi o kontekst osobisty czy wizerunkowy, a częściej o obieg pliku. Ikona użyta jako element interfejsu w opublikowanej aplikacji bywa zgodna z licencją, ale ten sam plik SVG umieszczony w bibliotece komponentów, pluginie, UI kicie albo szablonie eksportowanym dla klienta może już naruszać zakaz redystrybucji.

To szczególnie częste w Figma Community, darmowych paczkach UI, pluginach do projektowania i gotowych kitach pobieranych razem z dokumentacją. Dostęp do pliku nie jest równoznaczny z prawem do komercyjnego wdrożenia. Czasem licencja obejmuje tylko użytek osobisty, czasem jeden projekt, czasem zakazuje wykorzystania w produktach sprzedawanych klientom, a czasem wymaga wykupienia płatnej wersji do zastosowań komercyjnych.

Jeśli zespół traktuje ikonę jak zwykły detal graficzny, łatwo przeoczyć, że w świecie UI ten detal często staje się częścią większej biblioteki. A biblioteka ma inną logikę niż pojedyncze wdrożenie. Ikona w aplikacji to jedno; ikona jako element systemu designowego, paczki komponentów lub szablonu dla wielu marek to co innego.

Community assets i gotowe biblioteki nie dają automatycznego prawa do wdrożenia

Wiele osób zakłada, że skoro asset znajduje się w publicznej społeczności projektowej albo w pliku widocznym „do remiksu”, to można go bezpiecznie wdrożyć klientowi. To skrót myślowy, który bywa kosztowny. Platforma może umożliwiać kopiowanie pliku na poziomie technicznym, ale prawa do wykorzystania komercyjnego mogą być ograniczone przez opis autora, licencję zewnętrzną albo regulamin samej biblioteki.

W praktyce trzeba ustalić dwie rzeczy. Po pierwsze: na jakiej licencji udostępniono sam asset. Po drugie: czy ta licencja obejmuje akurat twój model użycia — wdrożenie dla klienta, przekazanie źródeł, wielokrotne użycie w różnych produktach albo dalszą sprzedaż szablonu. Sam fakt, że coś da się skopiować do projektu Figma, nie jest jeszcze zgodą na komercyjne użycie w aplikacji lub na stronie WWW.

To dlatego przy community assets najlepiej przyjąć prostą zasadę operacyjną: jeśli licencja nie jest jasno opisana i możliwa do zweryfikowania, asset nie powinien trafiać do produkcji. Zrzut ekranu z opisu, link do warunków i zapis wersji licencji w dokumentacji projektu zwykle rozwiązują więcej problemów niż późniejsze ustalanie „skąd to było”. W pracy agencyjnej albo zespołowej ma to dodatkowe znaczenie, bo po kilku miesiącach nikt nie pamięta, czy dana ikona była z otwartego zestawu, płatnej subskrypcji czy pliku skopiowanego z community.

Typowa pułapka wygląda tak: projektant wykorzystuje darmowy zestaw ikon znaleziony w publicznej bibliotece, potem deweloper eksportuje SVG do repozytorium, a finalnie klient dostaje cały system komponentów razem ze źródłami. Jeśli licencja zezwalała wyłącznie na użycie w jednym końcowym produkcie, to przekazanie paczki jako zasobu do dalszej pracy może wykraczać poza dozwolony zakres. Problem nie wynika wtedy z samego widoku opublikowanej strony, tylko z tego, jak asset został przekazany i do czego może zostać użyty dalej.

Rozsądne minimum to rozdzielenie trzech sytuacji: użycie tylko w gotowym interfejsie, przekazanie plików źródłowych klientowi oraz budowa biblioteki wielokrotnego użycia. Jeśli asset ma działać wyłącznie w jednym wdrożeniu, często wystarczy standardowa licencja komercyjna. Jeśli plik ma krążyć między zespołami albo wejść do design systemu używanego w kilku produktach, trzeba sprawdzić, czy licencja dopuszcza taki model albo czy potrzebna jest wersja rozszerzona. A jeśli nie da się tego ustalić bez domysłów, bezpieczniej wybrać zasób z czytelną licencją niż opierać wdrożenie na niepewnym pliku.

Najpraktyczniejsze podejście jest proste: do pojedynczej strony lub aplikacji wybieraj assety z licencją jednoznacznie dopuszczającą użycie komercyjne i modyfikację, do produktów przekazywanych klientom lub opartych na szablonach dobieraj zasoby z prawem do szerszej dystrybucji, a przy jakiejkolwiek niejasności traktuj brak pewności jak sygnał stop. W sporach liczy się nie to, co „wydawało się oczywiste”, tylko to, co rzeczywiście wynika z licencji.

Te same pliki, różne skutki prawne — scenariusze użycia w praktyce

Ten sam asset może być użyty legalnie w jednym miejscu i problematycznie w innym. Nie dlatego, że plik się zmienił, tylko dlatego, że zmienił się model wykorzystania. W projektach WWW i aplikacji najwięcej nieporozumień bierze się właśnie stąd: zespół patrzy na grafikę jak na element wizualny, a licencja patrzy na nią jak na zasób używany w konkretnym kanale, kontekście i obiegu.

Hero na stronie i ilustracja blogowa to zwykle najprostszy przypadek

Jeśli zdjęcie trafia na publiczną stronę firmy jako element hero, baner kampanii albo ilustracja wpisu blogowego, najczęściej kluczowe są trzy rzeczy: czy licencja dopuszcza użycie komercyjne, czy pozwala na modyfikacje oraz czy wymaga atrybucji. Taki scenariusz bywa stosunkowo prosty, bo asset nie jest dalej przekazywany użytkownikowi końcowemu jako samodzielny plik i nie stanowi produktu do odsprzedaży.

To jednak nie znaczy, że ryzyko znika. Jeśli zdjęcie z darmowego banku trafia na landing page płatnej usługi, użycie jest komercyjne nawet wtedy, gdy sam plik pobrano bez opłaty. Jeśli licencja wyłącza zastosowania reklamowe albo zastrzega dodatkowe warunki dla promocji usług, sam fakt „darmowego pobrania” niczego tu nie załatwia.

Onboarding, ekran pustego stanu i grafika w aplikacji SaaS

W aplikacji internetowej albo mobilnej asset przestaje być tylko ilustracją marketingową. Często staje się częścią produktu. To ma znaczenie zwłaszcza przy ikonach, ilustracjach onboardingowych i grafikach osadzonych w interfejsie użytkownika. Jeśli licencja pozwala na wykorzystanie na stronie, ale ogranicza użycie w oprogramowaniu, aplikacjach albo produktach cyfrowych, różnica jest realna.

W praktyce trzeba sprawdzić, czy zapis o dozwolonym użyciu obejmuje wyłącznie materiały promocyjne, czy także samą usługę cyfrową. Niektóre regulaminy rozróżniają stronę informacyjną od aplikacji, dashboardu, produktu SaaS czy aplikacji mobilnej dystrybuowanej przez sklep. Jeśli licencja mówi o „end product” albo „digital product”, trzeba ustalić, jak autor lub platforma rozumie ten termin.

To samo dotyczy paneli klienta. Z biznesowego punktu widzenia panel może być tylko częścią strony. Z punktu widzenia licencji bywa już odrębnym środowiskiem, zwłaszcza jeśli użytkownik loguje się do systemu, korzysta z funkcji aplikacyjnych i pobiera materiały. Jeśli asset jest osadzony w takim narzędziu, dobrze sprawdzić, czy licencja nie ogranicza użycia do treści publicznych albo marketingowych.

Szablon, motyw, UI kit i produkt do odsprzedaży

To jeden z najczęściej pomijanych punktów. Asset legalny w stronie firmowej nie musi być legalny w szablonie sprzedawanym wielu klientom. Gdy tworzysz motyw, landing page builder, zestaw komponentów, gotowy dashboard albo UI kit do dalszej odsprzedaży, przestajesz być tylko użytkownikiem końcowym. Zaczynasz dostarczać innym osobom narzędzie lub półprodukt, w którym cudzy asset nadal ma samodzielną wartość.

Wtedy największe znaczenie mają zapisy o redystrybucji, sublicencji, wykorzystaniu w template’ach oraz produktach resale. Jeśli licencja zabrania dalszego udostępniania pliku albo ogranicza użycie do jednego finalnego wdrożenia, osadzenie takiej ikony w komercyjnym szablonie będzie ryzykowne nawet wtedy, gdy użytkownik końcowy widzi ją tylko jako część interfejsu.

W praktyce różnica wygląda tak: strona dla jednej marki to zwykle jeden końcowy produkt. Biblioteka ekranów, którą klient może kopiować do kolejnych wdrożeń, to już infrastruktura do wielokrotnego użycia. W takim modelu standardowa licencja bardzo często nie wystarcza.

Projekt dla klienta a przeniesienie plików do zespołu wdrożeniowego

W pracy agencyjnej i freelancerskiej problem pojawia się w momencie przekazania projektu. Jeśli projektant pobrał asset na własnym koncie, to trzeba sprawdzić, kto jest licencjobiorcą. Czasem licencja obejmuje wykonawcę działającego na rzecz klienta. Czasem wymaga, by to klient miał własną subskrypcję albo własny zakup. Bywa też tak, że legalne jest przygotowanie projektu koncepcyjnego, ale już nie przekazanie plików źródłowych klientowi bez osobnego nabycia praw przez niego.

To nie jest detal administracyjny. Jeżeli klient po odbiorze projektu będzie samodzielnie rozwijał stronę, zatrudni nowy zespół albo wykorzysta ikonę w kolejnej kampanii, pytanie brzmi nie tylko „czy asset był legalny w dniu publikacji”, ale również „czy klient ma prawo korzystać z niego dalej we własnym zakresie”. Jeśli odpowiedź jest niejasna, problem wraca przy redesignie, migracji albo audycie prawnym po latach.

Modyfikacja, atrybucja, rozszerzona licencja — gdzie najczęściej dochodzi do błędnych założeń

Atrybucja nie zawsze jest obowiązkowa, ale czasem brak oznaczenia łamie licencję

Przy darmowych bankach zdjęć i bibliotekach ikon częstym uproszczeniem jest myślenie: „jeśli autor nie prosi o podpis, to nie trzeba nic sprawdzać”. Tymczasem obowiązek atrybucji może wynikać z licencji, regulaminu platformy albo warunków konkretnego autora. Jeśli licencja wymaga podania autora, źródła, linku albo wzmianki w stopce, brak takiego oznaczenia może oznaczać użycie niezgodne z warunkami, mimo że sam plik został pobrany legalnie.

Zdarza się też sytuacja odwrotna: platforma podaje autora jako dobrą praktykę, ale nie jako wymóg licencyjny. To rozróżnienie ma znaczenie, bo w jednym przypadku mówimy o obowiązku, a w drugim o etykiecie lub rekomendacji. Jeśli zapis nie jest jasny, najlepiej odczytywać go ostrożnie i dokumentować przyjętą interpretację.

„Można edytować” nie oznacza „można zrobić z tego własny zestaw”

Licencje często pozwalają modyfikować asset pod potrzeby projektu. To jednak nie daje automatycznie prawa do potraktowania przerobionej wersji jak własnego, niezależnego zasobu. Jeśli ikona została odrysowana, uproszczona, scalona z innym elementem albo włączona do zestawu komponentów, nadal może pozostawać objęta ograniczeniami pierwotnej licencji.

Praktyczny test jest prosty: jeśli po modyfikacji plik nadal ma wartość jako samodzielny zasób do ponownego użycia, trzeba patrzeć nie tylko na zgodę na edycję, ale też na zakazy dalszej dystrybucji. To właśnie tutaj zespoły najczęściej mylą dozwoloną obróbkę z prawem do zbudowania własnej biblioteki na bazie cudzych plików.

Rozszerzona licencja jest potrzebna wcześniej, niż wielu osobom się wydaje

Rozszerzona licencja nie służy wyłącznie dużym kampaniom reklamowym. Często staje się potrzebna wtedy, gdy asset ma wejść do produktu sprzedawanego wielu odbiorcom, do szablonu, do aplikacji white-label albo do systemu, który klient powiela w kolejnych markach. Jeśli podstawowa licencja mówi o jednym projekcie, jednym końcowym produkcie albo zakazuje resale, próba „rozciągnięcia” jej na kilka wdrożeń jest ryzykowna.

Podobnie przy zdjęciach używanych w materiałach promocyjnych tworzonych dla kilku podmiotów z jednej grupy albo przy ikonach osadzanych w gotowym motywie. Sama skala użycia nie jest jedynym kryterium. Liczy się też to, czy asset pozostaje częścią jednego wdrożenia, czy staje się elementem produktu dystrybuowanego dalej.

Krótki przykład z praktyki: zestaw ikon wykorzystany w pojedynczym panelu administracyjnym zwykle mieści się w standardowym modelu wdrożeniowym. Ten sam zestaw umieszczony w dashboardzie sprzedawanym jako szablon dla wielu klientów wymaga już innego spojrzenia na licencję, nawet jeśli wizualnie nic się nie zmieniło.

Najczęstsze błędy przy przekazywaniu projektu klientowi lub deweloperom

Większość problemów nie wynika z samego pobrania pliku, tylko z chaosu organizacyjnego. Asset trafia do Figmy, potem do repozytorium, potem do paczki dla klienta, a po kilku miesiącach nikt nie potrafi odpowiedzieć, skąd pochodził i na jakich warunkach został użyty. Właśnie dlatego legalność użycia trzeba traktować jak część procesu projektowego, a nie końcowy formalizm.

Najbardziej kosztowne są zwykle cztery błędy. Po pierwsze, brak zapisania źródła i wersji licencji. Po drugie, mieszanie assetów o różnych warunkach w jednym systemie komponentów. Po trzecie, przekazanie klientowi plików, do których klient nie nabył prawa użycia. Po czwarte, założenie, że zakup subskrypcji przez jedną osobę obejmuje cały łańcuch wykonawców i dalszych użytkowników.

Jeśli deweloper eksportuje SVG z projektu i wrzuca je do publicznego repozytorium lub do paczki instalacyjnej biblioteki komponentów, może dojść do niezamierzonej redystrybucji. Jeśli account manager wysyła klientowi folder „assets” bez sprawdzenia, czy licencja dopuszcza takie przekazanie, problem powstaje jeszcze przed publikacją. Jeśli nowy podwykonawca dostaje cały design system z ikonami pobranymi kiedyś z nieustalonego źródła, zespół traci kontrolę nad statusem prawnym plików.

Dlatego przy przekazaniu projektu dobrze rozdzielić dwie rzeczy: to, co jest niezbędne do działania wdrożenia, oraz to, co stanowi bibliotekę źródłową do dalszego wykorzystania. Nie każde legalne użycie wymaga przekazania wszystkich plików oryginalnych. Czasem bezpieczniej przekazać wdrożony interfejs i listę assetów z informacją, które z nich klient powinien nabyć samodzielnie na własnym koncie.

Jak prowadzić dokumentację, żeby dało się obronić legalność użycia po czasie

Dobra dokumentacja nie musi być rozbudowana. Ma przede wszystkim pozwalać odpowiedzieć na cztery pytania: co to za asset, skąd pochodzi, na jakiej licencji został użyty i w jakim dokładnie zakresie został wdrożony. Jeśli po roku nie da się tego ustalić w kilka minut, organizacja licencji jest zbyt słaba.

W praktyce dobrze działa prosty rejestr assetów dołączony do projektu. Przy każdym pliku lub zestawie wystarczy odnotować źródło, autora lub platformę, link do warunków, datę pobrania, typ licencji, informację o obowiązku atrybucji oraz uwagi o ograniczeniach, na przykład: „bez użycia w logo”, „bez redystrybucji”, „jeden projekt”, „klient musi nabyć własną licencję”.

Przy płatnych zasobach sens ma też przechowywanie potwierdzenia zakupu albo zrzutu ekranu z warunków obowiązujących w dniu pobrania. Regulaminy platform potrafią się zmieniać, a po czasie trudno wykazać, jaka wersja licencji obowiązywała przy wdrożeniu. Sam link bywa niewystarczający, jeśli treść regulaminu została później zaktualizowana.

Jeśli zespół pracuje w Figmie, repozytorium kodu i narzędziu do zarządzania zadaniami, najlepiej nie rozrzucać informacji po trzech miejscach. Jeden centralny rejestr działa lepiej niż wiedza „w głowie projektanta”. Zwłaszcza wtedy, gdy projekt przechodzi przez kilka rąk i po czasie nikt nie pamięta, czy dana ikona była częścią komercyjnej paczki, darmowego projektu community czy własnej ilustracji zespołu.

Jeśli użycie jest jednorazowe i zamknięte w jednej stronie firmowej, zwykle wystarczą assety z czytelną licencją komercyjną i prosty rejestr źródeł. Jeśli pliki mają trafić do aplikacji, panelu klienta, design systemu albo produktu sprzedawanego dalej, sens ma bardziej rygorystyczna selekcja: tylko zasoby z jasnymi warunkami modyfikacji, przekazania i redystrybucji. A gdy licencja zostawia pole do domysłów, najbezpieczniejszą decyzją najczęściej nie jest interpretowanie jej „na korzyść projektu”, tylko wybór innego źródła.