Legalność wtyczek i motywów WordPress: GPL, klucze aktywacyjne i aktualizacje

Fundament prawny: WordPress, GPL i co z tego wynika

WordPress jako projekt open source na licencji GPLv2+

WordPress jest wolnym oprogramowaniem wydawanym na licencji GNU General Public License (GPL) w wersji 2 lub nowszej. Oznacza to, że sam rdzeń systemu (core) jest objęty GPL i każdy, kto go pobiera, zgadza się na zasady tej licencji. Nie kupujesz więc „prawa do używania WordPressa” – ono jest z definicji przyznane każdemu – tylko korzystasz z uprawnień wynikających z GPL.

GPL jest licencją typu copyleft. W praktyce oznacza to, że jeśli tworzysz oprogramowanie będące dziełem zależnym od WordPressa (czyli ściśle z nim technicznie powiązane), to taki kod również powinien być udostępniony na warunkach GPL lub licencji z nią zgodnej. Do tej kategorii zalicza się zdecydowana większość motywów i wtyczek WordPress.

Dla właściciela strony najważniejsze jest to, że może instalować, kopiować i modyfikować WordPressa oraz dodatki na GPL bez dodatkowych opłat licencyjnych. Płatne są zwykle usługi wokół kodu (support, aktualizacje, wdrożenia), a nie sama możliwość jego uruchamiania.

Cztery wolności GPL w praktyce WordPressa

Klasyczne sformułowanie GPL mówi o czterech wolnościach użytkownika. Przekładając to na język WordPressa, otrzymujemy:

• Wolność uruchamiania programu – możesz używać WordPressa, motywów i wtyczek GPL na dowolnej liczbie stron, w dowolnym celu (komercyjnym, prywatnym, non-profit).
• Wolność analizowania i modyfikacji – masz prawo otworzyć pliki PHP, zmienić kod, usunąć część funkcji, dopisać własne, a nawet przeportować wtyczkę do innego projektu.
• Wolność rozpowszechniania kopii – możesz przekazać dalej niezmodyfikowaną kopię motywu lub wtyczki GPL, odpłatnie lub bezpłatnie.
• Wolność rozpowszechniania zmodyfikowanej wersji – możesz wydać własny fork, sprzedawać go lub rozdawać, ale również na licencji GPL.

To właśnie te wolności są źródłem wielu nieporozumień. Użytkownicy zakładają, że skoro wtyczka jest „premium”, to musi być jakoś sztywno powiązana z liczbą stron czy domen. Tymczasem GPL niczego takiego nie narzuca – ograniczenia wynikają z umów handlowych i systemów dystrybucji aktualizacji, a nie z samej licencji na kod.

Konsekwencje GPL dla motywów i wtyczek WordPress

Motyw lub wtyczka ściśle powiązana z core WordPressa zwykle jest traktowana jako dzieło zależne. To oznacza, że jej kod PHP powinien być udostępniony na GPL. Jeśli autor próbuje narzucić inny typ licencji na tę część, wchodzi w konflikt z filozofią i zasadami ekosystemu WordPress.

W praktyce wygląda to tak, że:

• dostawca może pobierać opłaty za dostęp do plików, aktualizacji i wsparcia,
• ale gdy już otrzymasz kod na GPL, masz prawo dalej z niego korzystać bez dodatkowych opłat,
• a także możesz go legalnie wykorzystać na więcej niż jednej stronie, jeśli umowa handlowa tego wprost nie zabrania (na poziomie usług).

Ważne rozróżnienie: nawet jeśli złamiesz regulamin sklepu (np. użyjesz kodu na większej liczbie stron, niż przewiduje pakiet), to nadal nie naruszasz GPL. Możesz naruszać warunki umowy cywilnoprawnej z dostawcą (co jest inną kategorią niż naruszenie praw autorskich do kodu), ale nie wolności udzielonej przez GPL do korzystania z samego programu.

Kod a marka, grafika i treści: różne porządki prawne

GPL obejmuje kod programu. Nie oznacza to jednak, że wszystko w paczce motywu lub wtyczki ma automatycznie taką samą licencję. Osobno działają:

