J'étais un avocat spécialisé en propriété intellectuelle, j'ai donc de l'expérience avec des licences. J'ai l'impression que les termes eux-mêmes sont assez lisibles et compréhensibles, mais là encore, je suis gâché par trois ans d'école de droit et un peu de temps d'avocat avant de retrouver mes esprits et de revenir au piratage. D'autant plus que je ne suis pas actuellement un avocat actif, ce n'est certainement pas du tout un conseil juridique.
Commençons par le langage de licence MIT lui-même. Ensuite, je vais exposer quelques points clés pour comprendre les licences open source, puis répondre à vos questions et fournir des observations de haut niveau.
La permission est accordée, sans frais, à toute personne obtenant une copie de ce logiciel et des fichiers de documentation associés (le "Logiciel"), de traiter le Logiciel sans restriction, y compris, sans limitation, les droits d'utilisation, de copie, de modification, de fusion , publier, distribuer, sous-licencier et / ou vendre des copies du Logiciel, et autoriser les personnes à qui le Logiciel est fourni à le faire, sous réserve des conditions suivantes: (qu'elles y laissent cet avis. La fin.)
Quelques éléments clés avec la plupart des licences open source (y compris BSD, MIT, GPL) pour les titulaires de droits d'auteur sont:
- La licence ne modifie pas votre propriété du droit d'auteur lui-même. C'est une licence non exclusive, pas une cession ou une déchéance de propriété. Utiliser une licence de système d'exploitation n'est pas «mettre quelque chose dans le domaine public», bien que ce soit certainement une approche de l'open source.
- Rien ne vous "oblige", en tant que propriétaire des droits d'auteur, à rendre le code public de quelque manière que ce soit simplement parce que vous y attachez une licence.
- Mais si vous utilisez une licence OS, vous ne pouvez pas empêcher quiconque "obtient" votre code sous licence OS de le rendre public de quelque manière que ce soit, ce qui est explicitement dans leurs droits sous toutes ces licences.
- Les licences Copyleft (par exemple, GPL) obligent les acquéreurs (mais pas les propriétaires) à rendre leurs œuvres dérivées publiques et open source. Permissif (MIT, BSD) ne le font pas. (cela peut être un peu simplifié, mais c'est la différence essentielle)
- Il n'y a pas de clause de «reprise» pour la plupart des licences open source (par exemple, le MIT), donc une fois que quelqu'un a «obtenu» votre code, il a le droit de l'utiliser à perpétuité, selon les conditions de licence sous lesquelles il l'a reçu.
- Vous pouvez toujours distribuer les futures versions de votre code sous une licence différente, ou les garder entièrement propriétaires. Cela n'empêche pas quelqu'un de commencer avec votre version précédente open-source (en supposant qu'il l'ait "obtenue") et d'ajouter ses propres nouvelles parties et de la distribuer.
- Vous pouvez supprimer un canal "d'obtention" pour les versions précédentes de votre code, par exemple, le retirer de github. Cependant, comme mentionné, cela n'empêche pas les autres d'utiliser ou de distribuer les versions précédentes que vous aviez ouvertes, en aucune façon.
Sur cette base, je vais passer à vos questions.
Je ne distribue mon code à personne. Je n'ai pas à distribuer mon code sous licence MIT à quiconque, si je possède le droit d'auteur, n'est-ce pas? Je veux dire, quelqu'un peut-il demander que je libère mon code que je prétends maintenant qu'il est sous licence MIT? Ce ne serait pas la fin du monde et je serais certainement d'accord pour le faire sous une menace juridique. ... En même temps, je ne veux pas distribuer ce code en tant que projet open source à personne.
En tant que détenteur des droits d'auteur, vous n'avez à distribuer aucun code à personne; vous n'auriez pas à honorer de telles demandes (même s'il s'agissait de GPL). Vous conservez tous les droits. Cependant, dans la situation que vous décrivez, vous distribueriez à votre nouvelle entreprise et lui octroyeriez une licence perpétuelle sous une licence OS. Votre employeur (plus probablement un ancien employeur) pourrait coller votre code sur Internet, et vous ne pourriez rien y faire à part vous plaindre.
Je suppose que vous voulez dire "toute personne en dehors de mon employeur". Si vous ne voulez pas le donner à votre employeur "en open source" et lui donner tous les droits qui sont inclus dans cette licence, y compris la redistribution et l'utilisation perpétuelle de la manière qu'il souhaite, alors vous ne devriez pas utiliser un licence open source. Vous devez simplement lui octroyer une licence directement dans les conditions que vous souhaitez. Bullet souligne ce que vous voulez et demandez à un avocat de vous facturer une heure ou deux pour les mettre sous forme de paragraphe. Ou écrivez-le vous-même. Les licences ne sont que des contrats qui ne sont que des accords mis en mots.
Mon objectif final est de pouvoir utiliser une version dérivée de mon ancien framework codé sans en perdre le copyright.
Vous ne pouvez pas perdre le droit d'auteur à moins de le céder à quelqu'un, de le concéder sous licence exclusivement (y compris vous-même) ou de le perdre. La licence open source n'en fait pas partie. Vous serez toujours en mesure d'utiliser les versions dérivées que vous créez et pourrez même concéder sous licence les dérivations différemment ou conserver tous les droits.
Mais, une de vos préoccupations principales et légitimes semble être que vous puissiez continuer à conserver le droit d'auteur et utiliser votre code à l'avenir sans que l'employeur ne revendique le code comme le leur ou que vous n'ayez pas le droit de le faire. La clé pour cela est de créer une preuve irréfutable que A) vous conservez le droit d'auteur sur votre travail précédent et que vous le fournissez sous des conditions de licence X (MIT fonctionne, si vous êtes d'accord avec l'aspect open source décrit ci-dessus. ) B) ils acceptent ces conditions, et C) quel était exactement le travail précédent.
Pour (A) et (B), vous pouvez les amener à signer ou à accepter par écrit quelque chose qui fait référence ou inclut la licence et qu'ils comprennent que vous apportez le code à la table selon ces termes. En ce qui concerne (C), je ne sais pas quelle serait la manière standard de procéder, mais soyez logique. Si ce n'est pas terriblement massif, vous pouvez simplement imprimer le code et l'inclure dans l'addendum en copie de l'accord que vous et votre employeur signez. Conservez votre copie, avec leur signature dessus. S'il est trop gros pour être imprimé pratiquement, il semble qu'un hachage md5 serait utile ici. Peut-être que vous pourriez vous y référer comme quelque chose comme "le fichier zip nommé X dans le référentiel github privé /, (ou site ftp, etc.), qui a un hachage md5 de XXXXXX ... et a été envoyé par courrier électronique à la société Y reprentative sur Z Date". Ensuite, vous pouvez l'envoyer par e-mail à votre responsable ou à son avocat ou à quiconque de votre compte de messagerie personnel et même s'ils suppriment leur copie, vous conservez toujours le vôtre et ils ne peuvent pas prétendre que vous avez prédit le futur hachage md5 de code qui n'est pas encore écrit . Cela les empêcherait théoriquement de revendiquer quoi que ce soit d'autre sur la route.
(Je ne suis pas avocat.)
Je vois quelques problèmes potentiels avec cela:
Si le pire arrive au pire, vous devrez prouver que vous avez écrit ce code avant de commencer à travailler là-bas et que lorsque vous l'avez utilisé dans votre projet au travail, votre employeur était conscient qu'il était sous vos droits d'auteur et sous la licence MIT . Comme l'objectif principal de cela est de conserver vos droits d'auteur, et non de fixer des conditions de redistribution, un contrat écrit avec votre employeur concernant l'utilisation de votre code précédemment écrit semble une meilleure idée.
Vous dites que vous voulez protéger vos droits d'auteur et la possibilité d'en créer "même une autre version dérivée". Maintenant, il est probable que pendant votre travail actuel, vous aurez quelques bonnes idées et les mettrez en œuvre. Il me semble que cela deviendrait poilu lorsque vous quittez votre travail, puis `` réimplémentez '' ces idées pour construire une autre version de votre bibliothèque - puisque vous ne pouvez pas faire ce que vous voulez avec le code que vous avez écrit lors de votre travail (et dans une certaine mesure, les idées sous-jacentes).
la source
Je ne suis pas avocat, mais ce serait ma solution:
Libérez le code sous la licence GNU GPL v3 dans un référentiel public, où tout le monde peut le voir.
La licence GPL ne permet pas à d'autres personnes de prendre votre code et de le mettre dans leur logiciel commercial propriétaire et de fermer le code.
Si le code a été créé à 100% par vous et ne contient pas de travail provenant d'autres personnes ou de travail dérivé, la GPL vous permet également de concéder sous licence votre code sous une autre licence, auquel cas vous êtes autorisé à l'utiliser dans vos travaux à des fins commerciales exclusives. code. Cependant, vous devez faire de votre employeur un licencié de cette licence propriétaire alternative.
Cette solution prouverait que vous avez écrit votre code AVANT de commencer le travail.
Vous pouvez annoncer que votre code est disponible sous une licence propriétaire à vendre (pour de l'argent), puis les parties intéressées peuvent vous contacter pour l'acheter.
la source
Y a-t-il une raison spécifique pour laquelle vous ne pouvez pas demander à votre employeur s'il est possible que vous conserviez le droit d'auteur sur le code général que vous écrivez pour votre framework (qui lui donne à son tour du code gratuit en ce moment), et que vous lui donniez une solution à tout faire -vous-voulez-avec-ça (d'accord, c'est un peu comme le MIT).
Cependant, si vous accordez une licence à votre code MIT actuel, il n'y a aucune raison pour que votre employeur ouvre sa version modifiée (modifiée par vous), donc je dirais que cela ne résout pas grand-chose. Même LGPL ne résoudrait pas cela, tant que le code n'est pas «distribué».
Dans l'ensemble, votre accord ne semble pas déraisonnable: vous avez du code cadre et vous êtes prêt à les donner à l'entreprise, tant que vous pouvez conserver le code et le réutiliser pour d'autres projets plus tard, alors pourquoi ne pas demander?
la source
IANAL, demandez à un vrai avocat, etc.
Tout d'abord, je pense que vous pensez que lorsque vous avez des droits d'auteur, vous ne pouvez vous concéder une licence sur le produit que dans les mêmes conditions que vous le concédez à tout le monde. C'est faux: vous pouvez vous le concéder sous n'importe quelle licence appropriée, et le concéder à quelqu'un d'autre sous une licence différente.
Cela signifie que vous pouvez créer une licence spéciale pour l'entreprise qui est sur le point de vous embaucher et mettre le logiciel à leur disposition dans le cadre d'un accord distinct. Bien sûr, cela devrait être fait par un vrai avocat.
Demandez à votre entreprise de signer la licence distincte, qui stipule explicitement que vous avez le droit d'auteur et que vous leur accordez certains droits, pas le droit d'auteur.
En ce qui concerne le problème secondaire, il existe d'autres moyens de prouver la date antérieure, en plus de l'open source du projet. Par exemple, vous pourriez héberger sur un serveur accessible au public un fichier, qui dit que vous avez bien écrit ce logiciel, à la date indiquée, contenant par exemple quelques hachages différents de la version actuelle, ou même la version cryptée du projet.
Cela signifie que si vous êtes sous une menace juridique, vous pouvez prouver la date d'utilisation antérieure au juge, mais vous ne révèle pratiquement rien sur le projet, à part que vous êtes l'auteur et la date à laquelle vous l'avez révélé. Vous devriez consulter un avocat au sujet de l'éventuelle validité d'un tel argument, mais je crois qu'il serait accepté par la plupart des tribunaux.
la source