Non sono d'accordo con la maggioranza qui. Chiaramente la maggior parte delle persone dice che non dovresti farlo. Non sono necessariamente in disaccordo con questo, ma il sottotesto e in molti casi il messaggio palese è che legalmente non puoi farlo piuttosto che semplicemente non dovresti farlo . La correttezza giuridica di quel messaggio è tutt'altro che chiara nel tuo caso e in generale.
È bello vedere che, sebbene io sia in minoranza, non è così oscuro che nessun'altra risposta sia d'accordo con la mia opinione o che tutte le risposte che concordano con la mia opinione siano valutate negativamente. Sono d'accordo con lo spirito del messaggio di @ Kittoes0124.
In quanto minoranza, dovremmo certamente imparare qualcosa dalla prudente maggioranza: molti sviluppatori sono stati licenziati o peggio per violazione del copyright o altro violazione della proprietà intellettuale. Il risultato, sfortunatamente, è stato un eccesso di difensiva nella comunità e il risultato è un danno alla comunità Open Source e alla società nel suo insieme, che beneficia di una forte comunità di sistemi operativi.
Uno un commento a proposito ha fatto riferimento a Clean Room Design, che è un metodo legalmente riconosciuto e collaudato di replica delle funzionalità senza violazione del copyright. Notare cosa l'articolo collegato dice sulla progettazione di camere bianche, con supporto legale specifico:
La progettazione di camere bianche è solitamente impiegata come best practice, ma non strettamente richiesta dalla legge . In NEC Corp. v Intel Corp. (1990), NEC ha chiesto un giudizio dichiarativo contro le accuse di Intel secondo cui gli ingegneri di NEC hanno semplicemente copiato il microcodice del processore 8086 nel loro clone NEC V20. Un giudice statunitense ha stabilito che mentre le prime revisioni interne del microcodice di NEC erano effettivamente una violazione del copyright, quella successiva, che in realtà è entrata nel prodotto di NEC, sebbene derivata dal primo, fosse sufficientemente diversa dal microcodice Intel da poter essere considerata esente da violazioni del copyright.
Questo è lo standard corretto negli Stati Uniti. Si basa sulla giurisprudenza, non sull'opinione degli sviluppatori o sugli aneddoti. È consentito fare riferimento a codice proprietario e all'esperienza personale come riferimento e persino utilizzare quel codice letterale come punto di partenza concreto, ma il codice finale deve essere "sufficientemente diverso".
Sembra essere un ambiguo e standard arbitrario perché è esattamente così. I giudici variano in termini di clemenza nell'interpretazione della regola, ma la regola è chiara. La saggezza comune è "meglio prevenire che curare", ed è per questo che molti professionisti purtroppo evitano la visualizzazione pubblica di qualsiasi codice. In genere è più intelligente e meno rischioso cercare l'approvazione aziendale interna, ma non è generalmente richiesto dalla legge. Potrebbe essere richiesto dalla legge se hai firmato alcuni documenti aggiuntivi o se la tua giurisdizione ha una legge speciale.
Una nota importante nel tuo caso specifico è che c'è un'importante differenza tra il codice che proponi di spedire e il codice originale. Dichiari che il codice originale è specifico della piattaforma e proponi di spedire codice indipendente dalla piattaforma. Ciò significa che ci sono casi d'uso che il codice legacy non può supportare. Questo è un metodo per dimostrare una differenza significativa. Potresti rafforzare ulteriormente questa differenza rendendo la tua soluzione intenzionalmente incompatibile con la piattaforma legacy. Ciò significherebbe che non vi è alcuna sovrapposizione di casi d'uso.
Non sono un avvocato e questa non è una consulenza legale. Ti consiglio di consultare un avvocato se decidi di fare qualcosa del genere. Vedo molti precedenti legali statunitensi a sostegno del fatto che quando si codifica si attingerà naturalmente all'esperienza e alla conoscenza precedenti, incluso il riferimento a esempi concreti di codice, e questo non rende l'Open Source illegale.
L'uso della stessa sintassi non deve essere un problema. Molti linguaggi e librerie forniscono solo un modo sintattico per eseguire una determinata operazione ed esistono best practice per funzioni, variabili e così via, in modo tale che l'utilizzo anche degli stessi nomi di variabile potrebbe essere inevitabile per la replica delle funzionalità. In casi come questo, una differenza significativa potrebbe essere impossibile e quindi non ragionevolmente richiesta.
Tieni presente che queste nozioni generali sarebbero completamente indifendibili se firmassi un accordo di non divulgazione specifico o determinati altri documenti.
Altre due note correlate. In primo luogo, le violazioni della proprietà intellettuale sono soggette a uno statuto di limitazioni negli Stati Uniti ( fonte):
La violazione di un copyright può comportare responsabilità civile e / o penale. Il termine di prescrizione per un procedimento penale è di cinque anni, mentre per un'azione civile è di tre anni.
Una seconda nota è che ci sono solo 4 tipi (AFAIK / IANAL) di proprietà intellettuale ( fonte):
- Copyright
- Marchio commerciale
- Brevetto
- Segreti commerciali
Se hai a che fare con IP che non rientra nelle categorie 1-3, è meno problematico dal punto di vista legale adattare il codice per uso personale. Mi sembra difficile che qualcuno possa sostenere che X è un segreto commerciale se X è un pattern o una caratteristica comune in altri software, in particolare se esiste già in progetti Open Source.