Etichetta corretta per il porting di un progetto Github a una nuova tecnologia

4

Sto lavorando alla traduzione di un repository github, che non possiedo, da Python a Java. La logica rimarrà la stessa, che è significativa, in quanto si tratta di un'applicazione Neural Network, ma devo essere in grado di implementarla ed eseguirla in un modo più indipendente dalla piattaforma, e Python semplicemente non lo offre.

La mia domanda è questa: dovrei sborsare il repository originale per dimostrare che il mio lavoro è chiaramente derivato? Non ci sarebbe mai alcun potenziale per le richieste pull o le unioni, in quanto non ci sarà alcun codice in comune tra i due progetti ...

    
posta therealmitchconnors 21.01.2017 - 17:54
fonte

2 risposte

4

Se fossi l'autore del progetto originale, ciò che apprezzerei di più sarebbe se mi limitassi a chiedermi . Lasciare loro una breve e-mail che spiega come apprezzi il loro lavoro e che intendi portarlo su Java. In particolare, chiedi loro se hanno qualche preferenza sulla denominazione della tua porta. (Ad esempio, se il progetto originale è stato denominato Foo , puoi nominare la tua porta JFoo per correlarla strettamente all'originale o scegliere un nome non correlato se tale associazione non è desiderata .) Forse gli autori originali hanno anche bisogno di una porta Java e sarebbero anche disposti a collaborare con voi. Gli utenti di entrambi i progetti trarranno vantaggio da un collegamento nei rispettivi READMEs all'altro progetto. Forse gli autori rimpiangono persino la loro scelta originale di tecnologia e continuerebbero a sviluppare il nuovo progetto se qualcuno fornisse un aiuto sostanziale nel porting della base di codice esistente.

Se non ricevi una risposta entro un tempo ragionevole o se la loro risposta non è cooperativa, non hai perso nulla. Puoi ancora fare qualunque cosa ti permetta di fare la tua licenza. Sarebbe saggio, tuttavia, scegliere con cura le parole quando le avvicini per la prima volta in modo da chiarire che non stai chiedendo il permesso ma offri collaborazione. E ricorda che è un loro buon diritto non avere alcun interesse per il tuo porto e nemmeno essere scontento di questo. Se svilupperai la tua nuova porta senza le benedizioni degli autori originali, assicurati di scegliere un nome distinto per il tuo nuovo progetto che non implichi alcuna approvazione. Il tuo README dovrebbe ovviamente spiegare che il tuo progetto ha le sue radici nell'altro progetto, ma ora è sviluppato indipendentemente.

    
risposta data 22.01.2017 - 19:05
fonte
6

Il punto di forking è che la cronologia completa del repository originale rimane disponibile. Poiché i due repository sono collegati, è possibile unire o estrarre richieste tra loro.

Quando porti un progetto in una lingua diversa, probabilmente non sei interessato ad unirmi al repository originale. Anche la cronologia delle modifiche del codice originale sembra inutile. Avrei quindi avviato un nuovo repository e invece scriverei un file README che si collega alla versione originale.

    
risposta data 22.01.2017 - 18:04
fonte

Leggi altre domande sui tag