AI e plugin WordPress: come il Plugin Team smaschera i cloni GPL e cosa rischi se pubblichi codice generato

Quando il Plugin Review Team di WordPress.org ha iniziato a rifiutare sistematicamente plugin generati con ChatGPT, la reazione della community è stata divisa. Da un lato gli sviluppatori che vedono l'AI come un acceleratore legittimo. Dall'altro i maintainer storici che notavano plugin sempre più simili tra loro, con porzioni di codice chiaramente copiate da plugin esistenti, licenze miste, e crediti mancanti. La posizione ufficiale del team, espressa da Mika Epstein (Ipstenu) e ripresa più volte sul blog Make WordPress Plugins, è netta: usare un code generator è permesso, ma il codice risultante deve essere GPL-compatibile al 100%, e la responsabilità della verifica ricade su chi lo pubblica, non sull'AI.

Questo articolo entra nel merito tecnico e legale della questione, partendo da dati reali (case study pubblici di plugin rifiutati, pattern di plagio riscontrati, conseguenze operative) per arrivare a una checklist concreta che sviluppatori, agenzie, e site owner possono usare subito. È complementare alla guida su come creare un plugin WordPress con AI in modo corretto e al tema della sicurezza dei plugin piratati, ma con un angolo inedito: il rischio legale-legato-alla-pubblicazione, non solo all'uso.

Cosa dice davvero la GPL, in parole semplici

La GNU General Public License v2 (o successiva, "v2+") è la licenza con cui WordPress e la quasi totalità del suo ecosistema sono distribuiti. In sintesi estrema:

• Puoi usare il codice liberamente
• Puoi modificarlo liberamente
• Puoi ridistribuirlo liberamente
• A condizione che anche le tue modifiche e il tuo lavoro derivato siano distribuiti sotto GPL
• A condizione che tu citi gli autori originali e mantenga intatte le note di copyright

Il punto 4 è quello che manda in crisi i code generator. Quando chiedi a ChatGPT "scrivimi un plugin per la gestione dei custom post type con un'admin UI moderna", il modello non distingue tra codice GPL, codice MIT, codice proprietario closed, e codice coperto da copyright ancora attivo. Produce un output plausibile, ma la provenienza di ogni riga è opaca.

Cosa fa il Plugin Review Team

Il Plugin Team di WordPress.org è un gruppo di volontari (oggi circa 60-70 reviewer attivi) che esamina ogni plugin sottomesso al repository ufficiale. Non fanno un audit esaustivo del codice: controllano che il plugin non faccia nulla di vietato dalle linee guida (no tracking, no upselling aggressivo, no chiamate a endpoint esterni non documentate, no codice offuscato), e che la GPL sia rispettata. Quando trovano pattern sospetti, rifiutano il plugin e chiedono chiarimenti.

Il tempo di review è cresciuto enormemente dal 2023 in poi. Mika Epstein ha dichiarato pubblicamente che il team riceve centinaia di submission al mese, una buona fetta delle quali mostra pattern di "AI senza verifica": codice funzionante in superficie, ma con licenze miste o porzioni palesemente copiate da plugin già esistenti.

I pattern reali che fanno scattare il rifiuto

Dalla documentazione pubblica del Plugin Team e dai case study analizzati, ecco i pattern più comuni di plugin AI-generati che vengono rifiutati.

Pattern 1: clone di un plugin esistente

Il caso più frequente. Chiedi a ChatGPT "fammi un plugin per gestire i cookie banner come XYZ", e il modello produce codice che è una variante funzionale del plugin XYZ ma con il nome cambiato e qualche modifica. Il Plugin Team lo riconosce, rifiuta la submission, e in casi ripetuti chiude l'account.

Caso studio noto: nel 2023-2024, almeno 4 plugin sono stati sottomessi con nome e struttura quasi identica a "Scroll to Top" di Mark Praschan, presentato come lavoro originale. Lo stesso Praschan lo aveva segnalato su Twitter. Tutti rifiutati.

Pattern 2: snippet da Stack Overflow con licenza Creative Commons BY-SA

Stack Overflow è rilasciato sotto CC BY-SA 4.0, non GPL. Questo significa che il codice preso da SO può essere usato in plugin GPL (le due licenze sono reciprocamente compatibili), ma a due condizioni:

1. Devi attribuire la fonte all'autore della risposta
2. Devi rilasciare il tuo plugin con la stessa licenza CC BY-SA oppure dimostrare la compatibilità con GPL