• znaki towarowe i nazwy (logo producenta, nazwa motywu) – chronione prawem własności przemysłowej,
• grafiki, zdjęcia stockowe, ikony – często na licencjach stockowych (np. do użytku na jednej stronie, bez dalszej odsprzedaży),
• czcionki – mogą mieć licencje SIL OFL, komercyjne lub inne, niezależne od GPL,
• pliki PSD, Figma, dokumentacja PDF – zwykle na osobnych, autorskich licencjach wydawcy.

To rozróżnienie ma znaczenie np. przy „odsprzedaży paczek GPL”. Kod motywu możesz dystrybuować dalej na GPL, ale kopiowanie brandingu, treści marketingowych, demo z płatnymi zdjęciami stockowymi czy logo autora może już naruszać odrębne prawa.

Dlaczego społeczność WordPress pilnuje GPL

Projekt WordPress zbudował swoją pozycję globalnie właśnie dlatego, że opiera się na wolnym oprogramowaniu. Społeczność (twórcy core, moderatorzy repozytorium, organizatorzy WordCampów) chroni zasady GPL, ponieważ:

• umożliwia to niezależny rozwój wtyczek i motywów,
• zwiększa bezpieczeństwo (dostęp do kodu, możliwość audytu),
• zapobiega powstawaniu zamkniętych ekosystemów uzależniających użytkownika od jednego dostawcy.

Dlatego np. na WordCamps nie mogą oficjalnie sponsorować firmy łamiące GPL, a w repozytorium WordPress.org nie przejdą wtyczki z licencjami sprzecznymi z GPL. To nie jest jedynie „ideologia open source” – to ochrona praktycznego interesu całego ekosystemu.

Co dokładnie obejmuje GPL w przypadku motywów i wtyczek

Dzieło zależne: kiedy motyw lub wtyczka musi być na GPL

Pojęcie dzieła zależnego oznacza utwór, który technicznie i funkcjonalnie opiera się na innym utworze. W kontekście WordPressa najczęściej przyjmuje się, że motywy i wtyczki, które korzystają z API WordPressa, hooków, filtrów i funkcji core, są dziełami zależnymi od WordPressa.

Konsekwencje:

• kod PHP takich dodatków powinien być wydany na GPL lub licencji zgodnej z GPL,
• twórca nie może skutecznie zakazać dalszej redystrybucji samego kodu (może natomiast ograniczać dostęp do aktualizacji i innych usług),
• nie jest możliwe wprowadzenie skutecznego z punktu widzenia GPL „zakazu modyfikacji kodu” w wtyczce opartej na WordPressie.

Czasem twórcy próbują obejść to przez trzymanie części logiki w zewnętrznych serwisach (SaaS), gdzie plugin jest tylko cienkim klientem API. Wtedy część serwerowa może mieć inną licencję, a GPL obejmuje jedynie kod po stronie WordPressa.

Elementy niebędące kodem: grafiki, fonty, materiały stockowe

W jednej paczce motywu mogą znajdować się różne elementy, do których stosują się różne licencje:

• Pliki PHP, JS, CSS – zwykle na GPL (lub częściowo na GPL przy split-licensing),
• Obrazy demo (jpg, png, svg) – często pochodzą z banków zdjęć, z licencjami ograniczającymi dalszą redystrybucję,
• Fonty – mogą być open source (np. Google Fonts) lub komercyjne,
• Pliki źródłowe designu – PSD, AI, Figma – często na osobnej licencji do użytku przez jednego klienta.

Przykład: kupujesz motyw premium, który zawiera zestaw pięknych zdjęć w demo. Kod motywu jest GPL, więc możesz go zainstalować na dowolnej liczbie stron. Zdjęcia jednak mogą mieć licencję, która zezwala na użycie ich tylko w jednym projekcie lub wyłącznie w demo. Skopiowanie tych zdjęć do innego projektu może już naruszać zasady licencji stockowej, niezależnie od GPL na kod.

Split licensing u dostawców premium i jego konsekwencje

Wielu producentów motywów i wtyczek premium stosuje tzw. split licensing, czyli rozdzielenie licencji na kod i elementy niebędące kodem. Najczęściej wygląda to tak:

• kod PHP (i czasem część JS/CSS) – na licencji GPL,
• grafiki, layouty, pliki PSD – na licencji autorskiej dostawcy, z ograniczeniami redystrybucji,
• znaki towarowe i nazwa produktu – zastrzeżone, zakaz używania w konkurencyjnych ofertach.

Dla użytkownika oznacza to, że:

