Oracle vieta il codice scritto dall’IA, ma c’è un paradosso
Il divieto vale per chi contribuisce a Java dall'esterno. In casa Oracle il fondatore dice l'opposto. La ragione della differenza riguarda tutti.
Oracle ha vietato il codice scritto dall’intelligenza artificiale. Ma solo agli altri. Il divieto riguarda chi contribuisce a OpenJDK, il progetto aperto da cui nasce Java, mentre dentro Oracle il fondatore racconta l’esatto contrario: il codice che Oracle scrive, dice, non lo scrive più Oracle.
Sembra una contraddizione da segnalare e archiviare. È invece la cosa più utile che un’azienda abbia messo per iscritto quest’anno sul rischio di usare l’IA per produrre software. Il motivo sta nella differenza fra i due casi.
Cosa dice la regola
La regola provvisoria, approvata dall’organo di governo del progetto, vieta i contributi che includono contenuti generati, in parte o del tutto, da modelli linguistici, modelli di diffusione o sistemi simili.
Il divieto è più largo di quanto suggerisca la parola codice. Copre anche i testi e le immagini nei repository, le richieste di modifica su GitHub, i messaggi di posta, le pagine wiki e le segnalazioni di errore. Resta permesso usare gli stessi strumenti in privato per capire, correggere e rivedere il codice esistente, purché quello che producono non venga inviato. Restano ammessi correttore ortografico, grammaticale e completamento automatico non basato su IA.
Quello che non è ammesso è dosare. Modificare a mano dieci righe su cento generate lascia il contributo per il resto generato, quindi fuori.
Tre rischi dichiarati: il terzo riguarda tutti
- Il carico di revisione. È facile produrre grandi quantità di codice dall’aspetto plausibile, con test dall’aspetto plausibile, che però è sbagliato oppure, anche quando funziona, è progettato male e difficile da mantenere. Rivederlo consuma il tempo di persone che ne hanno poco.
- La sicurezza. Java regge sistemi critici in imprese e amministrazioni di mezzo mondo. Del codice plausibile ma scorretto lì dentro è un rischio che il progetto non vuole correre.
- La proprietà intellettuale. L’accordo che i contributori firmano con Oracle richiede che siano titolari dei diritti su quello che cedono. Gli strumenti generativi sono addestrati in gran parte su contenuti protetti, il loro risultato può includere materiale che viola quelle licenze, e la domanda se chi usa uno strumento generativo abbia diritti sul suo risultato è, per usare le parole del documento, oggetto di cause in corso.
Il terzo riguarda anche chi non scriverà mai una riga di Java. Non dice che il codice generato è brutto. Dice che non si sa di chi sia.
Perché il paradosso non è ipocrisia
La distanza fra il divieto e il resto dell’azienda è notevole. Larry Ellison ha raccontato che i modelli scrivono il codice di Oracle, alla quale resta il compito di dichiarare l’intento. A giugno l’azienda ha tagliato 21.000 posti di lavoro, citando fra le ragioni la diffusione delle tecnologie di IA nelle proprie operazioni. Per l’anno che arriva ha annunciato 70 miliardi di dollari di investimenti nei centri dati, contro i 55,7 dell’esercizio chiuso a maggio, una scommessa a cui S&P ha risposto abbassando il giudizio sul credito a un gradino sopra i titoli spazzatura. Chiude il quadro un dettaglio interno: GraalVM, un altro progetto di Oracle, i contributi assistiti dall’IA li accetta.
La contraddizione l’ha notata The Register, che ha chiesto spiegazioni all’azienda. Per noi la spiegazione non è il doppio standard. Sta in una parola: responsabilità.
Dentro il proprio prodotto, un’azienda che usa l’IA per scrivere codice corre un rischio suo. Se salta fuori un problema di licenze, paga lei. Ha calcolato che ne valga la pena. In un progetto aperto la catena è rovesciata: migliaia di persone cedono diritti a Oracle, che poi distribuisce il risultato al mondo intero. Se in mezzo entra codice di cui nessuno può garantire la titolarità, il problema si scarica su chi lo ha messo nel pacchetto e su tutti quelli che lo usano.
Chi commissiona software si trova esattamente nella seconda posizione, non nella prima.
Cosa portarsi a casa
Tre domande da fare prima di firmare un contratto di sviluppo, oggi che la risposta non è più scontata.
- Il fornitore ha usato strumenti generativi? E se sì, ve l’ha detto spontaneamente? Non è una domanda ostile ma di inventario: senza risposta non sapete cosa avete comprato.
- Nel contratto c’è una garanzia su chi è titolare del codice consegnato? E soprattutto: chi risponde se quella garanzia viene contestata da un terzo?
- Chi rivede quel codice, con quanto tempo a disposizione? Se la quantità che prima richiedeva un mese ora arriva in tre giorni, il collo di bottiglia si è spostato sulla revisione. Quel costo va messo a preventivo.
Un’organizzazione che tiene in piedi Java ha risposto con un divieto largo e dichiaratamente provvisorio, in attesa di capire meglio. Non è la parola definitiva e lo ammette da sola. Ma la ragione che l’ha prodotta non scade in fretta: quelle cause non si chiudono questo mese, e fino ad allora la domanda su chi possiede il codice generato resta aperta per tutti.