Il client vuole il codice sorgente, ma contiene molto codice condiviso che riuso con altri progetti

La prima cosa da tenere a mente è che il codice sorgente ha un valore separato dai binari. È perfettamente ragionevole rifiutare di firmare un contratto che richiede la consegna del codice sorgente o di insistere per pagamenti extra per la consegna del codice sorgente. I contratti sono documenti a due vie. Non lasciare che l'altra parte imponga ciò che è richiesto solo perché sono "grandi aziende" e "fanno tutto il tempo". In primo luogo, decidi quali tuoi sono disposti a consegnare e in che modo tu vuoi essere ricompensato. Quindi prendi il loro contratto con un avvocato e stabilisci cosa deve cambiare. Quindi, negoziare.

Non fare quello che fanno molti giovani quando iniziano a contrattare. Non limitarti a firmare perché sembra che abbiano molta esperienza e tu no. Questo è un buon modo per essere derubati.

Cerca in perché vogliono la fonte. Potrebbero volerlo così hanno la possibilità di utilizzare un altro sviluppatore in seguito. Oppure potrebbero volerlo solo perché temono di essere investiti da un autobus e all'improvviso rimarranno binari che non possono migliorare. Se si tratta di questo secondo caso, consulta un servizio di garanzia del codice del software . Questi servizi contengono il codice sorgente in caso di fallimento o altrimenti non è possibile mantenere il software. Questo può soddisfare sia il tuo desiderio di mantenere il tuo codice di proprietà per gli altri clienti che il desiderio di non essere lasciato in possesso della busta con un insieme impossibile di binari se succede qualcosa di brutto.

"No" è una risposta perfetta, in realtà è una risposta incredibilmente utile che per qualche motivo non riesco a capire è molto sottovalutata.

"Ciao, abbiamo deciso in un secondo momento di volere solo il codice sorgente, gratuitamente."
"Ciao, no."

Non è poi così difficile,

Quindi, se desiderano pagare somme ingenti di denaro oltre ciò che già ti deve, potresti dare loro una versione tagliata della tua applicazione, che include solo il le fonti di cui hanno effettivamente bisogno, e avendo cura di ottenere assolutamente non - diritti esclusivi.

Non complicare le cose semplici.

La tua domanda è, "qual è il modo migliore per aggirare questo problema?" Ma cosa vedi come problema? Altri hanno giustamente sottolineato che è una questione di negoziazione: ogni cosa ha un valore, e spetta a te dare al cliente un prezzo per fornire ciò che è richiesto.

Ma devi anche considerare attentamente - e scrivere nel contratto - le implicazioni di fornire il codice. È così che il cliente può vederlo? Il cliente può modificarlo? In particolare, consideri di concedere ai tuoi clienti diritti esclusivi sulla base di codice che hai creato nel corso degli anni e viene utilizzato come modello per la maggior parte delle applicazioni in modo che tu non possa mai più utilizzarlo da solo in futuro ?

Devi assicurarti che il contratto indichi esplicitamente chi ha i diritti per utilizzare il codice e in che modo.

Ricorda che qualsiasi codice sorgente richiede una licenza. Se si consegna il codice sorgente, la società può utilizzare il codice sorgente per fare tutto ciò che la licenza consente e qualsiasi altra cosa è la violazione del copyright. Quindi, se si consegna il codice sorgente, si avrà un contratto che rende assolutamente chiaro che si mantiene il copyright esclusivo del codice sorgente, e esattamente quali usi del codice sorgente sono consentiti. E ovviamente il codice sorgente + la licenza non verrebbe gratis.

È improbabile che un'importante compagnia violi i diritti d'autore, perché l'essere scoperti causerebbe un grave danno alla loro reputazione, a parte i danni finanziari. D'altra parte, il pagamento di software senza la garanzia che eventuali problemi possano essere risolti in futuro potrebbe risultare inaccettabile per il cliente.

In precedenza, di solito fornivo al client il codice sorgente (librerie e tutto) con una licenza MIT. Se le tue librerie sono ben organizzate, fornisci solo i file / risorse necessari per quel particolare client, ma nulla di più. Penso che sia giusto sia per me che per il cliente. Tuttavia c'era sempre il problema del nuovo codice scritto per quel particolare client sotto contratto che prima non faceva parte della libreria. Così ho iniziato a discutere il problema con il cliente prima di iniziare il progetto. Alcuni clienti volevano la proprietà di quel codice, altri no (ho sempre dato incentivi negativi, come prezzi più alti per quelli che lo fanno). Ma, per alcuni clienti, la discussione è stata molto confusa ea volte ho finito per parlare di 3 o 5 persone diverse (incluso il loro avvocato) solo per ottenere l'approvazione del progetto.