• może legalnie kopiować i modyfikować sam motyw lub wtyczkę jako kod,
• nie może natomiast sprzedawać „tego samego motywu” z oryginalną nazwą, brandingiem, grafikami demo i materiałami marketingowymi, udając oficjalny produkt.

Split licensing jest w zasadzie kompromisem między filozofią GPL a interesem komercyjnych twórców. Pozwala zarabiać na brandzie i warstwie wizualnej, jednocześnie respektując wymogi GPL wobec kodu zależnego od WordPressa.

Pełny motyw na GPL vs motyw z osobną licencją na grafiki

Dwa częste scenariusze z praktyki:

1. Pełny motyw na GPL – wszystkie pliki w paczce, łącznie z grafikami, są udostępnione na GPL. Możesz ich używać, modyfikować i redystrybuować bez dodatkowych ograniczeń. To popularny model w społecznościowych motywach z WordPress.org.
2. Motyw z GPL na kod i osobnymi licencjami na grafiki – najczęstszy model u motywów premium z marketplace’ów. Kod jest GPL, ale obrazy demo są dostępne tylko w ramach jednej licencji, nie można ich swobodnie odsprzedawać dalej.

Przy tworzeniu stron dla klientów oznacza to tyle, że nawet jeśli technicznie możesz przekazać dalej cały katalog motywu, to pod kątem legalnym dobrze jest sprawdzić licencje na grafiki i fonty. W praktyce wielu twórców stron zastępuje zdjęcia demo własnymi zasobami lub darmowymi stockami, aby uniknąć wątpliwości.

Różne podejścia marketplace’ów do GPL

Duże platformy z motywami i wtyczkami przyjęły różne podejścia do GPL:

Przy wyborze źródła motywów i wtyczek dobrze jest zwrócić uwagę, czy licencja jest jasno opisana, a informacje o GPL nie są ukryte drobnym druczkiem. Im bardziej przejrzysta polityka licencyjna, tym mniejsze ryzyko sporu przy późniejszym korzystaniu z dodatku.

Legalność pobierania i korzystania z motywów i wtyczek z różnych źródeł

Oficjalne źródła: WordPress.org, strony producentów, autoryzowane marketplace’y

Najbezpieczniejszym źródłem dodatków do WordPressa jest zawsze oficjalne repozytorium WordPress.org. Wszystkie znajdujące się tam motywy i wtyczki są poddawane weryfikacji pod kątem zgodności z GPL i podstawowych standardów jakości. Jeśli coś pochodzi z WordPress.org, kwestia legalności licencji na kod jest w praktyce domknięta.

Druga kategoria to oficjalne strony producentów – wtyczek premium, motywów komercyjnych, pakietów „pro”. Tam zwykle płacisz za subskrypcję lub jednorazową licencję, w zamian za co otrzymujesz dostęp do paczek instalacyjnych, aktualizacji i wsparcia. Z prawnego punktu widzenia kod nadal jest na GPL, ale dystrybucja odbywa się na warunkach określonych przez sprzedawcę.

Trzecia grupa to autoryzowane marketplace’y, jak ThemeForest czy CodeCanyon. Tam licencje mogą być formułowane nieco inaczej (np. single site / extended), jednak dla samego kodu powiązanego z WordPressem obowiązuje GPL. Różnice dotyczą głównie usług, materiałów dodatkowych i zasad wsparcia.

„GPL clubs” i paczki z motywami: gdzie jest granica legalności

Na rynku pojawiły się serwisy zwane potocznie „GPL clubs” – oferują dostęp do setek czy tysięcy motywów i wtyczek premium za ułamek ceny, najczęściej w formie abonamentu. Ich model opiera się na tym, że:

• kupują legalnie oryginalne motywy/wtyczki od producentów,

Jak działają serwisy z redystrybucją „GPL” w praktyce

Tego typu serwisy zazwyczaj działają według powtarzalnego schematu:

• kupują dostęp do motywów i wtyczek premium (często w najwyższych planach, z prawem do nieograniczonej liczby stron),
• pobierają oryginalne paczki instalacyjne (czasem wraz z dodatkowymi pluginami towarzyszącymi),
• udostępniają je dalej abonentom swojego serwisu, powołując się na wolność redystrybucji z GPL.

Od strony czysto licencyjnej (GPL) redystrybucja samego kodu PHP/JS jest co do zasady dopuszczalna, o ile:

