Come Scrivere un Contratto Freelance per la Proprietà del Codice Sorgente

1. Definisci l'esatto risultato di proprietà del codice

Prima di scrivere una singola clausola, decidi cosa sta realmente acquistando il cliente. La cessione totale, una licenza o la proprietà solo dopo il pagamento finale non sono la stessa cosa, e il contratto dovrebbe corrispondere all'accordo commerciale che desideri realmente. Se il cliente si aspetta di possedere il codice sorgente dal primo giorno, dillo. Se il freelancer mantiene i diritti fino a quando l'ultima fattura non viene saldata, dillo anche. Una frase vaga causa mesi di attriti.

Qui è dove "come scrivere un contratto freelance per la proprietà del codice sorgente" inizia a diventare pratico. Un fondatore di startup potrebbe voler trasferire l'intero repository, mentre una piccola agenzia potrebbe aver bisogno solo di una licenza ampia per eseguire l'app. Questi sono affari diversi. Un contratto che li mescola può lasciare entrambe le parti infastidite, e nessuna delle due completamente protetta.

Usa il contratto per rispondere a tre domande dirette: chi possiede il codice, quando la proprietà passa di mano e se il cliente può modificare o rivendere il lavoro. Se la risposta è “dopo il pagamento finale,” specifica che non ci sarà alcun trasferimento prima che il pagamento venga saldato. Se la risposta è “cessione totale dalla creazione,” scrivilo chiaramente e senza drammi. Frasi brevi aiutano in questo caso.

Per un buon confronto sull'uso attento delle piattaforme, vedi come assumere un freelance in sicurezza. Quell'articolo riguarda la scelta saggia delle persone; questo riguarda la scrittura dell'accordo una volta che le hai scelte.

2. Identifica i specifici beni di codice in ambito

Non lasciare che “codice sorgente” fluttui come una frase rassicurante. Nomina le risorse. Se il progetto include codice dell'app, script, repository, file di build, configurazioni di deployment, documentazione e qualsiasi codice rifattorizzato o derivato creato durante il progetto, elencali. Un contratto che dice solo “il codice” invita a discussioni in seguito. Due parole non sono sufficienti.

Pensa in termini di cartelle e file, non di astrazioni. Ad esempio, l'ambito può coprire il repository principale dell'applicazione, un repository separato per il pannello di amministrazione, script CI, file di migrazione del database, wrapper API e un README che spiega la configurazione locale. Se il freelancer crea una versione patchata di un modulo esistente durante il progetto, decidi se quella patch fa parte del deliverable. Quel dettaglio è importante.

Ecco un modo semplice per definire l'ambito: “Tutto il codice sorgente e i file di progetto correlati creati per il Progetto X, inclusi il codice scritto nel Repository A e qualsiasi codice derivato o rifattorizzato prodotto durante il periodo di questo accordo.” Quella frase non è elaborata. Funziona perché nomina il luogo, il tipo di lavoro e la finestra temporale.

Se il progetto ha più repository, allega un elenco numerato. Un repo, una riga. Due repo, due righe. Il contratto non dovrebbe costringere qualcuno a indovinare se il pacchetto dell'app mobile conta come codice sorgente o solo come un artefatto esportato.

3. Aggiungi una chiara clausola di assegnazione della proprietà intellettuale

La clausola di cessione della proprietà intellettuale è il cuore del contratto. Dovrebbe indicare che il freelancer cede al cliente tutti i diritti, il titolo e l'interesse nel codice creato. Se il trasferimento avviene al momento della creazione, dillo. Se avviene al momento del pagamento, dillo invece. La clausola non dovrebbe basarsi su un'assunzione nascosta.

Una clausola pratica può essere formulata così: “Al pagamento completo di tutti gli importi dovuti ai sensi di questo accordo, il Freelancer cede al Cliente tutti i diritti di proprietà intellettuale sui deliverables creati specificamente per il Cliente nell'ambito di questo progetto, escludendo eventuali materiali preesistenti elencati nell'Allegato A.” Questa formulazione fornisce un punto di trasferimento, una condizione di pagamento e un'eccezione. Tre parti in movimento, una frase.

Alcuni contratti affermano anche che il trasferimento è efficace a livello mondiale e per l'intero termine di protezione, comprese le proroghe e le estensioni dove consentito. Quel tipo di linguaggio è comune perché il software può vivere per anni, e nessuno vuole rinegoziare la proprietà quando l'app è già in produzione. Una cessione in una sola riga può essere troppo sottile se la legge nella giurisdizione pertinente si aspetta maggiori dettagli.