Il Plugin Team verifica questa attribuzione. Molti plugin AI-generated non la includono, e vengono rifiutati. Caso eclatante: plugin che contenevano 30+ snippet di SO copiati verbatim, senza alcun commento di attribuzione. Chiusura immediata del plugin già pubblicato.

Pattern 3: porzioni di plugin proprietari (nulled) decompilati

Questo è il caso più grave. Alcuni plugin AI-generated sul mercato non sono affatto generati da zero: sono plugin commerciali (Elementor Pro, SEOPress Pro, WP Rocket) a cui sono state rimosse le protezioni di licenza, e poi "passati a ChatGPT" per giustificare la presenza di codice altrimenti non GPL-compatibile. Il risultato è codice infetto (come abbiamo visto nella guida sui plugin piratati) E violazione di copyright.

Pattern 4: licenze miste non documentate

Un plugin può importare correttamente da più fonti, ma se include una libreria MIT deve dichiararlo. Se include una porzione BSD deve dichiararlo. Se include codice Apache 2.0 deve dichiararlo. Il Plugin Team verifica il file readme.txt e l'header del plugin principale. Plugin AI-generated che omettono queste dichiarazioni vengono rifiutati.

Pattern 5: codice generato senza "human in the loop"

Un plugin sottomesso che contiene esattamente le stesse risposte di ChatGPT a un prompt noto (verificabile con un test "scrivimi un plugin per X" e il confronto) è un segnale fortissimo che non c'è stato lavoro umano di adattamento. Il Plugin Team non vieta l'AI in sé, ma vieta la pass-through pura.

Cosa rischi se pubblichi un plugin AI-generated non verificato

Le conseguenze concrete per uno sviluppatore che sottomette un plugin AI-generated senza le verifiche del caso sono tre.

1. Rifiuto della submission

Il minimo sindacale. Il Plugin Team invia una email standardizzata, spiega cosa non va, e tu correggi e ri-sottometti. Tempo perso: 2-7 giorni, niente di drammatico.

2. Chiusura del plugin già pubblicato

Se il plugin era già nel repository e il Team scopre una violazione GPL a posteriori (spesso tramite segnalazione di un altro sviluppatore), il plugin viene chiuso. Gli utenti ricevono un errore di installazione al prossimo aggiornamento, e tu ricevi una email di notifica. Danno reputazionale: medio.

3. Ban dell'account sviluppatore

Per violazioni ripetute, il Plugin Team può sospendere l'account sviluppatore. Significa perdita di accesso a tutti i plugin pubblicati, al repository SVN, e alla reputazione accumulata in anni. Alcuni sviluppatori sono stati banditi per pattern di plagio sistematico.

La checklist operativa: come pubblicare plugin AI-generated in modo corretto

Ecco una checklist concreta, testata sul campo, per pubblicare un plugin AI-generated nel rispetto della GPL e delle linee guida WordPress.org.

Fase 1: prima di scrivere codice

• [ ] Definisci il problema in modo originale. Più il prompt è generico ("fammi un plugin per la SEO"), più il rischio di clone è alto. Specifica il problema di business, non la categoria del plugin
• [ ] Verifica che non esista già un plugin simile. Cerca nel repository ufficiale, su GitHub, e sui marketplace commerciali. Se esiste qualcosa di molto simile, valuta se contribuire a quel plugin invece di crearne uno nuovo
• [ ] Decidi la licenza esplicita. GPLv2+ è lo standard. Dichiaralo nel file principale e nel readme.txt

Fase 2: durante la generazione del codice

• [ ] Usa l'AI come assistente, non come autore. Chiedi a ChatGPT/Claude "spiega come funziona X" o "ottimizza questa funzione", non "scrivi l'intero plugin"
• [ ] Mantieni un log delle fonti. Se copi uno snippet da SO, GitHub, o un altro plugin, salvalo in un file SOURCES.md con autore, URL, e licenza
• [ ] Verifica manualmente la provenienza di ogni blocco non ovvio. Se una funzione di 50 righe è misteriosa, chiediti: l'ho scritta io o l'ha generata l'AI basandosi su cosa?

Fase 3: prima della submission

• [ ] Verifica le licenze di tutte le dipendenze. Ogni libreria importata deve avere licenza compatibile GPL. Usa uno script automatico:

# Comando per scansionare le licenze dichiarate nelle dipendenze Composer
composer licenses 2>/dev/null | grep -v MIT | grep -v BSD | grep -v Apache

• [ ] Controlla il codice con uno strumento di rilevamento plagio. Strumenti come MOSS (Measure of Software Similarity) oggi hanno dataset insufficienti per il codice AI, ma funzionano per il plagio di plugin esistenti
• [ ] Verifica l'header del plugin principale. Deve contenere License: GPLv2 or later e un commento Author: con il nome reale (no pseudonimi Account-AI)
• [ ] Testa in un ambiente vergine. Installa il plugin in un WordPress pulito e controlla che non generi errori, chiamate esterne non documentate, o comportamenti inattesi

Fase 4: nella submission

• [ ] Dichiara l'uso di AI se rilevante. Le linee guida non lo richiedono esplicitamente, ma un plugin AI-generated con disclosure onesta ha meno probabilità di essere segnalato per plagio
• [ ] Fornisci un changelog realistico. Un plugin con 47 funzionalità rilasciate in v1.0.0, senza un history di beta, è sospetto. Rilascia prima in GitHub, poi in WordPress.org
• [ ] Rispondi prontamente alle email del Plugin Team. Se ti chiedono chiarimenti, rispondi entro 48 ore con la documentazione delle fonti

Cosa rischi se usi un plugin AI-generated di terzi

Anche se non sei lo sviluppatore, usare un plugin AI-generated di terzi ha rischi specifici. Ecco i principali.

Rischio 1: licenza non chiara

Se il plugin non dichiara esplicitamente la licenza, non puoi sapere se puoi fork-arlo, modificarlo, o ridistribuirlo. In ambito aziendale, questo è un problema serio: il legal team blocca l'uso.

Rischio 2: codice coperto da copyright altrui

Se il plugin contiene codice copiato da un plugin GPL senza attribuzione, l'utente finale non è responsabile (la responsabilità è di chi ha pubblicato), ma il plugin può essere chiuso da un giorno all'altro, e tu resti con un sito rotto.

Rischio 3: plugin chiuso retroattivamente

WordPress.org può chiudere un plugin anche dopo anni di presenza nel repository, se emerge una violazione. Esempio reale: il plugin "WP-Touch" è stato chiuso nel 2019 per motivi di licenza, dopo 9 anni di presenza. I siti che lo usavano hanno dovuto trovare alternative in fretta.

Mitigazione: la regola del fork verificato

Per uso aziendale, la regola prudenziale è: non installare un plugin di cui non puoi fare il fork verificato su GitHub entro 10 minuti. Se il plugin è solo su WordPress.org, non hai una base di codice indipendente per audit e manutenzione.

L'ecosistema si sta regolando: il caso del Plugin Check