• kod jest faktycznie na GPL (lub licencji z nią zgodnej),
• użytkownik otrzymuje informacje o licencji i swoje prawa (m.in. prawo do dalszej redystrybucji i modyfikacji),
• nie są wprowadzane dodatkowe ograniczenia w samej licencji na kod.

Problem zaczyna się tam, gdzie „GPL clubs” naruszają inne obszary prawa, np. warunki świadczenia usług producenta, licencje na grafiki, a niekiedy także znaki towarowe i prawo do oznaczeń handlowych.

Różnica między naruszeniem GPL a naruszeniem regulaminu producenta

Trzeba rozdzielić dwie kwestie, które często są wrzucane do jednego worka:

1. naruszenie GPL – np. zamknięcie kodu, zakaz redystrybucji, usuwanie informacji o licencji, brak udostępnienia kodu źródłowego przy dystrybucji binarnej,
2. naruszenie regulaminu/usługi producenta – np. zakaz udostępniania dalej swojego konta, pobierania aktualizacji dla osób trzecich, odsprzedaży dostępu do panelu klienta.

Z perspektywy użytkownika końcowego, który pobiera wtyczkę z „GPL clubu”:

• wobec producenta – nie jest stroną umowy (regulaminu), bo jej nie akceptował. To twórca „GPL clubu” narusza regulamin, jeśli kupił licencję z zastrzeżeniem „tylko do własnego użytku”, a następnie udostępnia paczki dalej,
• wobec prawa autorskiego – korzysta z kodu, który jest na GPL, więc jego użycie na własnych stronach (w granicach GPL) jest co do zasady dopuszczalne.

Innymi słowy: działanie serwisu sprzedającego cudze motywy może łamać umowy i regulaminy dostawców, natomiast samo korzystanie z kodu objętego GPL przez użytkownika klubowego mieści się w ramach tej licencji – o ile nie wchodzą w grę inne elementy (grafiki, brand, API SaaS).

Ryzyka praktyczne korzystania z „GPL clubs”

Nawet jeśli sam kod jest formalnie legalnie redystrybuowany, korzystanie z nieoficjalnych paczek wiąże się z konkretnymi ryzykami:

• brak gwarancji integralności – nie ma pewności, że paczka nie została zmodyfikowana, np. przez dodanie backdoora czy ukrytych linków,
• brak wsparcia producenta – oficjalny autor zwykle nie pomaga w rozwiązywaniu problemów użytkownikom, którzy kupili dodatek z nieautoryzowanego źródła,
• brak bezpośrednich aktualizacji – wiele klubów nie aktualizuje paczek na bieżąco, co w kontekście bezpieczeństwa jest poważnym problemem,
• niejasny status grafik i materiałów dodatkowych – często kopiowane są razem z motywem, choć ich licencja nie pozwala na swobodną redystrybucję.

Przykładowo: agencja wdraża klientowi stronę na motywie premium pobranym z „GPL clubu”. Motyw działa, ale po roku wychodzą dwie krytyczne łatki bezpieczeństwa, których klub nie aktualizuje. W efekcie strona zostaje zhakowana, a klient ma realne roszczenie wobec agencji, która świadomie wybrała tańsze, ale mniej bezpieczne źródło.

Granica między „legalne, ale nie fair” a faktycznym naruszeniem

W środowisku WordPressa często mówi się o „moralności GPL” – o tym, że coś może być zgodne z literą licencji, ale sprzeczne z duchem współpracy i finansowania rozwoju.

Z punktu widzenia prawa autorskiego:

• sprzedawanie dalszych kopii kodu objętego GPL, bez dostępu do konta u producenta, mieści się w ramach licencji,
• posługiwanie się marką autora w sposób sugerujący oficjalne powiązanie – może naruszać prawo znaków towarowych i zasady uczciwej konkurencji,
• redystrybucja grafik i materiałów stockowych bez uprawnień – może naruszać osobne licencje tych materiałów.

Pojawiają się też sytuacje pośrednie. Część klubów dodaje własne modyfikacje do kodu (np. usuwa mechanizmy sprawdzania licencji, dodaje własny branding). Wtedy taki podmiot staje się współautorem utworu zależnego i musi samodzielnie zachować zgodność z GPL (np. nie może zamknąć swojego forka, skoro opiera się na kodzie GPL).

