Il codice "watermarking" con spazi vuoti finali casuali è un buon modo per rilevare il plagio?

Question

Il codice "watermarking" con spazi vuoti finali casuali è un buon modo per rilevare il plagio?

#1 da (20 voti)
#2 da (18 voti)
#3 da (6 voti)
#4 da (2 voti)
#5 da (2 voti)

3

Considera questo:

int f(int x)  
{    
    return 2 * x * x;      
}

e questo

int squareAndDouble(int y)  
{    
    return 2*y*y;      
}

Se li hai trovati in corpi di codice indipendenti, potresti dare ai due programmatori il beneficio del dubbio e assumere che abbiano prodotto più o meno la stessa funzione indipendentemente. Ma guarda lo spazio bianco alla fine di ogni riga di codice. Stesso schema in entrambi. Sicuramente prova di copiare. Su una porzione più ampia di codice, la correlazione di spazi vuoti casuali alle estremità della linea sarebbe la prova inconfutabile di un'origine condivisa.

Ora, a parte le evidenti debolezze: ad es. visibile o evidente in alcuni editor, facilmente rimosso, mi chiedevo se valesse la pena implementare qualcosa di simile nel mio progetto open source. Il mio settore ha una storia di aziende che strappano progetti open source.

open-source whitespace copy-protection copy-paste-programming

posta paperjam 04.12.2012 - 20:01

fonte

5 risposte

Leggi altre domande sui tag open-source whitespace copy-protection copy-paste-programming

bilanciamento del carico nel cluster nulla condiviso Come ASCIUGARE con le chiamate a un database da eseguire?

score 20 · Answer 1

20

Poiché "Riduci spazio bianco al salvataggio" è una funzionalità di molti IDE, non penso che ciò sia positivo per qualcosa.

risposta data 04.12.2012 - 20:29

fonte

score 18 · Answer 2

Innanzitutto, se qualcuno estrapola un progetto open source, presumibilmente per creare un progetto closed source, presumibilmente non avresti accesso alla fonte del progetto closed source senza una causa legale e prove sufficienti per ottenere un ordine del tribunale essere in grado di esaminare il codice sorgente. Questo tende a essere una barra relativamente alta da cancellare prima che tu possa anche accedere alla fonte per confrontare lo spazio bianco.

Supponendo che tu abbia la motivazione per presentare una causa e che tu possa raccogliere prove sufficienti a suggerire di copiare senza usare la fonte, tuttavia, non è ovvio per me quanto sia benefica l'analisi dello spazio bianco. Se questo è un vero progetto open source che ha successo abbastanza da rubare, è probabile che lo spazio bianco cambierà abbastanza regolarmente nel tempo mentre le persone inviano nuove versioni di codice, così la "filigrana" cambierà nel tempo. Se si presume che la società che sta strappando il codice stia cercando di modificare i nomi delle variabili e la spaziatura della sorgente significativa (che renderebbe molto difficile applicare le modifiche al progetto open source), sembra probabile che il la società aggiungerebbe rapidamente un passaggio per rimuovere gli spazi bianchi finali dal loro codice.

La maggior parte delle aziende (e sviluppatori) che rubano il codice fanno molto più sfacciatamente. Stanno solo andando a copiare e incollare il codice funzionante nel loro progetto e premere Compila. Non si preoccuperanno di cambiare i nomi delle variabili o di cambiare il nome di una procedura o qualsiasi altra cosa che richiede loro di capire e testare le modifiche. Ci saranno generalmente pistole fumanti molto più grandi del numero di spazi alla fine della linea.

score 6 · Answer 3

No.

Gli spazi bianchi non sono sufficienti per dimostrare una filigrana come suggerisci.

L'esecuzione del codice tramite un formattatore di stile che modifica le schede in spazi o viceversa e parte della filigrana è stato modificato. Inoltre, in base alle regole di stile esistenti, lo spazio finale potrebbe essere troncato per rispettare la regola di stile.

Supponendo che potrebbe provare il "furto", cosa faresti? Hai reso il codice open-source, quindi stai dando via il codice sorgente. E in che modo avresti accesso al loro codice sorgente in primo luogo?

score 2 · Answer 4

Potrebbe anche essere un'indicazione sull'utilizzo dello stesso editor scadente che non ripulisce le terminazioni di riga.

Ho trovato alcune migliaia di righe di codice assembly non commentato in un progetto su cui stavo lavorando oltre un decennio fa. All'epoca mi chiedevo se questo significasse che si trattava di codice plagiato con i commenti spogliati.

In definitiva, questa è una domanda legale e la risposta migliore è probabilmente "dipende dalla giurisdizione". Le leggi sul copyright tra Stati Uniti e Regno Unito sono simili, non conosco altri paesi, e certamente ci sono ulteriori difficoltà se il copyright è detenuto in un paese e violato in un altro.

L'uso di schemi di spaziatura alla fine delle linee è comunque un'idea interessante. Alcuni editor (come IntelliJ ed Emacs) tronceranno automaticamente tutti gli spazi bianchi finali per te, quindi non so quanto sarebbe efficace.

Ecco le linee guida di Wikipedia (non i consigli legali, solo ciò che funziona per loro).

score 2 · Answer 5

Non credo che sarà di alcun beneficio, se la piattaforma / lingua utilizza un sistema di formattazione (come i formattatori presenti nell'ecosistema Delphi / FreePascal, la funzionalità di stampa di VB.NET, il formattatore C # su VS, ecc. ...

Quindi se il codice è passato da quegli strumenti e considerando che lo strumento è nelle sue impostazioni predefinite, tutti i watermarking sono spariti.

Alcuni editor hanno anche funzionalità per rimuovere gli spazi bianchi alla fine di una riga (penso che l'espressione sia "spazi vuoti finali" - l'inglese non è la mia prima lingua).

Se gli sviluppatori di piattaforma / lingua non fanno molto uso degli IDE con funzionalità di formattazione automatica, la filigrana può - in teoria - funzionare.

Ma non ci credo molto.