On construit un système de support avec un dev freelance sur du code open source — qui détient les droits ?

Faites particulièrement attention à la question AGPL. S'il écrit le code directement dans le noyau AGPL, ce code peut aussi tomber sous le coup de l'AGPL. Si vous faites concevoir les modules supplémentaires comme un service séparé qui ne communique avec le noyau que via une API indépendante, vous serez bien plus tranquille dans les débats de propriété.

Sur un projet similaire, on a fait installer un système de support pour 6 000 dollars il y a deux ans. Comme on n'avait pas écrit clairement la propriété du code dans le contrat, le dev nous a demandé 2 000 dollars de frais supplémentaires pour une simple mise à jour d'API. Si vous ne récupérez pas la cession de droits dès le départ, ce système vous coûtera plus cher en quelques années que des logiciels prêts à l'emploi.

Ouvrez tout de suite un dépôt Git privé au nom de votre société et ne donnez au dev qu'un droit d'écriture. Que le code afflue tous les jours sur votre serveur. N'acceptez surtout pas que le dev dise « je garde sur mon ordi, je pousserai tout en bloc à la fin ».

Le dev code-t-il un nouveau panneau de zéro, ou intègre-t-il des bibliothèques prêtes qu'il a déjà développées pour d'autres clients ? S'il utilise ses propres outils communs écrits auparavant c'est normal qu'il les licencie ; mais le copyright des parties écrites de zéro avec les 7 500 dollars que vous payez doit absolument vous appartenir.

Selon la doctrine du « Work Made for Hire » en vigueur dans le système juridique américain, la propriété intellectuelle produite par des contractants indépendants ne passe pas automatiquement à l'employeur sans un contrat de cession écrit explicite. Insérer une clause de cession explicite de propriété dans votre contrat est une obligation légale pour éviter la perte de droits.

laissez pas le copyright du code perso que vous payez au gars. bon demain ou après-demain il prend le même module et le vend à votre concurrent et vous vous retrouvez obligé de repasser par le même gars chaque fois pour faire ajouter une ligne de code au système.

La règle d'or quand on bosse avec des devs : le jour où le boulot se termine, même si ce dev disparaît complètement, vous devez récupérer la doc et les accès pour qu'un autre ingénieur puisse reprendre le système en 24h. Ne signez pas un contrat qui ne donne pas cette garantie.

edit : j'ai corrigé quelques fautes de frappe.

Merci de partager le résultat.

Il y a un piège ici, je ne pouvais pas ne pas le mentionner. Quand on essaie de tout changer en même temps, rien ne prend.

Si vous écrivez le résultat ici cela aidera aussi d'autres personnes.

Merci, c'était exactement la réponse que je cherchais. Quand on décide sans mesurer, on revient toujours au même point.

Je le note au cas où.

Trois avis différents sont sortis, ils se complètent tous. L'erreur commise du côté de propriété du code open source est généralement réversible, mais coûteuse.

Cherchez-vous un associé ou un cofondateur ? Ce sont deux choses différentes. Voilà, désolé si je me suis étendu.

Je suis d'accord en partie, pas en partie. Un partenariat ne se décide pas sans avoir travaillé ensemble.

Voilà, désolé si je me suis étendu.

Trois avis différents sont sortis ils se complètent tous. Avant de parler d'actions faites un petit projet de trois mois pour apprendre à vous connaître.

Bon courage.

J'y pensais aussi. La seule chose qui distingue l'amitié du partenariat, c'est le contrat écrit.

Merci beaucoup je teste dès aujourd'hui.

Chez nous aussi. Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois.

Bien sûr, cela change si votre situation est différente.

je suis d'accord.

Merci d'avoir écrit cela, c'est exactement ça. La seule chose qui distingue l'amitié du partenariat, c'est le contrat écrit.

Je le note au cas où.