Stiamo costruendo un sistema di supporto su codice open source con uno sviluppatore freelance — di chi sono i diritti?

Fate particolare attenzione alla questione AGPL. Se scrive i codici direttamente dentro il core AGPL, anche quei codici possono rientrare nel perimetro AGPL. Se fate progettare i moduli aggiuntivi come servizio separato e li fate comunicare con il core solo tramite un'API indipendente, sarete molto più tranquilli nelle dispute sulla proprietà.

In un progetto simile due anni fa abbiamo fatto installare un sistema di supporto per 6.000 dollari. Siccome nel contratto non avevamo scritto chiaramente la proprietà del codice, lo sviluppatore ci ha chiesto 2.000 dollari extra per un semplice aggiornamento dell'API. Se non vi fate cedere i diritti fin dall'inizio, quel sistema in qualche anno vi costerà più di un software già pronto.

Aprite subito un repository Git privato a nome della vostra azienda e date allo sviluppatore solo il permesso di scrittura. I codici devono confluire ogni giorno sul vostro server. Non permettete assolutamente che lo sviluppatore dica 'li tengo sul mio computer, te li mando tutti insieme quando il lavoro è finito'.

Lo sviluppatore sta codificando un pannello nuovo da zero, o sta integrando librerie già pronte che ha sviluppato in precedenza per altri clienti? Se usa strumenti comuni che ha scritto lui prima, è naturale che li licenzi; ma il copyright delle parti scritte da zero con i vostri 7.500 dollari pagati deve essere assolutamente vostro.

Secondo la dottrina del 'Work Made for Hire' valida nel sistema giuridico americano, la proprietà intellettuale prodotta da appaltatori indipendenti non passa automaticamente al committente senza un esplicito contratto scritto di cessione. Inserire nel contratto una clausola esplicita di cessione della proprietà è un obbligo legale per prevenire la perdita dei diritti.

nn lasciate all'uomo il copyright del codice personalizzato che pagate voi. un giorno o l'altro prende lo stesso modulo e lo vende al vostro concorrente e voi restate ogni volta obbligati a rivolgervi allo stesso tizio xké vi aggiunga una riga di codice al sistema.

La regola d'oro quando si lavora con gli sviluppatori software è questa: il giorno in cui il lavoro finisce, anche se quel programmatore sparisse del tutto, dovete ricevere la documentazione e gli accessi tali per cui un altro ingegnere possa subentrare al sistema entro 24 ore. Non firmate un contratto che non vi dia questa garanzia.

edit: ho corretto alcuni errori di battitura.

Mi farebbe piacere se scrivesse il risultato.

C'è una trappola qui, non posso non segnalarla. Se cerchi di cambiare tutto insieme, niente si stabilizza.

Se scrivete qui il risultato, sarà utile anche ad altri.

Grazie mille, era la risposta che cercavo. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

Lascio una nota, potrebbe servire.

Sono emerse tre opinioni diverse, si completano a vicenda. L'errore commesso da proprietà del codice open source è generalmente reversibile ma costoso.

Cercate un socio o un co-fondatore? Sono due cose diverse. È tutto, scusate se mi sono dilungato.

Sono d'accordo in parte, in parte no. Una partnership non è una decisione da prendere senza aver collaborato prima.

È tutto, scusate se mi sono dilungato.

Sono emerse tre opinioni diverse si completano a vicenda. comunque prima di parlare di quote fate un piccolo lavoro insieme per tre mesi così vi conoscete.

Buon lavoro.

Stavo pensando la stessa cosa. L'unica cosa che distingue un'amicizia da una partnership è un contratto scritto.

Grazie mille, proverò oggi.

Anche da noi è così. Prendere appunti per due settimane dà risultati migliori rispetto a una stima di sei mesi.

Naturalmente cambia se la vostra situazione è diversa.

sono d'accordo.

Grazie per averlo scritto, è proprio così. L'unica cosa che distingue un'amicizia da una partnership è un contratto scritto.

Lascio una nota, potrebbe servire.