Nielicencjonowane źródła: warez, torrenty, „nulled themes”

Osobną kategorią są strony oferujące tzw. „nulled themes/plugins”, często wprost reklamujące się hasłami typu „za darmo, bez licencji, crackowane”. W odróżnieniu od klubów, które przynajmniej formalnie kupują oryginalne paczki, tu pojawiają się dodatkowe problemy:

• niestety niemal zawsze dochodzi do modyfikacji kodu – dodanie złośliwego JS, wstrzyknięcie ukrytego użytkownika administratora, linki SEO,
• brak jakiegokolwiek kontaktu z „dostawcą” – nie ma osoby czy podmiotu prawnego, który ponosi odpowiedzialność i którego można pociągnąć do odpowiedzialności za szkody,
• często naruszane są także inne licencje (np. grafik, fontów, bibliotek JS niebędących GPL),
• dystrybucja odbywa się z naruszeniem nawet samej GPL – np. bez dołączenia informacji o licencji czy kodu źródłowego tam, gdzie jest to wymagane.

Od strony czysto prawnej dostęp do kodu GPL nigdy nie wymaga „crackowania” czy łamania zabezpieczeń – producent nie może zabronić jego redystrybucji. Jeśli więc ktoś oferuje „nulled” wersję, która omija mechanizmy licencyjne, to najczęściej dotyczy to nie samego kodu (ten jest wolny), lecz dostępu do aktualizacji, API czy usług zewnętrznych, które GPL już nie obejmuje.

Użycie kodu GPL w projektach komercyjnych dla klientów

Agencje i freelancerzy często pytają, czy wdrażanie klientom motywów i wtyczek GPL nie przenosi na nich obowiązków GPL wobec klientów. Odpowiedź zależy od tego, jak wygląda model współpracy:

• jeśli klient otrzymuje pełny dostęp do kodu (FTP, repozytorium, paczki instalacyjne), to automatycznie korzysta z praw dawanych przez GPL – może poprosić innego wykonawcę o modyfikacje, pobrać kod, przekazać go dalej itd.,
• jeżeli agencja świadczy usługę w modelu „SaaS na WordPressie” (klient nie ma bezpośredniego dostępu do kodu, tylko do panelu administracyjnego), to w pewnych modelach może nie dochodzić do „dystrybucji” w rozumieniu GPL – wtedy obowiązki są nieco inne.

W praktyce przy standardowych wdrożeniach stron dla klientów sytuacja jest prosta: kod WordPressa, motywów i wtyczek pozostaje na GPL, a klient korzysta z niego w ramach tych samych uprawnień co wykonawca. Umowa z klientem może jednak regulować inne kwestie – np. zakaz przekazywania dalej brandingu agencji, layoutów projektowanych na zamówienie, autorskich treści.

Klucze aktywacyjne do wtyczek i motywów premium

Techniczne działanie kluczy licencyjnych

Klucze aktywacyjne w motywach i wtyczkach premium są zazwyczaj ciągiem znaków powiązanym z kontem klienta u producenta. Po wpisaniu klucza w panelu WordPressa dodatek:

• wysyła żądanie do zewnętrznego serwera licencyjnego (API),
• przesyła dane identyfikujące stronę (domena, czasem adres IP, wersja WP, identyfikator instalacji),
• otrzymuje odpowiedź: licencja aktywna, wygasła, przekroczono limit domen itp.

W oparciu o tę odpowiedź kod dodatku podejmuje decyzję: czy włączyć aktualizacje automatyczne, czy wyświetlać komunikaty o braku licencji, czy udostępnić funkcje „pro”. Słowem – klucz jest narzędziem do zarządzania modelem biznesowym, nie do „wyłączania” wolności GPL na samym kodzie.

Czego klucz aktywacyjny nie może ograniczyć

Niezależnie od tego, jak producent formułuje komunikaty marketingowe, klucz aktywacyjny nie znosi praw nadanych przez GPL. W szczególności:

• nie może odebrać prawa do kopiowania i używania kodu dodatku na wielu stronach,
• nie może legalnie zabronić modyfikowania kodu (np. przez forka w repozytorium),
• nie może uniemożliwić redystrybucji kodu (np. przekazania paczki klientowi).

Producent może natomiast egzekwować swoje warunki w obszarach, które GPL zostawia poza swoim zakresem. Przykładowo:

• może zablokować dostęp do serwera aktualizacji, jeśli klucz jest nieaktywny,
• może ograniczyć support tylko do stron z aktywną licencją,
• może uzależnić dostęp do dodatkowych API lub usług SaaS od poprawnej aktywacji.

„Nielegalne użycie bez licencji” – co w tym jest nieścisłe

Marketing wielu dodatków premium posługuje się sformułowaniami typu „illegal without license”, „do not use without valid license key”. W przypadku kodu zależnego od WordPressa (czyli objętego GPL) takie hasła są co najmniej mylące.

Jeśli paczka z kodem została raz legalnie wprowadzona do obrotu na licencji GPL, to:

• każda kopia tego kodu zachowuje tę licencję,
• nawet jeśli wygasł dostęp do aktualizacji, sama instalacja i używanie posiadanej wersji nadal jest legalne,
• „brak ważnej licencji” oznacza w praktyce brak ważnego kontraktu na usługi z producentem, a nie złamanie prawa autorskiego.

Spór może pojawić się tam, gdzie producent próbuje w regulaminie rozszerzyć skutki braku aktywnej subskrypcji na samą możliwość używania kodu, np. przez zapisy „po wygaśnięciu licencji musisz odinstalować wtyczkę”. Taki zapis stoi w sprzeczności z GPL i może być w części nieskuteczny wobec użytkownika końcowego.

Klucze aktywacyjne a forki i modyfikacje

Jeśli ktoś tworzy forka wtyczki GPL (np. usuwa mechanizm aktywacji lub zmienia sposób łączenia z API), to:

• ma do tego prawo, o ile zachowa zgodność z GPL (np. dołączy informacje o licencji, zapewni dostęp do kodu źródłowego),
• nie może jednak podszywać się pod oryginalnego producenta – używać identycznej nazwy, logotypu, domeny sugerującej oficjalność,
• musi usunąć lub zmienić elementy objęte innymi prawami (np. zastrzeżonym znakiem towarowym, materiałami graficznymi na innej licencji).

Od strony technicznej producenci próbują czasem „bronić się” przed forkami przez wbudowanie w kod rozbudowanych mechanizmów weryfikacji licencji lub łączenie krytycznych funkcji z serwerem SaaS. GPL nie zabrania takiej architektury – chodzi jednak o to, że część serwerowa (SaaS) nie musi być GPL, a użytkownik bez ważnego konta nie ma technicznej możliwości korzystania z pełnej funkcjonalności, nawet jeśli sam kod klienta jest wolny.

Czy można udostępnić klientowi własny klucz licencyjny

W praktyce agencje czasem zastanawiają się, czy mogą „podpinać” klientów pod swoje klucze licencyjne, kupione w wyższych planach:

• jeśli plan przewiduje nieograniczoną liczbę domen (np. „agency plan”), producent często dopuszcza, że klucz jest używany na stronach klientów – ale może zakazywać ich dalszej odsprzedaży jako osobnej usługi,
• jeżeli plan jest wyraźnie oznaczony jako „tylko do własnego użytku”, udostępnianie klucza klientowi zwykle narusza umowę z producentem, nawet jeśli nie narusza samej GPL na kod.

Od strony relacji z klientem istotne jest jasne opisanie w umowie, co się stanie po zakończeniu współpracy: czy klient zachowuje dostęp do aktualizacji przez klucz agencji, czy musi kupić własną licencję, czy agencja zobowiązuje się do odinstalowania dodatków powiązanych z jej kontem itd. Sam kod (GPL) zostaje na stronie klienta, ale usługa aktualizacji i supportu może być wygaszona.

Aktualizacje, wsparcie techniczne i przywileje komercyjne

Rozdzielenie „licencji na kod” od „umowy na usługi”

Najczęściej zadawane pytania (FAQ)

Czy używanie płatnych motywów i wtyczek WordPress bez „ważnej licencji” jest legalne?

Jeśli motyw lub wtyczka są na GPL (a w ekosystemie WordPress to standard), to samo korzystanie z kodu jest legalne – niezależnie od tego, czy masz aktywną subskrypcję u producenta. GPL daje prawo uruchamiania programu w dowolnej liczbie kopii, także komercyjnie.

Problem może pojawić się na poziomie umowy z dostawcą: kupując pakiet „na 1 stronę”, zgadzasz się na określone warunki handlowe (np. ile instalacji obejmuje support i aktualizacje). Jeśli przekroczysz te limity, łamiesz regulamin sklepu, ale nie samą licencję GPL na kod.