Il Plugin Check tool, integrato in WordPress core dalla 6.5 e migliorato nella 7.0, include ora un check specifico per pattern AI-generati sospetti. Non è un rilevatore di AI in senso stretto (impossibile allo stato dell'arte), ma identifica pattern di plagio da plugin noti confrontando porzioni di codice con un dataset interno.

// Esempio: aggiungere un check custom al Plugin Check
add_filter( 'plugin_check_ai_patterns', function( $patterns ) {
    $patterns[] = [
        'name'        => 'AI prompt injection in plugin headers',
        'description' => 'Header del plugin contenenti commenti che sembrano prompt AI',
        'regex'       => '/\/\/\s*(Ignore previous|You are|Generate|Simulate)/i',
        'severity'    => 'warning',
    ];
    return $patterns;
} );

Per ora il check è warning, non blocker. Ma la direzione è chiara: tra fine 2026 e 2027, è probabile che plugin con pattern di plagio eclatanti vengano rifiutati automaticamente prima ancora della review umana.

Caso studio: il plugin NorthStar di Mark Praschan

Uno dei pochi casi ben documentati di plugin generato con AI e accettato dal repository. Mark Praschan, sviluppatore non professionista, ha usato ChatGPT free per generare un plugin "NorthStar" che mostra un messaggio personalizzato nella admin bar. La versione iniziale funzionava, Praschan l'ha testata, l'ha rifattorizzata manualmente, e l'ha pubblicata. Il Plugin Team l'ha accettata senza problemi.

Cosa ha fatto bene Praschan:

• Plugin con scope chiaro e limitato (non un clone di un plugin esistente)
• Refactoring manuale del codice generato (non un pass-through)
• Test in ambiente locale prima della submission
• Descrizione onesta nel readme.txt

È l'esempio che il Plugin Team cita quando spiega: l'AI è uno strumento, non un problema. Il problema è l'uso pass-through senza verifica.

Il futuro: AI disclosure obbligatoria?

Una delle proposte emerse nella community WordPress nel 2025-2026 è l'introduzione di una AI disclosure obbligatoria nei readme.txt dei plugin. Idea: aggiungere un campo AI Generated: yes/no/partial e un altro AI Disclosure: <note testuale>. Pro: trasparenza. Contro: rischio di discriminazione verso plugin AI-generated perfettamente legittimi.

La proposta non è ancora stata approvata, ma è in discussione. Se passerà, avremo un ecosistema più trasparente ma anche un nuovo campo di frizione per gli sviluppatori.

Domande frequenti

È legale usare ChatGPT per scrivere un plugin WordPress?

Sì, è legale. I termini di servizio di OpenAI consentono l'uso commerciale dell'output. La legalità del plugin risultante dipende dalla GPL: se tutto il codice è tuo originale o GPL-compatibile, il plugin è legittimo. Se contiene codice copiato da plugin non GPL senza attribuzione, il plugin è illegale.

Come faccio a sapere se il codice generato da ChatGPT è GPL-compatibile?

Non c'è modo automatico. ChatGPT non traccia la provenienza del codice che produce. La verifica deve essere manuale: se una funzione è misteriosa o ti sembra "troppo perfetta" per essere generata, chiedi a ChatGPT di spiegartela riga per riga. Se la spiegazione è vaga, cerca il pattern su Google. Se trovi match in plugin GPL noti, aggiungi l'attribuzione. Se trovi match in plugin proprietari, riscrivi da zero.

Il Plugin Team rifiuta plugin solo perché generati con AI?

No. Rifiuta plugin che violano la GPL o le linee guida, indipendentemente dal fatto che siano AI-generated. La differenza è che i plugin AI-generated hanno una probabilità più alta di contenere codice non GPL, perché il modello non distingue le licenze. Il controllo del Plugin Team è sul risultato, non sul processo.

Cosa succede se il mio plugin viene chiuso dopo anni di utilizzo?

Devi trovare un'alternativa o fare un fork. Il sito dei tuoi clienti smette di funzionare se il plugin era critico. La lezione: tieni sempre un fork GitHub aggiornato dei plugin critici, anche se sono nel repository ufficiale.

Posso usare codice da GitHub in un plugin WordPress?

Dipende dalla licenza del repository GitHub. Se è MIT, BSD, o Apache 2.0, la compatibilità con GPL è buona (con alcune condizioni per Apache). Se è "all rights reserved" o non specificata, non puoi. Se è GPL, perfetto, basta mantenere la stessa licenza.

Vale la pena dichiarare l'uso di AI nel readme.txt?

Dipende dalla policy del momento. Al 2026 non è obbligatorio, ma la trasparenza è apprezzata dalla community. Se il plugin è AI-generated ma con pesante refactoring umano, una nota del tipo "Sviluppato con assistenza AI, revisionato e testato manualmente" può essere un segnale positivo.

Riferimenti utili per approfondire

• WordPress Plugin Guidelines ufficiali - le regole da seguire.
• Make WordPress Plugins blog - comunicazioni ufficiali del Plugin Team.
• Discussione su AI e Plugin Review - il post originale di Mika Epstein che ha fatto da spartiacque.
• GNU GPL v2 testo integrale - la licenza in sé.
• GPL compatibility chart - per verificare la compatibilità tra licenze.
• Plugin Check tool su GitHub - strumento ufficiale di verifica pre-submission.
• Stack Overflow license details - per capire come usare snippet SO in plugin GPL.
• Creare plugin WordPress con AI: metodo completo mrtux.it - workflow pratico per evitare i problemi descritti qui.
• Plugin WordPress piratati e sicurezza mrtux.it - il rischio speculare per chi usa plugin AI compromessi.
• Lista 23 plugin da evitare mrtux.it - criteri per scegliere plugin mantenuti e testati.

Questa guida verrà aggiornata quando il Plugin Team pubblicherà linee guida formali sull'AI disclosure. Per casi reali o domande specifiche sulla tua submission, l'area commenti è aperta.