Per uno sguardo correlato ai termini e alle regole della piattaforma, il regole del sito 24freelance.pro. freelance è un utile background. Non scriverà la clausola per te, ma ti ricorda che le regole formali e il linguaggio contrattuale non dovrebbero essere in conflitto.

4. Separare strumenti, modelli e componenti riutilizzabili preesistenti

I liberi professionisti portano spesso i propri collaboratori al lavoro. Un modello, una libreria di utilità personalizzata, un wrapper API privato o uno script di build potrebbero già esistere prima dell'inizio del progetto. Il contratto dovrebbe proteggere quel lavoro preesistente pur dando al cliente diritti sul prodotto finale. Senza quella distinzione, il cliente potrebbe credere di aver acquistato l'intero toolbox.

Il metodo più chiaro è nominare i materiali esclusi in un allegato o in un programma. Chiamalo Programma A, Programma B o Allegato 1. Elenca ogni strumento preesistente, modello o componente riutilizzabile che il libero professionista non assegna. Se al cliente è consentito utilizzare uno di quegli elementi all'interno del prodotto finale, specifica se tale utilizzo è sotto licenza e se la licenza è esclusiva o non esclusiva. Piccole etichette prevengono grandi conflitti.

Esempio: un libero professionista costruisce un flusso di pagamento utilizzando una libreria di validazione privata creata due anni prima. Il contratto può affermare che la libreria rimane di proprietà del libero professionista, mentre il cliente riceve una licenza perpetua per utilizzare la libreria solo come incorporata nell'app consegnata. Questo protegge il lavoro precedente del libero professionista e lascia comunque al cliente un prodotto utilizzabile. La linea tra 'proprietà' e 'licenza' deve essere visibile.

Questa è un'area in cui il linguaggio degli allegati supera le promesse vaghe. Se il libero professionista dice: 'Ho del codice riutilizzabile', non è sufficiente. Metti i nomi in un programma. Metti le eccezioni per iscritto. Metti il numero del programma nel corpo principale in modo che nessuno dimentichi di aprirlo dopo.

5. Imposta i requisiti di consegna, accesso al repository e passaggio di consegne

Le clausole di proprietà non sono sufficienti se il cliente non può effettivamente ottenere i file. Il contratto dovrebbe coprire l'accesso a Git, la cronologia dei commit, il passaggio dei rami, il trasferimento delle credenziali, la documentazione e una dichiarazione che tutti i file sorgente finali sono consegnati all'accettazione. Una clausola legale ben formulata è utile; una password mancante del repository non lo è.

Specifica cosa significa consegna. Il freelancer carica il codice finale nel repository di proprietà del cliente? Il freelancer fornisce un archivio zip dell'intero progetto? Il passaggio di consegne include note sullo schema del database, variabili d'ambiente e passaggi di distribuzione? Se il progetto dipende da un account di servizio privato, il contratto dovrebbe indicare quando quelle credenziali passano al cliente o vengono ruotate. Un token mancante può ritardare il lancio.

Mantieni i termini del repository concreti. Ad esempio: “Il freelancer concederà al cliente accesso amministrativo al repository del progetto entro la data di consegna, preservando la cronologia dei commit a meno che il cliente non richieda un passaggio di consegne pulito, e trasferirà il controllo di tutti i rami utilizzati per il lavoro di produzione.” Quella formulazione copre accesso, cronologia e proprietà dei rami in un unico posto. Se il cliente desidera un ramo di staging separato, nominarlo anche.

Buoni termini di passaggio riducono anche la disputa "Ho inviato tutto". Se l'accettazione dipende dalla consegna dei file sorgente finali, specifica quali file sono. Se la documentazione finale include note di configurazione, elencale. Se il progetto include il deployment nel cloud, anche le credenziali per quell'ambiente potrebbero necessitare di un passaggio di consegna separato, ed è qui che tecnologia del cloud computing può plasmare il lato pratico della consegna.

6. Includere regole sulla riservatezza, sul codice open-source e sul codice di terze parti

La proprietà del codice sorgente può diventare complicata rapidamente quando il codice esterno entra nel progetto. Il contratto dovrebbe limitare le librerie non divulgate, richiedere l'approvazione per l'uso di codice open-source e richiedere la divulgazione di componenti o dipendenze di terze parti che potrebbero influenzare la proprietà. Se il freelancer inserisce un pacchetto sotto una licenza che limita l'uso commerciale, il cliente dovrebbe saperlo prima del rilascio, non dopo che arriva un ticket di supporto.

Stabilisci una regola per il materiale open-source. Ad esempio, il freelancer può utilizzare codice open-source solo se il cliente lo approva per iscritto e solo se i termini di licenza non confliggono con le aspettative di proprietà del cliente. Ciò significa che il freelancer deve identificare qualsiasi componente GPL, LGPL, MIT, Apache o simile utilizzato nel progetto e spiegare l'effetto pratico. I nomi sono importanti.

