Il cliente vuole il codice sorgente, ma contiene molto codice condiviso che riutilizzo con altri progetti

Ho un client che vorrebbe che io consegnassi il codice sorgente con un'applicazione binaria sviluppata. Inizialmente non avevano detto nulla sul codice sorgente, ma recentemente hanno affermato di averne bisogno. Il contratto non è stato finalizzato. Accettarono il lavoro, non firmarono e poi tornarono con questa clausola.

Il problema è: ho una base di codice che ho creato negli anni e usato come modello per la maggior parte delle applicazioni che scrivo. È molto più ampio dell'ambito del progetto.

Intendo anche usarlo per un prodotto, quindi non desidero davvero fornirlo per un progetto relativamente piccolo.

Immagino che questa non sia la prima volta che succede in questo settore. Qual è il modo migliore per aggirare questo problema? Immagino che cose come le librerie condivise potrebbero aiutare.

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 insistere su 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 "fai tutto questo". In primo luogo, decidere che cosa si è disposti a fornire e come si desidera essere compensata. Quindi portare il loro contratto con un avvocato e capire cosa deve cambiare. Quindi, negozia.

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

Scopri perché vogliono la fonte. Potrebbero volerlo, quindi avranno la possibilità di utilizzare un altro sviluppatore in seguito. Oppure potrebbero volerlo solo perché hanno paura che tu possa essere colpito da un autobus e all'improvviso rimarranno con binari che non possono migliorare. Se si tratta di questo secondo caso, consultare un servizio di deposito a garanzia del codice software . Questi servizi contengono il codice sorgente in caso di fallimento o in caso di impossibilità a mantenere il software. Questo può soddisfare sia il tuo desiderio di mantenere il tuo codice proprietario per servire gli altri clienti sia il loro desiderio di non rimanere nella borsa con un set di binari non mantenibile se succede qualcosa di brutto.

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

"Ciao, abbiamo deciso di voler semplicemente anche il codice sorgente, gratuitamente."
"Ciao, no."

Non è così difficile, davvero.

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

Non complicare le cose semplici.

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

Ma devi anche considerare attentamente - e scrivere nel contratto - le implicazioni della fornitura del codice. È solo così che il cliente può vederlo? Il cliente può modificarlo? E in particolare, prenderesti in considerazione la possibilità di concedere al tuo cliente diritti esclusivi per la base di codice che hai creato nel corso degli anni e viene utilizzato come modello per la maggior parte delle applicazioni in modo da non poterlo mai più utilizzare in futuro?

È necessario assicurarsi che il contratto dichiari esplicitamente chi ha i diritti per utilizzare il codice e in quali modi.

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 cosa oltre a quella sia una violazione del copyright. Quindi, se si consegna il codice sorgente, si avrebbe un contratto che chiarisce in modo assoluto che si conserva il copyright esclusivo del codice sorgente, ed esattamente quali usi del codice sorgente sono consentiti. E ovviamente il codice sorgente + la licenza non verrebbero gratis.

È improbabile che una grande azienda violi il diritto d'autore, poiché essere scoperti causerebbe un grave danno alla sua reputazione, oltre a quello finanziario. D'altra parte, pagare per il software senza alcuna garanzia che eventuali problemi possano essere risolti in futuro, potrebbe essere inaccettabile per il cliente.

Prima di solito fornivo al client il codice sorgente (librerie e tutti) con una licenza MIT. Se le tue librerie sono ben organizzate, fornisci solo i file / risorse necessari per quel particolare client, ma niente 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 cliente sotto contratto che non faceva parte della libreria prima. Quindi 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 i prezzi più alti per quelli che lo fanno). Ma, davvero per alcuni clienti quella discussione è stata molto confusa e talvolta ho finito per parlare con 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" per spiegare 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 (per essere riutilizzato da me e da loro) ma il codice relativo alla loro applicazione è solo per loro mantenere i propri termini (quel codice molto probabilmente sarebbe inutile per me riutilizzarlo in un altro progetto). Ovviamente tutto ciò che è correttamente scritto 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ì, potresti pensare di usare le librerie condivise. Tuttavia, ti chiedo, perché non fornisci loro il codice sorgente che hai usato, con una licenza che consentirà loro di ridurre il rischio? Penso che sarebbe giusto.

Il modo per affrontare questo è di negoziare.

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

D'altra parte ... se non sono disposti a pagare quello che vuoi, possono decidere di "portare i loro affari altrove".

Benvenuti nel mondo degli affari :-)

E quando parlerai con potenziali clienti in futuro, assicurati di menzionare presto questo problema ... per evitare di perdere tempo a tutti.

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

Questo potrebbe essere troppo tardi per te, in quanto potresti aver già concordato contrattualmente di farlo e potresti aver concordato termini reciprocamente incompatibili con clienti diversi.

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

Alcuni clienti vorranno la proprietà del codice sorgente. Ciò significa che alla fine del processo ti pagheranno soldi e in cambio darai loro il copyright del codice che crei per loro. Uno dei motivi è se vedono un potenziale significativo per la proprietà intellettuale nel codice sorgente e potrebbero voler valutarlo nel bilancio della propria azienda. In questo scenario, non avrai diritto all'uso continuato di quel codice sorgente per altri progetti, a meno che tu non ottenga anche una licenza dal tuo cliente che ti dà questo diritto.

Se il cliente sta acquistando un prodotto "pronto all'uso" da soli, 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 stiano beneficiando di un costo di acquisto inferiore a causa della più ampia base di clienti.

Tuttavia, la situazione in questa domanda è un miscuglio dei due.

Ecco cosa vorrei poter 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 sono in atto offerte per lavori futuri che si basano sul fatto che continui a utilizzare questo lavoro. sottolinea che ciò ha comportato meno tempo per questo progetto per i tuoi clienti e 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 svilupparlo e altri progetti basati su questa libreria. Tuttavia, se preferiscono la proprietà di tutto il codice, sei disposto a creare un sostituto, ma questo sarebbe un costo aggiuntivo.

A seconda di cosa ti sei già impegnato, potresti dover scrivere una funzionalità sostitutiva gratuitamente o regalare il tuo codice sorgente.

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

Se si utilizza una terza parte con il software fornito, è probabile che non si disponga del codice sorgente per questa terza parte. Consegnerai comunque il software all'azienda con file 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 società il codice sorgente del tuo framework. Puoi fornirle una buona documentazione API con un contratto di licenza e che. Se il tuo codice contiene la prossima grande novità che rivoluzionerà il settore, è un'altra storia, ma generalmente non è il caso.