Supposons que je possède un projet Open Source sans informations de licence. De plus, supposons que personne n'a contribué au public et donc je possède le code source du projet et le droit d'auteur.
Dites que le code source est déjà hébergé en ligne. Si je décide de lui donner une licence open source en téléchargeant le document de copie associé au référentiel et en ajustant les fichiers source en conséquence, les versions précédentes du projet seront-elles également sous licence? Ou les versions actuelles et futures seront-elles protégées alors que les versions précédentes relèvent de domaine public?
Alternativement, disons que je démarre un nouveau projet à l'aide d'un DVCS (par exemple mercurial) sur ma machine locale. Je commettre toutes mes modifications (localement), puis ajoutez des informations de licence dans une modification ultérieure. Si je devais héberger le projet / le référentiel, l'ensemble de l'historique sera-t-il sous licence ou uniquement les versions qui suivent cette modification?
in (2), le projet n'est initialement pas hébergé, donc cela ne semble pas être un problème. Mais une fois que cela est téléchargé, une partie de l'historique du projet n'inclut pas les informations de la licence, ce qui rendra le résultat presque exactement comme (1).
Je pose parce que Google Code vous permet de sélectionner une licence sur un nouveau projet, même si vous avez l'intention d'importer le référentiel par la suite, la création de licences semblent quelque peu externes au code source réel, alors que Bitbucket.org ne le fait pas.
5 Réponses :
Je ne suis pas un avocat mais aussi loin que je connais le code ou toute forme de contenu étant clairement sur le Web ne le rend pas vraiment public.
En ce qui concerne le calendrier de votre licence: si vous attachez une licence à votre code dans la révision 100, cela ne devrait affecter que les modifications de la révision 100 et des futures jusqu'à ce que vous modifiez à nouveau cette licence. Sinon, vous pourriez, par exemple, revenir au code d'être opensource après.
De ma compréhension La licence que vous obtenez lors de la vérification du code (avec une révision donnée) est la licence applicable à cette révision du projet. IMO Ceci est également ce qui rend les fourchettes de projets possibles qui sont passées d'une licence OSI à une ferme fermée à l'aide du code OpenSource.
Par conséquent, vous devriez probablement créer un nouveau repo avec les informations de licence en place avant de la mettre en ligne.
+1 "... Si [SIC] devrait créer un nouveau représentant avec les informations de licence en place avant de la mettre en ligne."
Je suis d'accord avec vous, puisque le forking / clonage sur une révision portera sur la licence et les futures versions sous une licence différente ne doivent pas affecter cela. Et je suis d'accord avec "... avant de la mettre en ligne." Mais lorsque vous possédez un projet localement et que vous souhaitez le publier (y compris son histoire, E.G. Mercurial + Bitbucket) avec une licence, il devrait y avoir un moyen simple de déclarer que "tout mon travail [jusqu'à présent] relève de cette licence".
Tant que vous n'utilisez aucune bibliothèque GPL, ce que vous faites avec votre code est à vous. Vous pouvez dire que votre code est rétroactivement GPL ou vous pouvez dire quelle version est GPL et quelle version est BSD et quelle version est la licence Apache. Vous pouvez même proposer une double licence: utilisez GPL ou payez-moi 100 $ pour utiliser BSD (genre de comme ce que les gars Qt ont fait avant de décider de proposer LGPL).
Maintenant, si vous utilisez une bibliothèque sous licence GPL, votre code est déjà gpl.
Bon point sur l'utilisation de bibliothèques agréées GPL.
Je crois comprendre que si vous possédez le droit d'auteur sur la source, vous pouvez le licencer à d'autres personnes pour leur propre usage, mais vous souhaitez que vous souhaitiez, etc. Vous avez raison, GPL en tant que licence CopyLeft a la condition que Si vous utilisez une bibliothèque GPL, vous devez également utiliser GPL. Je suis plus curiouis quant à ce que la loi dit sur l'historique des rtiquements de projet, le style mercurial en particulier.
Pourquoi voulez-vous exposer l'historique source? La solution la plus facile à votre scénario consiste simplement à copier votre code et à créer un nouveau référentiel, puis publiez ce nouveau référentiel quelque part avec une licence open source. Tirez la source qui sort actuellement en ligne sans permis et vous êtes doré. L'ancienne source et la nouvelle source sont complètement séparées et il ne devrait y avoir aucun problème. Si quelqu'un a une copie de l'ancienne source, vous ne pouvez probablement rien faire pour les empêcher de faire ce qu'ils veulent avec elle, mais vous avez une ardoise propre pour tout ce qui va de l'avant. Tout ce qui est tiré de votre nouveau repo (celui avec la licence) sera couvert par cette licence.
Je suppose que vous êtes l'auteur de la source actuellement hébergée en ligne. Si vous n'êtes pas, vous avez d'autres problèmes à soutiendrer avec, à savoir si vous avez le droit de spécifier une licence pour le code source de quelqu'un d'autre - probablement pas.
Le problème est qu'il est fastidieux de recréer un référentiel complet pour simplement ajouter un fichier (le document de copie) à la "première révision". Vous devrez revenir à chaque révision, copier sur le nouveau référentiel, mettre dans votre nouveau fichier et vous engager avec les mêmes messages / balises / branches / etc. pour le faire. Il y a probablement des outils pour quelque chose comme ça. Mais dans des cas comme un référentiel local non encore publié et que vous possédez le code, il serait plus agréable de déclarer une licence sur cet état de référentiel complet. La question est hypothétique et le code est à moi, dans un référentiel mercurial local.
Si vous utilisez un code LGPL (ou Apache ou Berkeley-licencié), vous pouvez mieux utiliser le code GPL, ce qui nécessite que tous les codes écrites sur la base de ce code doivent être publiés comme source ouverte. Voir http://www.google.com/help/faq_codeesearch.html#license, mais vous pouvez obtenir de meilleures informations concernant le code de Google à partir de cette source.
Salut, merci pour la réponse. Cependant, dans cette question, je suis plus curieux de publier un projet déclarant que cela et que chaque révision de son code source a une certaine licence, pas tellement que la licence que je devrais utiliser.
Si vous souhaitez que la licence s'applique à l'ensemble de l'historique, dites simplement que dans le fichier de licence, quelque chose comme «Ce fichier a été ajouté à la révision X, mais vous pouvez considérer que la licence s'applique à toutes les révisions avant X. '.
Vous pouvez le considérer comme la licence déclarant ce qu'elle couvre ... Legalbol est un code, la portée peut être explicite si vous le souhaitez.
Ça a du sens. Mais cela soulève une autre question: Que se passe-t-il lorsqu'une révision antérieure qui n'inclut pas ce dossier est fourchue / clonée, cette fourche relève-t-elle toujours sous la portée de la licence? Peut-être en exigeant que le développeur copie la licence de la révision ultérieure.
Je pense que vous devrez demander à un avocat cette question. Compte tenu de ce que je sais sur la loi sur le droit d'auteur, je m'attendrais à ce que cela relèverait de cette portée, mais vous ne savez jamais avec des problèmes juridiques.
Je vote pour fermer cette question comme étant hors sujet, car il s'agit de la licence et des problèmes juridiques, non pas de programmation ou de développement de logiciels. voir ici pour plus de détails, et le Centre d'aide pour plus.
@Pang Oh. D'accord. Eh bien, c'est aussi une question impliquant le contrôle de la source, qui n'est pas aussi générale que la "licence".