Protezione di un nuovo formato di file? [chiuso]

Davvero non puoi

Se rendi il formato del file sufficientemente difficile da gestire ed eviti di fornire la documentazione per il formato di file effettivo, puoi fare la scelta logica per la maggior parte delle persone di utilizzare la tua API per interagire con il file. Nulla impedisce a qualcuno di dedicarsi all'ingegnerizzazione inversa del formato file e all'interazione con i file raw stessi, ma se è molto più semplice utilizzare la tua API, questo è il percorso che la maggior parte delle persone prenderà. E se rilasci costantemente nuove versioni che apportano sottili ritocchi che infrangono il codice esistente che non utilizza la tua API, puoi aumentare il fastidio che chiunque avrebbe a che fare con i tuoi file raw direttamente.

Questo è fondamentalmente (intenzionalmente e non intenzionalmente) il percorso seguito da Microsoft con i vari formati di file binari di Office. Erano sufficientemente complesse che se una suite per ufficio concorrente tentasse di leggere o scrivere qualcosa di più del file più semplice, inevitabilmente scoprirai che qualcosa è andato perso nella traduzione.

Ovviamente, se fai qualcosa di simile, particolarmente intenzionalmente, incorrerai nella collera di una grossa frazione di sviluppatori. Nella vasta maggioranza dei casi, se crei un formato di file, avrai più problemi a convincere le persone a supportarlo piuttosto che a impedire alle persone di manipolare i tuoi file proprietari. Avere persone che scrivono codice in grado di interagire facilmente con i tuoi file è in genere un importante fattore di successo del tuo formato di file. Alienare le persone che ti servono per generare popolarità per il tuo formato di file sarebbe quasi sempre una pessima idea.

Se definisci un formato di file, dovresti al contrario documentare pubblicamente le sue specifiche , poiché un formato di file è un mezzo per comunicare dati tra software e persone.

Non sono l'unico in ad evitare i formati di file chiusi . Se ne usassi qualcuno, sarei intrappolato nel prodotto che ne ha bisogno. In alcuni contesti e molte organizzazioni, che utilizzano un formato di file proprietario non documentato potrebbero essere disapprovate o vietate. In Francia, il governo di Ayrault ha emanato un decreto che favorisce standard aperti (e preferibilmente software libero). AFAIK, la Commissione europea sta facendo qualcosa di simile.

Quindi per avere successo , non vuoi "proteggere" il tuo formato di file, vuoi specificare il tuo formato di file nel miglior modo possibile in una specifica pubblica in modo che diventi di fatto uno standard (usato dai concorrenti).

E non puoi vietare legalmente il reverse-engineering del tuo formato (almeno non in Europa ; il reverse engineering di AFAIU è esplicitamente legale in Europa se fatto per ragioni di interoperabilità, ma IANAL).

Nascondere il tuo formato di file probabilmente lo renderebbe un fallimento a livello mondiale; nessuno lo userebbe (che ovviamente è la massima protezione, ma lo vuoi davvero?).

Non puoi proteggere legalmente un formato di file. Tuttavia, se il processo per creare o utilizzare il formato file è sufficientemente innovativo, tale processo può potenzialmente essere brevettato.

Ad esempio, il formato di file .gif non era protetto in alcun modo forma o forma. Tuttavia, l'algoritmo LZW utilizzato per comprimere o decomprimere i gif è stato assegnato ai brevetti.

Poco importava che avessero iniziato a far rispettare i loro brevetti. L'atto di farli rispettare ruotò .gif da uno dei 2 formati di immagine di base di Internet, in un formato non iniziale che ora viene usato solo perché gif89a consente alcune animazioni rudimentali senza un plug-in. .png ha ripreso il resto del mercato .gif. I brevetti ora sono tutti scaduti, ma è troppo tardi per il formato.