Le client veut du code source, mais il contient beaucoup de code partagé que je réutilise avec d'autres projets
J'ai un client qui voudrait que je livre le code source avec un binaire d'application développé. À l'origine, ils n'ont rien dit sur le code source, mais ils ont récemment dit qu'ils en avaient besoin. Le contrat n'est pas finalisé. Ils ont accepté le travail, n'ont pas signé, puis sont revenus avec cette clause.
Le problème est le suivant: j'ai une base de code que j'ai créée au fil des ans et utilisée comme modèle pour la plupart des applications que j'écris. Elle est bien plus grande que la portée du projet.
J'ai également l'intention de l'utiliser pour un produit, donc je ne souhaite vraiment pas le fournir pour un projet relativement petit.
Je suppose que ce n'est pas la première fois que cela se produit dans cette industrie. Quelle est la meilleure façon de contourner ce problème? Je suppose que des choses comme les bibliothèques partagées pourraient aider.
La première chose à garder à l'esprit est que le code source a une valeur distincte des binaires. Il est parfaitement raisonnable de refuser de signer un contrat qui nécessite la livraison du code source, ou d'insister sur des paiements supplémentaires pour la livraison du code source. Les contrats sont des documents à double sens. Ne laissez pas l'autre partie dicter ce qui est requis simplement parce que ce sont des "grandes entreprises" et "faites cela tout le temps". Tout d'abord, décidez ce que vous êtes prêt à livrer et comment vous voulez être indemnisé. Apportez ensuite leur contrat à un avocat et déterminez ce qui doit changer. Ensuite, vous négociez.
Ne faites pas ce que font beaucoup de jeunes lorsqu'ils commencent à contracter. Ne vous contentez pas de signer, car il semble qu'ils ont beaucoup d'expérience et vous ne l'avez pas. C'est un bon moyen de se faire arnaquer.
Regardez pourquoi ils veulent la source. Ils peuvent le vouloir afin qu'ils aient la possibilité d'utiliser un autre développeur plus tard. Ou ils peuvent le vouloir simplement parce qu'ils ont peur que vous vous fassiez frapper par un bus et soudainement ils se retrouveront avec des binaires qu'ils ne peuvent pas améliorer. Si c'est ce deuxième cas, regardez dans un Software Escrow Service . Ces services détiennent le code source au cas où vous feriez faillite ou autrement ne pourriez pas maintenir le logiciel. Cela peut satisfaire à la fois votre désir de garder votre code propriétaire au service d'autres clients et leur désir de ne pas laisser le sac avec un ensemble de fichiers binaires non maintenables en cas de problème.
"Non" est une réponse parfaitement fine, en fait c'est une réponse incroyablement utile qui, pour une raison que je ne comprends pas, est très sous-estimée.
"Salut, nous avons soudainement décidé que nous voulions juste du code source aussi, gratuitement."
"Salut, non."
Ce n'est pas si difficile, vraiment.
Ensuite, s'ils souhaitent payer des sommes d'argent considérables plus ce qu'ils déjà vous doivent, vous pouvez leur donner une version tronquée de votre demande, qui comprend uniquement les sources qu'ils ont réellement besoin, et en prenant soin, ils obtiennent absolument non - des droits exclusifs.
Ne compliquez pas les choses simples.
Votre question est: "quelle est la meilleure façon de contourner ce problème?" Mais quel est selon vous le problème? D'autres ont souligné à juste titre que c'est une question de négociation: tout a une valeur, et c'est à vous de donner au client un prix pour ce qui est demandé.
Mais vous devez également considérer attentivement - et écrire dans le contrat - les implications de la fourniture du code. Est-ce juste pour que le client puisse le voir? Le client peut-il le modifier? Et en particulier, envisageriez-vous de donner à votre client des droits exclusifs sur la base de code que vous avez créé au fil des ans et utilisé comme modèle pour la plupart des applications afin que vous ne puissiez plus jamais l'utiliser vous-même à l'avenir ?
Vous devez vous assurer que le contrat indique explicitement qui a le droit d'utiliser le code et de quelles manières.
N'oubliez pas que tout code source nécessite une licence. Si vous remettez le code source, l'entreprise peut utiliser le code source pour faire tout ce que la licence permet, et tout ce qui va au-delà est une violation du droit d'auteur. Donc, si vous remettez le code source, vous auriez un contrat qui stipule clairement que vous conservez le droit d'auteur exclusif du code source, et exactement quelles utilisations du code source sont autorisées. Et bien sûr, le code source + licence ne serait pas gratuit.
Il est peu probable qu'une grande entreprise enfreigne votre droit d'auteur, car être pris causerait un préjudice majeur à sa réputation, en dehors des dommages financiers. D'un autre côté, payer pour un logiciel sans garantie que des problèmes puissent être résolus à l'avenir pourrait être inacceptable pour le client.
Auparavant, je fournissais généralement le code source (bibliothèques et tous) sous une licence MIT au client. Si vos bibliothèques sont bien organisées, vous ne fournissez que les fichiers/ressources nécessaires pour ce client particulier, mais rien de plus . Je pense que c'est juste pour moi et pour le client. Cependant, il y a toujours eu un problème de nouveau code écrit pour ce client particulier sous contrat qui ne faisait pas partie de la bibliothèque auparavant. J'ai donc commencé à discuter du problème avec le client avant de commencer. Certains clients voulaient s'approprier ce code, d'autres pas (j'ai toujours donné des incitations négatives, comme des prix plus élevés pour ceux qui le faisaient). Mais, vraiment pour certains clients, cette discussion était très déroutante et parfois je finissais par parler pour 3 ou 5 personnes différentes (y compris leur avocat) juste pour faire approuver le projet.
Alors maintenant, toutes mes bibliothèques font partie d'un framework personnalisé que j'utilise toujours pour développer et j'explique au client que j'utiliserai ce framework mais que le framework est un produit différent avec une licence différente. (Parfois j'utilise des "composants logiciels" pour expliquer parce que le "framework" peut leur être inconnu). Je fournis toujours le code des fichiers utilisés sous une licence MIT et (parce que tout le code est bien organisé) le code de bas niveau (même le nouveau) reste dans le framework (pour être réutilisé par moi et par eux) mais le code relatif à leur application est uniquement pour eux de garder sous leurs propres conditions (ce code serait très probablement inutile pour moi de réutiliser dans un autre projet). Bien sûr, tout cela est correctement écrit dans le contrat. Je pense que c'est juste aussi.
La clé est: "ces composants sont un produit différent" et tout est écrit dans un contrat avant de commencer.
Alors oui, votre idée d'utiliser des bibliothèques partagées peut être juste. Cependant, je vous demande, pourquoi ne leur fournissez-vous pas le code source que vous avez utilisé, sous une licence qui leur permettra de réduire leurs risques? Je pense que ce serait juste.
La façon de traiter cela est de négocier.
S'ils veulent du code source, alors ils devraient être prêts à payer pour cela, et c'est à vous de décider combien cela devrait être.
D'un autre côté ... s'ils ne sont pas prêts à payer ce que vous voulez, ils peuvent décider de "prendre leurs affaires ailleurs".
Bienvenue dans le monde des affaires :-)
Et lorsque vous parlez à des clients potentiels à l'avenir, assurez-vous de mentionner ce problème dès le début ... pour éviter de perdre du temps à tout le monde.
Il convient également de noter que ce que vous faites est un anathème pour les développeurs open source et pour les clients (éduqués) qui recherchent des solutions open source.
Cela peut être trop tard pour vous, dans la mesure où vous avez peut-être déjà convenu contractuellement de le faire, et vous auriez pu accepter des conditions mutuellement incompatibles avec différents clients.
Il existe deux façons de fournir à vos clients votre code source. Propriété du droit d'auteur et sous licence.
Certains clients voudront posséder le code source. Cela signifie qu'à la fin du processus, ils vous paieront de l'argent et vous leur donnerez en échange le droit d'auteur sur le code que vous créez pour eux. Cela s'explique notamment par le fait qu'ils voient un potentiel important de propriété intellectuelle dans le code source et peuvent vouloir le valoriser dans le bilan de leur entreprise. Dans ce scénario, vous n'aurez pas le droit de continuer à utiliser ce code source pour d'autres projets, sauf si vous obtenez également une licence de votre client vous accordant ce droit.
Si votre client achète vous-même un produit "sur étagère", il s'attend à recevoir une licence pour utiliser le logiciel, et non la propriété du code source. Ils devraient s'attendre à ce que vous vendiez le même logiciel (ou similaire) à de nombreuses autres organisations, et qu'ils bénéficient, espérons-le, d'un coût d'achat inférieur en raison de la clientèle plus large.
Cependant, la situation dans cette question est un méli-mélo des deux.
Voici ce que je voudrais pouvoir faire. J'accorderais à votre client une licence pour utiliser (et modifier) votre code partagé. Si le client m'interroge, je voudrais souligner qu'il s'agit d'un code partagé que vous avez déjà utilisé dans plusieurs projets et que des offres en cours pour des travaux futurs sont basées sur le fait que vous continuez à utiliser ce travail. Faites remarquer que cela a permis de réduire le temps consacré à ce projet pour votre client et qu'il a par conséquent payé un prix inférieur. Comme d'autres bibliothèques de code partagées utilisées par le projet, ils ont une licence en place pour utiliser ce code, et pour permettre à d'autres équipes de développement de le développer, et à d'autres projets basés sur cette bibliothèque. Cependant, s'ils préfèrent être propriétaires de tout le code, vous êtes prêt à créer un remplacement, mais ce serait un supplément.
Selon ce à quoi vous vous êtes déjà engagé, vous pourriez avoir à écrire une fonctionnalité de remplacement gratuitement ou à donner votre code source.
N'oubliez pas qu'il existe différents types de bibliothèques. La bibliothèque de modèles standard en C++ est un bon exemple de bibliothèque incluse au niveau du code source et compilée dans un exécutable de projet qui peut être assez similaire à la façon dont vous avez utilisé votre code commun.
Si vous utilisez un tiers avec le logiciel que vous livrez, il est probable que vous ne disposiez pas du code source de ce tiers. Vous livrerez toujours le logiciel à l'entreprise avec les fichiers binaires du tiers. Le code que vous avez développé en tant que framework partagé dans tous vos projets est exactement comme un tiers même s'il vous appartient. Dans ce cas, l'entreprise a exactement le même risque avec les binaires de votre framework qu'avec le tiers. Pourquoi dans ce cas donneriez-vous à l'entreprise le code source de votre framework? Vous pouvez lui fournir une bonne documentation API avec un contrat de licence et ça. Si votre code contient la prochaine grande chose qui va révolutionner l'industrie, c'est une autre histoire mais ce n'est généralement pas le cas.