Le interfacce e le firme dei metodi sono protette da copyright?

Ad esempio, è una violazione del copyright se scrivo una classe chiamata Casuale con lo stesso identico scopo e le stesse firme del metodo della classe .Net System.Random di Microsoft? Fa differenza in che lingua è scritta? In questo caso, voglio scrivere una classe casuale da utilizzare in ActionScript, che manca di una classe PRNG con seeding incorporata.

Se qualcuno ha buoni collegamenti o suggerimenti di riferimento per capire quali aspetti del software sono protetti, anche questo è fantastico. E sì, lo so che questo non è il posto per una "vera" consulenza legale. Se qualcuno va in tribunale indicando una bacheca pubblica come una precendenza, vergognatevi.

Credo che la relazione tra Mono e Dotnet risponda a questa domanda. Il team di Mono può utilizzare le definizioni del metodo o l'interfaccia pubblica ma devono reimplementare gli interni. Tuttavia, la custodia Android v Oracle evidenzia alcuni altri punti che rendono questa ovvia distinzione un po 'più sfocata. Nel caso AvO la maggior parte dei punti portati in tribunale sono brevetti relativi alla VM, le interfacce della libreria non sono state un punto controverso. L'unico codice che è stato evidenziato sono esempi in cui sembra in qualche modo che gli interni siano stati copiati.

C'era una domanda simile sugli schemi di database: copiare lo schema di database di un concorrente? Ho risposto lì che copiare l'intero schema sarebbe probabilmente una violazione del copyright, a seconda della scala della copia, apprezzata da un giudice.

Anche se la tua domanda è simile, risponderò esattamente al contrario: puoi copiare le firme dei metodi. Perché?

In effetti, le firme dei metodi provengono dal buon senso.

• In primo luogo, se prendiamo un esempio estremo, Microsoft non può tutelare il nomeRandom e fare causa a tutti coloro che useranno la parola Randomin qualsiasi applicazione.

• In secondo luogo, cosa stai cercando di fare esattamente? Reimplementazione di .NET Framework? Perché? Non è necessario reinventare la ruota . Se sai come renderlo migliore, più intuitivo, ecc., È probabile che verrai con nomi migliori di classi e metodi, un'organizzazione migliore, ecc. Se provi a copiare la struttura di .NET Framework per portarlo su un altro lingua , quindi non sei un concorrente diretto di Microsoft, quindi non hanno seri motivi per farti causa (detto questo, ti faranno causa se copi il codice sorgente stesso). In realtà, trarranno beneficio anche da te: la copia di tale struttura in altri framework non solo mostrerà il successo di .NET Framework, ma renderà anche più facile per gli sviluppatori .NET lavorare con altre lingue e gli sviluppatori da altre lingue per imparare .NETTO.

• In terzo luogo, hanno cose più serie da fare che citare in giudizio tutti coloro che copieranno i nomi dei metodi e delle classi di .NET Framework.

Ora, se il tuo intento è quello di copiare l'intero .NET Framework e realizzare un prodotto che verrà utilizzato da molti sviluppatori, consulta un avvocato prima di assumerti dei rischi.

Un esempio:

Ero totalmente scontento della vergognosa limitazione di 259 caratteri nei percorsi dei file in .NET Framework e dell'incapacità di utilizzare le transazioni di codice a livello di file. Così ho implementato la mia Fileclasse con i metodi che avrebbero funzionato come previsto per qualsiasi percorso, non solo quelli piccoli, e implementavo le transazioni. Nella prima versione, ho deciso di clonare i nomi dei metodi Filee delle Directoryclassi . Microsoft mi farà causa per averlo fatto? Ne dubito.

In tutti i casi, nella seconda versione sono arrivato con una nuova sintassi new File(string fileName), che trovo molto più intuitiva per me . La clonazione di nomi di metodi è talvolta utile, ma devi avere una buona ragione per farlo.

La protezione del copyright protegge l '"espressione artistica" di un'opera, non la forma tecnica (per citare Wikipedia ).

La protezione del copyright non protegge i fatti .

Quindi la domanda diventa: un'API o un'interfaccia è un "fatto" o un'espressione artistica? Per le API semplici che sono solo un elenco di modi per ottenere numeri casuali e i diversi tipi di numeri casuali, l'API è probabilmente più simile a un fatto. Ma ho potuto vedere che esiste un'interfaccia molto sofisticata (sai, quelle che guardi per un minuto, e poi dire "Ahh! È impressionante.") Potrebbe essere considerata una "espressione artistica" degna di protezione.

Ecco un recente articolo su Oracle e Google che combattono per il copyright dell'API su questo stesso argomento dibattuto nei tribunali (USA).

Non sono un avvocato e questo post non deve essere interpretato come una consulenza legale. Non riesco nemmeno a scrivere disclaimer molto bene.

Puoi prendere gli aspetti puramente funzionali, ma non puoi prendere gli aspetti espressivi. Il nome della classe, i nomi dei metodi e le firme sono puramente funzionali. Ti servono per interagire. I nomi dei parametri e le macro di intestazione potrebbero essere considerati espressivi. Ad esempio, nel suo caso antitrust di Windows, Microsoft ha sostenuto che nulla ha impedito a un concorrente di replicare le API di Windows e creare la propria piattaforma su cui sarebbero state eseguite le applicazioni Windows.