Quindi ora tutte le mie librerie fanno parte di un framework personalizzato che utilizzo sempre per sviluppare e spiego al cliente che userò questo framework ma che il framework è un prodotto diverso con una licenza diversa. (A volte uso "componenti software" quando spieghiamo perché "framework" potrebbe non essere noto a loro). Fornisco sempre il codice dei file utilizzati sotto una licenza MIT e (poiché tutto il codice è ben organizzato) il codice di basso livello (anche il nuovo) rimane nel framework (da riutilizzare da me e da loro) ma il codice relativo alla loro applicazione è solo per loro di tenere sotto i loro termini (quel codice molto probabilmente sarebbe inutile per me riutilizzare in un altro progetto). Naturalmente tutto ciò che è scritto correttamente nel contratto. Penso che anche questo sia giusto.

La chiave è: "questi componenti sono un prodotto diverso" e tutto è scritto in un contratto prima di iniziare.

Quindi sì, l'idea di usare le librerie condivise potrebbe essere giusta. Tuttavia, ti chiedo, perché non fornisci loro il codice sorgente che hai usato, con una licenza che consenta loro di ridurre i rischi? Penso che sarebbe giusto.

Il modo di affrontare questo è negoziare.

Se vogliono il codice sorgente, dovrebbero essere pronti a pagare per questo, e spetta a te decidere quanto dovrebbe essere.

D'altro canto ... se non sono disposti a pagare quello che vuoi, potrebbero decidere di "portare altrove la loro attività".

Benvenuti nel mondo degli affari: -)

E se in futuro parlerai con potenziali clienti, assicurati di menzionare questo problema all'inizio ... per evitare di sprecare il tempo di tutti.

Vale anche la pena notare che ciò che stai facendo è un anatema per gli sviluppatori open source e per i clienti (istruiti) che sono alla ricerca di soluzioni open source.

Potrebbe essere troppo tardi per te, in quanto potresti già aver contrattualmente contratto per farlo, e avresti potuto accettare termini mutualmente incompatibili con diversi clienti.

Ci sono due modi in cui puoi fornire ai tuoi clienti il tuo codice sorgente. Proprietà del copyright e concesso in licenza.

Alcuni clienti vorranno la proprietà del codice sorgente. Questo significa che alla fine del processo ti pagheranno dei soldi e in cambio darai loro il copyright del codice che crei per loro. Una ragione di questo è se vedono un potenziale significativo di proprietà intellettuale nel codice sorgente e potrebbe voler valutare questo valore nel loro bilancio aziendale. In questo scenario, non avrai diritto all'utilizzo continuato di quel codice sorgente per altri progetti, a meno che tu non ottenga anche una licenza dal tuo cliente che ti concede questa autorizzazione.

Se il tuo cliente acquista da te un prodotto "off-the-shelf", si aspetterebbe di ricevere una licenza per utilizzare il software, non la proprietà del codice sorgente. Dovrebbero aspettarsi che tu stia vendendo lo stesso (o simile) software a molte altre organizzazioni, e che si spera che beneficino di un costo di acquisto inferiore a causa della più ampia base di clienti.

Tuttavia, la situazione in questa domanda è un miscuglio di entrambi.

Ecco cosa vorrei essere in grado di fare. Concederei al tuo cliente una licenza per utilizzare (e modificare) il tuo codice condiviso. Se interrogato dal cliente, vorrei sottolineare che questo è un codice condiviso che hai già utilizzato in più progetti e che hanno offerte in atto per il lavoro futuro basato su te che continui a utilizzare questo lavoro. Fai notare che questo ha comportato meno tempo per questo progetto per il tuo cliente e che, di conseguenza, hanno pagato un prezzo inferiore. Come altre librerie condivise di codice utilizzate dal progetto, dispongono di una licenza per utilizzare questo codice e per consentire ad altri team di sviluppo di sviluppare questo e altri progetti basati su questa libreria. Tuttavia, se preferiscono la proprietà di tutto il codice, sei disposto a creare una sostituzione, ma questo sarebbe un costo aggiuntivo.

A seconda di ciò a cui ti sei già impegnato, potresti dover scrivere una funzionalità sostitutiva gratuitamente o dare via il tuo codice sorgente.

Ricorda, ci sono diversi tipi di librerie. La libreria di modelli standard in C ++ è un buon esempio di una libreria che è inclusa a livello di codice sorgente ed è compilata in un eseguibile del progetto che potrebbe essere abbastanza simile a come hai usato il tuo codice comune.

Se si utilizza una terza parte con il software fornito, è probabile che non si disponga del codice sorgente per questa terza parte. Continuerai a consegnare il software alla compagnia con i binari di terze parti. Il codice che hai sviluppato come framework condiviso in tutti i tuoi progetti è esattamente come una terza parte, anche se di tua proprietà. In questo caso, la società ha esattamente lo stesso rischio con i file binari del framework che con la terza parte. Perché in questo caso daresti alla compagnia il codice sorgente del tuo framework. È possibile fornire a lei una buona documentazione API con un accordo di licenza e che esso. Se il tuo codice contiene la prossima grande novità che rivoluzionerà il settore, è un'altra storia, ma in genere non è così.