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.