Czy mogę legalnie instalować jeden motyw premium na wielu stronach?

Z punktu widzenia GPL – tak. Licencja nie ogranicza liczby domen ani instalacji. Jeśli kod motywu jest na GPL, możesz zainstalować go na dowolnej liczbie stron, modyfikować go i kopiować.

Ograniczenia „1 strona / 5 stron / nieograniczone strony” wynikają z polityki sprzedażowej producenta: dotyczą dostępu do aktualizacji, wsparcia i ewentualnie usług dodatkowych. Naruszenie tych limitów to spór umowny, a nie naruszenie praw autorskich do kodu.

Czy wolno mi sprzedawać dalej motywy i wtyczki WordPress na GPL?

GPL wyraźnie dopuszcza odpłatne rozpowszechnianie zarówno oryginalnych, jak i zmodyfikowanych wersji programu. Jeśli masz legalną kopię motywu lub wtyczki na GPL, możesz ją dalej dystrybuować – także za pieniądze.

Trzeba jednak oddzielić kod od elementów niebędących kodem. Nie możesz legalnie sprzedawać pełnej „kopii produktu” z cudzym logo, nazwą, grafikami stockowymi czy materiałami marketingowymi, jeśli te elementy są na innych licencjach (znaki towarowe, licencje stockowe itp.). Najbezpieczniej jest oferować własny fork pod własną nazwą i z własnym brandingiem.

Czy licencja GPL oznacza, że mogę wszystko kopiować, łącznie ze zdjęciami z demo?

Nie. GPL obejmuje przede wszystkim kod programu (PHP, część JS, CSS). Zdjęcia demo, ikony, fonty, pliki PSD czy materiały marketingowe często mają odrębne licencje: stockowe, komercyjne lub autorskie wydawcy.

Typowy scenariusz: kod motywu możesz używać i forknąć bez ograniczeń GPL, ale przeniesienie dokładnie tych samych zdjęć stockowych do innego projektu może naruszać licencję banku zdjęć. Zawsze sprawdzaj, czy paczka nie zawiera osobnych warunków dla grafik i fontów.

Czy złamanie warunków „licencji na 1 stronę” to piractwo?

Nie jest to klasyczne „piractwo” w rozumieniu naruszenia praw autorskich do kodu, jeśli kod jest na GPL. To naruszenie warunków umowy z dostawcą (np. regulaminu sklepu), czyli kwestia prawa cywilnego, a nie karnego ścigania za kopiowanie oprogramowania bez zgody.

Dostawca może np. zablokować dostęp do aktualizacji lub wsparcia, a w skrajnych przypadkach dochodzić roszczeń z tytułu złamania umowy. Nie może natomiast cofnąć ci praw wynikających z GPL do już otrzymanego kodu.

Czy klucz aktywacyjny (license key) jest obowiązkowy z punktu widzenia GPL?

Nie. GPL nie wymaga żadnych kluczy do „legalnego” uruchomienia programu. License key to narzędzie biznesowe producenta, służące głównie do weryfikacji uprawnień do aktualizacji, wsparcia i integracji z zewnętrznymi usługami.

Brak klucza zwykle oznacza brak automatycznych aktualizacji, importu dem, premium supportu itp., ale sam kod – jeśli jest na GPL – nadal możesz uruchomić, modyfikować i kopiować. Ograniczenie dotyczy więc usług, a nie podstawowego prawa do korzystania z programu.

Czy mogę zmodyfikować motyw lub wtyczkę WordPress i sprzedawać jako własny produkt?

GPL zezwala na tworzenie forków (zmodyfikowanych wersji) i ich dalszą dystrybucję, także komercyjnie, pod warunkiem że:

• twój kod również będzie udostępniony na GPL (lub licencji zgodnej),
• nie naruszysz cudzych znaków towarowych (nazwa, logo) ani licencji na grafiki, fonty czy inne zasoby.

W praktyce oznacza to: zmieniasz nazwę, branding, usuwasz elementy na innych licencjach, dodajesz własne modyfikacje i oferujesz produkt jako własny, ale z zachowaniem GPL dla kodu. Dzięki temu nie wchodzisz w konflikt ani z licencją, ani z prawem znaków towarowych.