La scorsa settimana un nuovo sito web di investigazione su Github Copilot creato da Matthew Butterick ha riportato la conversazione sul progetto Copilot di GitHub alla mente di molte persone, me compreso. Copilot , uno strumento addestrato sul codice pubblico progettato per suggerire automaticamente il codice ai programmatori, è stato accolto da entusiasmo, curiosità, scetticismo e preoccupazione da quando è stato annunciato.
Gli argomenti del sito di indagine di Github Copilot si basano sul lavoro precedente di Butterick, così come sull’analisi ponderata di Bradley M. Kuhn al Software Freedom Conservancy . Trovo che gli argomenti contenuti in questi pezzi siano convincenti in alcuni punti e non altrettanto convincenti in altri, quindi scrivo questo post nella speranza che mi aiuti a iniziare a sistemare tutto.
A questo punto, Copilot mi sembra uno strumento che sostituisce la ricerca su Google per le risposte di overflow dello stack. Sembra qualcosa che potrebbe essere utile. Sembra anche plausibile che la formazione di tale strumento su repository di software pubblici aperti (inclusi repository open source) possa essere consentita dalla legge sul copyright degli Stati Uniti. Ciò potrebbe cambiare se o quando Copilot si evolve, il che rende questa discussione fruttuosa da avere in questo momento.
Sia Butterick che Kuhn combinano argomenti legali e sociali/culturali nei loro pezzi. Questo post sul blog inizia con gli argomenti sociali/culturali perché sono più interessanti in questo momento e potrebbero avere un impatto sull’analisi legale man mano che i fatti si evolvono in futuro. Butterick e Kuhn fanno argomentazioni correlate, quindi farò del mio meglio per essere chiaro con quale versione specifica di un punto mi sto confrontando in un dato momento. Come probabilmente diventerà chiaro, in genere trovo l’approccio e l’inquadratura di Kuhn più perspicaci (il che non vuol dire che l’intuizione di Butterick manchi!).
Che cos’è Copilot, davvero?
Gran parte di questa discussione sembra prendere in considerazione il modo migliore per pensare e analogiare ciò che sta facendo Copilot (l’attuale pagina di Copilot fa un ottimo lavoro nell’illustrare come si potrebbe usarla).
Butterick sembra pensare che il modo corretto di pensare a Copilot sia come un motore di ricerca che indirizza gli utenti a una parte specifica di un pacchetto software specifico (spesso open source). Nelle sue parole, è “una comoda interfaccia alternativa a un ampio corpus di codice open-source”. È preoccupato che questa “interfaccia egoistica per il software open source” sia costruita attorno al ” dammi solo quello che voglio! ” (sottolinea il suo).
L’approccio egoistico può fornire agli utenti ciò che pensano di volere, ma così facendo nasconde la comunità che esiste attorno al software e rimuove le informazioni critiche che il codice è concesso in licenza con una licenza open source che viene fornita con obblighi. Se ho capito bene l’argomento, nel tempo questo atto di nascondere la comunità prosciugherà il software open source della sua vitalità. Ciò rende Copilot una minaccia per il software open source come concetto sostenibile.
Ma…
La preoccupazione di nascondere la comunità del software open source risuona con me. Allo stesso tempo, il punto di partenza di Butterick mi colpisce, almeno in termini di come cerco le risposte alle domande di codifica.
Questo è probabilmente un buon posto per fermarsi e notare che io sono un programmatore pessimo che, tuttavia, crea del codice che tende ad essere concesso in licenza aperta ed è quasi sempre costruito su altro codice open source. Tuttavia, non ho neanche lontanamente le competenze necessarie per dare un contributo tecnico significativo al codice di qualcun altro.
Oggi, la mia “comodo interfaccia alternativa” per trovare risposte quando ho bisogno di risolvere problemi di codifica è google. Quando mi imbatto in un problema di codifica, descrivo cosa sto cercando di fare o semplicemente incollo il messaggio di errore che sto ottenendo in Google. Se sono fortunato, Google mi indicherà lo stack overflow, o un post del blog, o pagine di documentazione o qualcosa di simile. Non credo di aver mai risposto a una domanda di codifica finendo in una parte specifica del codice open source in un repository pubblico. Se l’avessi fatto, sembra improbabile che il codice, anche se avesse ottimi commenti, mi avrebbe portato dove stavo andando da solo perché non avrei il contesto necessario per capire rapidamente che ha risposto alla mia domanda..
Questa distinzione tra “portami a far parte del codice open source” (punto di vista di Butterick) e “aiutami a fare questa cosa” (il mio punto di vista) è importante perché quando guardo il sito Web di Copilot, sembra che Copilot sia attualmente commercializzato come un commentatore di overflow dello stack potenzialmente utile, non qualcuno con una conoscenza enciclopedica di dove quel problema è stato risolto in altro codice open source. Butterick ha sperimentato Copilot a giugno e ha descritto l’output come “Questo è il codice che mi aspetterei da un talentuoso dodicenne che ha imparato a conoscere JavaScript ieri e i numeri primi oggi”. È proprio al mio livello!
Se poni a Copilot una domanda del tipo “come posso analizzare questo elenco e restituire un tipo diverso di elenco?”, nella maggior parte dei casi (ma, come sottolinea Butterick, non tutti!) sembra rispondere con una risposta sintetizzata da molti repository di codice pubblico invece di puntare semplicemente a un singolo repository di “risposta migliore”. Ciò rende Copilot più un esploratore di overflow dello stack che un esploratore di codice pubblico, sebbene sia esso stesso addestrato esplorando il codice pubblico. Sembra che riduca il tipo di danno descritto da Butterick.
Utilizzare a proprio rischio
Butterick e Kuhn sollevano anche preoccupazioni sul fatto che Copilot non fornisce alcuna garanzia sulla qualità del codice che suggerisce. Sebbene questa sia una preoccupazione ragionevole da avere, non mi sembra particolarmente unica per Copilot. Aspettarsi che Copilot fornisca ogni volta un codice funzionante e autorizzato, lo sta confrontando con uno status quo irrealistico.
Sebbene utili, i frammenti di codice che trovo in overflow dello stack/post del blog/qualunque cosa raramente hanno una licenza adeguata e sono sempre “usati a proprio rischio” (nella misura in cui funzionano). Le preoccupazioni di Butterick e Kuhn in quest’area sembrano ugualmente applicabili alla maggior parte delle mie risposte di overflow dello stack/post del blog. La documentazione di Copilot se abbastanza esplicita sul valore del codice che suggerisce (“Ti consigliamo di prendere le stesse precauzioni quando usi il codice generato da GitHub Copilot che avresti quando usi qualsiasi codice che non hai scritto tu stesso.”), per qualunque cosa sia di valore.
Copilot creerà un motivo in meno per interagire direttamente con il codice open source?
Secondo Butterick, un altro aspetto negativo di questo servizio “dammi solo quello che voglio” è che riduce il numero di situazioni in cui qualcuno potrebbe interagire consapevolmente direttamente con il codice open source. Con quale frequenza la maggior parte degli utenti interagisce direttamente con il codice open source? Come notato sopra, interagisco con molti software open source di altre persone come utente estremamente grato e importatore di librerie, ma non come contributore. Quindi Copilot sposterebbe la mia profonda interazione diretta con il codice open source da zero a zero.
Sono un outlier? L’eccellente libro di Nadia Asparouhouva (nata Eghbal) Working in Public fornisce informazioni sul software open source basato sul comportamento degli utenti su Github. In esso, tiene traccia di come la maggior parte degli utenti di software open source non faccia parte della comunità di sviluppatori attivi del software:
“Questa distribuzione – in cui uno o pochi sviluppatori fanno la maggior parte del lavoro, seguito da una lunga coda di contributori casuali e molti più utenti passivi – è ora la norma, non l’eccezione, nell’open source”.
Suggerisce anche che potrebbe esserci troppa comunità attorno ad alcuni progetti di software open source, il che è interessante da considerare alla luce della preoccupazione di Butterick per l’esaurimento della comunità:
“Il problema che i manutentori devono affrontare oggi non è come ottenere più contributori, ma come gestire un volume elevato di interazioni frequenti e a basso impatto. Questi sviluppatori non stanno creando comunità; stanno dirigendo il traffico aereo.
Ciò suggerisce che non sono necessariamente un outlier. Ma forse gli utenti come me non contano davvero nel grande schema dello sviluppo di software open source. Se Butterick ha ragione sull’impatto di Copilot sugli sviluppatori di software open source più attivi, potrebbe essere un grosso problema.
Inoltre, anche se gli utenti come me sono oggi rappresentativi e Copilot non è attualmente abbastanza bravo da distogliere le persone dall’interazione con il codice open source, potrebbe esserlo in futuro?
“Forse?” sembra l’unica risposta ragionevole a questa domanda. Come sottolinea Kuhn, “l’IA di solito è lenta e produce cambiamenti incrementali molto più spesso di quanto non produca cambiamenti radicali”. Kuhn sostiene giustamente che il cambiamento lento non è un motivo per ignorare una possibile minaccia futura. Allo stesso tempo, presenta la possibilità che un Copilot molto migliore possa esso stesso operare in un ambiente che è stato soggetto ad altri cambiamenti radicali. Questi cambiamenti potrebbero aumentare o ridurre gli impatti negativi di quel futuro Copilot.
Dove ci lascia? Il tipo di interazione casuale con il codice open source di cui Butterick è preoccupato potrebbe verificarsi meno di quanto ci si potrebbe aspettare. Allo stesso tempo, il Copilot di oggi non sembra un sostituto per qualcuno che vuole fare un tuffo più profondo in uno specifico pezzo di software open source. Una versione diversa di Copilot potrebbe, ma è difficile immaginare le altre cose che potrebbero essere diverse nel caso in cui quella versione esistesse. La versione odierna di Copilot non sembra manifestare del tutto la minaccia descritta da Butterick.
Copilot è formato su Open Source, non su Open Source
Per qualche ragione, sono entrato in questa ricerca pensando che Copilot fosse stato esplicitamente addestrato sul software open source. Non è del tutto corretto. Copilot è stato formato su repository Github pubblici. Questi includono molti repository di software open source. Includono anche molti repository di codice che sono solo pubblici, senza licenza, o una licenza non aperta o qualcos’altro. Quindi Copilot è stato formato sul software open source, nel senso che i suoi dati di addestramento includono una grande quantità di software open source. Non è stato formato su software open source, nel senso che i suoi dati di addestramento sono costituiti solo da software open source o che i suoi sviluppatori hanno cercato specificamente software open source come dati di addestramento.
Questa distinzione evidenzia anche una tendenza in evoluzione nel mondo open source, in cui i creatori confondono codice pubblico con codice con licenza aperta. Come osserva Asparouhouva:
”Ma la generazione GitHub di sviluppatori open source non la vede in questo modo, perché danno la priorità alla comodità rispetto alla libertà (a differenza dei sostenitori del software libero) o all’apertura (a differenza di tutti i sostenitori dell’open source). I membri di questa generazione non sono a conoscenza, né si preoccupano davvero, della distinzione tra software libero e open source. Né sono entusiasti di evangelizzare l’ idea stessa dell’open source. Pubblicano semplicemente il loro codice su GitHub perché, come con qualsiasi altra forma di contenuto online oggi, la condivisione è l’impostazione predefinita”.
Come avvocato che lavora con l’open source, penso che la distinzione tra “apertamente/liberamente autorizzata” e “pubblico” sia molto importante. Tuttavia, potrebbe non essere particolarmente importante per le persone che utilizzano software disponibile pubblicamente (indipendentemente dalla licenza) per approfondire la codifica. Sebbene questo possa essere un problema esacerbato da Copilot, non so che Copilot altera fondamentalmente le dinamiche sottostanti che lo alimentano.
È legale?
Come notato in alto, e attestato dal corpo di questo post finora, questo post inizia con le critiche culturali e sociali di Copilot perché questa è un’area più ricca di esplorazione in questa fase del gioco. Tuttavia, le critiche sono – abbastanza ragionevolmente – fondate su preoccupazioni legali.
Giusto uso
Le preoccupazioni legali riguardano principalmente il copyright e il fair use. Normalmente, per fare copie del software, è necessaria l’autorizzazione del creatore. Le licenze software open source concedono tali autorizzazioni in cambio del rispetto di obblighi specifici, come l’accredito del creatore originale.
Tuttavia, se la copia del software è protetta dal fair use, la fotocopiatrice non ha bisogno dell’autorizzazione del creatore e può ignorare qualsiasi obbligo in una licenza. In questo caso, Github non rispetta alcun requisito di licenza open source perché ritiene che le sue copie siano protette dal fair use. Dal momento che non ha bisogno di autorizzazione, non ha bisogno di copiare con i requisiti di licenza (sebbene a volte ci siano buone ragioni per rispettare l’intento sociale delle licenze anche se non sono legalmente vincolanti…). Lo ha detto, anche se (e la sua società madre Microsoft) ha rifiutato di approfondire ulteriormente.
Ho letto che Butterick insinuasse che il silenzio di Github e Microsoft sui dettagli della sua affermazione di fair use significa che l’affermazione stessa è debole: “Perché Microsoft non ha potuto produrre alcuna autorità legale per la sua posizione? Perché [Kuhn and the Software Freedom Conservancy] ha ragione: non ce n’è.
Non credo che la caratterizzazione sia giusta. Anche se ritengono che la loro affermazione sia forte, Github non può presumere che sia così forte da evitare contenziosi sulla questione (vedi, ad esempio, l’esistenza del sito Web di indagine Github Copilot stesso). Hanno tutte le ragioni per evitare di pre-contenzioso sulla questione del fair use tramite post sul blog e comunicati stampa, mantenendo la polvere asciutta fino al vero contenzioso.
Kuhn ha un approccio più sfumato (e corretto, per quanto mi riguarda) su come interpretare le domande: “In effetti, queste aree sono così sostanzialmente nuove che quasi ogni problema non ha risposte definitive”. Sebbene sia del tutto ragionevole respingere qualsiasi affermazione secondo cui la legge su questa domanda è risolta a favore di Github (Kuhn, ancora una volta, “Dovremmo semplicemente ignorare l’affermazione ridicola di GitHub secondo cui la “questione del fair use” sull’apprendimento automatico è risolta.”) , che è molto diverso dal suggerire che sia deciso contro Github.
Come farà a scrollarsi di dosso tutto questo? È difficile da dire. Google ha scansionato tutti i libri per creare strumenti di ricerca e analisi, sostenendo che le loro copie erano protette dal fair use. Sono stati citati in giudizio da The Authors Guild nel Secondo Circuito. Google ha vinto quella causa. La scansione dei libri per creare strumenti di ricerca e analisi è la stessa cosa della scansione del codice per creare il completamento automatico basato sull’intelligenza artificiale? In qualche modo si? In altri modi no?
Google ha anche vinto una causa dinanzi alla Corte Suprema in cui si basava sul fair use per copiare le chiamate API. Ma TVEyes ha perso una causa in cui ha tentato di fare affidamento sul fair use nella registrazione di tutte le trasmissioni televisive per facilitare la ricerca e la fornitura di clip. E la Corte Suprema sta attualmente esaminando un caso riguardante i dipinti di Prince di Warhold che potrebbero cambiare il fair use in modi inaspettati. Come ha notato Kuhn, siamo in un luogo di nuove domande senza risposte definitive.
E i Termini di servizio?
Come ha sottolineato Franklin Graves , è anche possibile che i Termini di servizio di Github gli consentano di utilizzare qualsiasi cosa in qualsiasi repository per creare Copilot senza preoccuparsi di ulteriori autorizzazioni di copyright. Se è così, non avranno nemmeno bisogno di arrivare alla parte del fair use dell’argomento. Ovviamente, ci sono probabilmente buone ragioni per cui Github non sta lavorando sodo per pubblicizzare il fatto che i loro ToS potrebbero dare loro molto spazio quando si tratta di utilizzare i caricamenti degli utenti sul sito.
Dove lascia le cose?
Per cominciare, penso che sia responsabile per i sostenitori di anticipare cose come questa. Come sottolinea Kuhn:
“In quanto tale, non dovremmo sopravvalutare la probabilità che questi nuovi sistemi accelerino lo sviluppo di software proprietario, mentre allo stesso tempo non riusciamo a impedire che il software soggetto a copyleft abiliti tale attività. Il primo potrebbe non verificarsi, quindi non dovremmo preoccuparci indebitamente del secondo, per non indirizzare male le risorse. In breve, l’IA è solitamente lenta e produce cambiamenti incrementali molto più spesso di quanto non produca cambiamenti radicali. Il problema quindi non è imminente né il danno irreversibile. Tuttavia, dobbiamo rispondere deliberatamente con tutta la dovuta celerità e iniziare immediatamente quel lavoro”.
Allo stesso tempo, non sono convinto che Copilot sia un problema. È possibile che una versione futura di Copilot possa far morire di fame il software open source della sua comunità o consentire alle persone di ricostruire efficacemente il codice open source al di fuori dell’ambito della licenza originale? Lo è, ma sembra che quella versione di Copilot sarebbe significativamente diversa dalla versione attuale in modi che sembrano difficili da prevedere. Il Copilot di oggi sembra più una corsia preferenziale per risposte di overflow dello stack possibilmente utili che un indice in grado di fornire frammenti non attribuiti di tutto il software open source.
Così com’è, la grave minaccia che Copilot presenta oggi al software open source sembra relativamente modesta. E i vantaggi potrebbero essere reali. Ci sono usi dell’odierno Copilot che potrebbero rendere più facile per più persone entrare nella programmazione, anche nella codifica open source. A volte la risposta di un talentuoso dodicenne è esattamente ciò di cui hai bisogno per superare la gobba.
Naturalmente, Github può avere ragione sul fair use E Copilot può essere utile E sarebbe comunque abbastanza ragionevole concludere che si desidera estrarre il codice da Github. Questo è vero anche se, come sottolinea Butterick, Github ha ragione sul fair use significa che il codice ovunque su Internet potrebbe essere incluso nelle versioni future di Copilot.
Sono contento che il Software Freedom Conservancy stia andando avanti e si stia prendendo il tempo per riflettere su cosa significhi. Sono anche curioso di vedere se Butterick finisce per sfidare le cose in un modo che metta direttamente alla prova le domande sul fair use.
Infine, l’intera discussione potrebbe anche rivelarsi un buon esempio del motivo per cui il copyright non è lo strumento migliore da utilizzare contro le preoccupazioni relative alla creazione di set di dati ML. Cercare soluzioni per il copyright ha il potenziale per estendere la legge sul copyright in strane direzioni, causare effetti collaterali inaspettati e indirizzare male le cose a cui tieni veramente. Questo è qualcosa di cui sono sempre diffidente, e un piore che informa la mia analisi qui. Naturalmente, Amanda Levandowski fa esattamente l’argomento opposto nel suo articolo Resisting Face Surveillance with Copyright Law .
Michael Weinberg da theverge.com
