Quote:
Originariamente inviato da Bellaz89
Beh, accademicamente parlando e' corretto, ma di fatto un codice per essere ritenuto realmente open-source deve rispettare alcuni parametri in fatto di qualita'. Poi ognuno ha i suoi standard per definire cosa e' accettabile o cosa non lo e'. Ma fornire codice offuscato non e' in generale una pratica ben vista.
|
Questo lo sa, ma a me non interessa di essere ben visto.
Quote:
Comunque non credo che il tuo progettino di offuscamento sia valido con la GPL(altre licenze non so):
Dal paragrafo 1
E questo proprio per evitare che codice offuscato possa aggirare la licenza.
|
Sì, questo serve effettivamente per tutelarsi dall'offuscamento del codice, ma credo ci sia una scappatoia, sebbene più complicata.
Dovrebbe essere sufficiente mantenere i sorgenti coperti da GPL in maniera separata da quelli che li andranno a patchare per generare poi i binari finali.
Prima della compilazione utilizzi il tool di cui parlavo per offuscare il codice GPL, poi i file della patch, e infine esegui il merge della patch al codice GPL. A questo punto puoi compilare per tirare fuori l'eseguibile.
Richiede molto più lavoro, ma dovrebbe funzionare.
Quote:
Che ti devo dire. Sfiga. Anche perche' il bug e' nato da un utilizzo non avveduto di un tool di sanitizzazione.
Purtroppo questi errori sono possibili(e accadono!) indipendentemente dal modello di sviluppo utilizzato, a tutti.
C'e' comunque da riflettere che il team di debian si premura di fare test di sanita' su codice non prodotto da debian stesso. E questo probabilmente accade per le altre maggiori distro.
|
Senz'altro, ma... capita, per l'appunto. Perché gli sviluppatori sono esseri umani, e gli errori li commettono a prescindere che lavorino su codice open o closed.
Un altro esempio di qualche anno fa:
Scoperta vulnerabilità Null Pointer nel kernel Linux