Il codice di terze parti merita la stessa onestà. Un SDK a pagamento, uno script di un datore di lavoro precedente o un frammento copiato da un repository pubblico possono complicare la proprietà. Il contratto dovrebbe richiedere la divulgazione di qualsiasi componente del genere prima che venga incluso. Se è necessaria l'approvazione, rendi il processo di approvazione un passaggio, non un messaggio di chat. Una nota in Slack è facile da perdere.

La riservatezza dovrebbe coprire anche i contenuti del repository, le credenziali, le note architettoniche e la logica aziendale. Non si tratta solo di una questione legale. Un concorrente che vede il processo di build o il flusso di distribuzione potrebbe ottenere più di quanto il cliente intendesse condividere. Se il progetto coinvolge casi studio pubblici o utilizzo del portfolio, il contratto dovrebbe specificare se il freelancer può mostrare screenshot dopo il lancio.

7. Definire i tempi di accettazione, pagamento e trasferimento di proprietà

Il trasferimento di proprietà spesso dipende dal pagamento. È normale. Il contratto dovrebbe indicare se l'approvazione delle milestone o il pagamento finale attivano il trasferimento di proprietà, e dovrebbe specificare cosa succede se il progetto termina anticipatamente. Se il trasferimento avviene all'accettazione, definisci chiaramente l'accettazione. Se avviene quando la fattura finale è pagata, scrivi quella condizione in inglese semplice.

Non lasciare il tempismo alla memoria. Una clausola può affermare che i deliverables sono considerati accettati dopo l'approvazione scritta o dopo un periodo di revisione stabilito se non arriva alcun avviso di rifiuto. Poi collega il trasferimento della proprietà a quell'evento di accettazione, o alla ricezione del pagamento dopo l'accettazione. Un evento, una conseguenza. Questa struttura impedisce a tutti di discutere sull'ordine delle operazioni.

La risoluzione anticipata ha bisogno di una propria regola. Supponiamo che il cliente annulli dopo il traguardo 2. Il cliente possiede già il codice per cui è stato pagato? Il freelancer mantiene i diritti sui moduli non completati? Il cliente riceve una licenza per utilizzare il lavoro parziale, o solo una copia per revisione interna? Il contratto dovrebbe rispondere a tutte e tre le domande prima che qualcuno inizi a programmare.

Per progetti ad alto rischio, alcuni team separano il pagamento dalla proprietà. Il freelancer può ricevere un pagamento parziale a ciascun traguardo, mentre la proprietà del codice completato si trasferisce solo dopo la chiusura dell'ultimo traguardo. Questo può funzionare, ma solo se il contratto spiega se il codice parzialmente pagato è concesso in licenza per uso interno durante il progetto. Se la risposta è no, dì di no.

8. Aggiungi una checklist pronta per la firma prima di inviare il contratto

Prima di inviare il contratto, esegui una checklist. Usa nomi, percorsi e date. Nome del progetto, posizione del repository, clausola di proprietà, materiali esclusi, obblighi di consegna e qualsiasi revisione legale necessaria per un linguaggio specifico della giurisdizione dovrebbero essere tutti presenti. Se uno di quegli elementi è mancante, sistemalo prima. Una firma affrettata è comunque un rischio.

Ecco un elenco pratico da controllare prima dell'invio:

• Il nome del progetto corrisponde alla dichiarazione di lavoro.
• La posizione del repository è identificata da URL o percorso esatto.
• La clausola di proprietà indica quando avviene il trasferimento.
• I materiali esclusi sono elencati in un programma.
• Le obbligazioni di consegna menzionano i file sorgente, i documenti e l'accesso.
• Le regole per il codice open-source e di terze parti sono scritte.
• I tempi di accettazione e pagamento sono collegati.
• Il linguaggio specifico per la giurisdizione ha una revisione legale.

Se il contratto è per un team che valuta anche la reputazione pubblica, è utile rivedere recensioni dei freelancer prima di assegnare ulteriore lavoro. Un contratto può proteggere la proprietà del codice, ma non risolve cattive abitudini di passaggio o scadenze ripetutamente mancate. Due misure di sicurezza sono meglio di una.

Una nota pratica finale: se il progetto è legato a un flusso di lavoro di una piattaforma di nicchia, il contratto non dovrebbe entrare in conflitto con le regole operative del sito, la sequenza di pagamento o il percorso di approvazione. Ecco perché molti clienti mantengono un breve elenco di controllo interno accanto alla bozza del contratto. Sembra semplice. Semplice è buono.