Comment éviter de tomber dans l'oubli par un contributeur plus puissant?

Comme récemment rapporté ici :

Xamarin a créé Cocos2D-XNA, un framework de développement de jeux 2D / 3D, créant une bibliothèque multi-plateformes pouvant être incluse dans des projets PCL.

Cependant le fondateur du projet qui a été fourchu dit :

Le but de la licence MIT est de libérer votre utilisation équitable. Ne vous encouragez pas à prendre un logiciel, à le renommer comme le vôtre, puis "prenez-le dans une nouvelle direction" comme vous le dites.

Bien que ce ne soit pas illégal, c'est contraire à l'éthique.

Il semble que la page GitHub du nouveau projet n'indique même pas qu'il s'agit d'un fork, comme c'est le cas avec GitHub, optant pour une section Historique facilement amovible (voir ci-dessous).

Donc mes questions sont:

1. L'action de Xamarin et la façon dont l'action a-t-elle été menée étaient-elles éthiques ou non?
2. Est-il possible d'éviter une telle situation si vous êtes un développeur unique ou un petit groupe de développeurs non financé?

J'espère que cela pourrait être une question wiki ou qu'il y aura des réponses objectives fondées sur l'éthique / la philosophie du logiciel libre.

L'action de Xamarin et la façon dont l'action a-t-elle été menée étaient-elles éthiques ou non?

Eh bien, demandons à un expert - la liste de la licence MIT elle-même, fournie par la Open Source Initiative , avec la licence citée dans son intégralité:

La licence MIT (MIT)

Copyright (c)

Par la présente, une autorisation est accordée gratuitement à toute personne obtenant une copie de ce logiciel et des fichiers de documentation associés (le "Logiciel"), afin de traiter le logiciel sans restriction, y compris, sans limitation, les droits d'utilisation, de copie, de modification et de fusion. , publiez, distribuez, concédez en sous-licence et / ou vendez des copies du logiciel, et autorisez les personnes à qui le logiciel est fourni à le faire, sous réserve des conditions suivantes:

L'avis de copyright ci-dessus et cet avis de permission doivent être inclus dans toutes les copies ou parties substantielles du logiciel.

LE LOGICIEL EST FOURNI "EN L'ETAT", SANS AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS DE MANIÈRE NON LIMITÉE À LA GARANTIE DE QUALITÉ MARCHANDE, D'ADÉQUATION À UN USAGE PARTICULIER ET D'INFRACTION. EN AUCUN CAS, LES AUTEURS OU LES TITULAIRES DE COPYRIGHT NE PEUVENT ÊTRE TENUS RESPONSABLES DE TOUTE RÉCLAMATION, DE DOMMAGES OU D'AUTRE RESPONSABILITÉ, QU'IL SOIT PAR UN ACTION DE CONTRAT, DE LORT OU DE AUTRE QUE CE SOIT, OU LIÉ AU LOGICIEL OU À L'UTILISATION OU AUTRE LOGICIEL.

Si quelqu'un - personne physique ou entreprise - publie un code logiciel / source avec une licence MIT, cela signifie que toute autre personne - personne physique ou entreprise peut "utiliser le logiciel sans restriction". Tant que la notice de copyright reste intacte, ils sont capables de faire ce qu'ils veulent.

C'est l'un de ces cas où l'éthique et la légalité sont à peu près exactement les mêmes. Si une personne ou un groupe ne comprend pas le permis ou ses implications, il ne fait pas preuve de diligence raisonnable. Open Source Initiative fournit de nombreuses autres ressources utiles pour nous aider à comprendre les licences telles que la variante MIT. Regardons quelques clauses de leur définition Open Source:

1) Redistribution gratuite - La licence n’interdit à aucune partie de vendre ou de céder le logiciel en tant que composant d’une distribution globale de logiciels contenant des programmes de plusieurs sources différentes. La licence n’exige pas de redevance ni d’autres frais pour cette vente.

3) Travaux dérivés - La licence doit autoriser les modifications et les travaux dérivés, et leur permettre d'être distribués dans les mêmes conditions que la licence du logiciel d'origine.

5) Pas de discrimination à l'égard de personnes ou de groupes - La licence ne doit pas discriminer contre une personne ou un groupe de personnes.

6) Absence de discrimination à l’égard des domaines de compétence - La licence ne doit empêcher quiconque de faire usage du programme dans un domaine d’activité donné. Par exemple, cela ne doit pas empêcher le programme d'être utilisé dans une entreprise ou d'être utilisé pour la recherche génétique.

À ma lecture, cela semble tout à fait clair: publier quelque chose en tant que source ouverte, en particulier avec la licence MIT, permet à quelqu'un de prendre librement le logiciel, de le modifier, de le conditionner et de le vendre à peu près à qui il aime, tant qu'il ne le fait pas. t supprimer votre avis de droit d' auteur et de la revendiquer comme leur propre seul travail.

En tant qu'auteur, vous renoncez explicitement au droit d'être sélectif. Vous ne décidez pas qui ou quoi peut bénéficier de votre logiciel, vous ne l'utilisez pas, et vous ne décidez pas pourquoi ils l'utilisent. Vous abandonnez explicitement ce droit.

L'idée est que vous contribuez au bien commun en renonçant explicitement à tous les droits légaux dont vous disposez pour contrôler et restreindre l'utilisation et la modification de ce que vous avez créé. Si Microsoft veut créer votre projet FluffBall et le vendre à un prix de 2 000 dollars par siège en tant que WindowsSpongeCake, ils le peuvent. Ne pas laisser les gens faire ce qu’ils veulent, c’est le but de votre projet?

Est-il possible d'éviter une telle situation si vous êtes un développeur unique ou un petit groupe de développeurs non financé?

Genre de! Commencez par utiliser une licence adaptée à vos objectifs et à vos souhaits. Si vous ne voulez pas que quelqu'un l'utilise d'une manière que vous n'approuvez pas, vous ne devriez probablement pas le publier en tant que source ouverte - et franchement, vous ne devriez peut-être pas le publier du tout! Si vous ne voulez pas que quelqu'un utilise un travail dérivé (comme une fourchette) sur un projet commercial, vous devriez probablement opter pour une version copyleft de la GPL . Si vous souhaitez une licence non commerciale, vous devriez probablement demander conseil à un avocat spécialiste des droits d'auteur / de la licence, car ce n'est souvent pas considéré comme un logiciel "open source" et il n'existe pas de licence pré-écrite majeure pour soutenir cette affaire.

Le problème avec les castrats de Xamarin et de Coco n’est pas une question d’éthique ou de légalité, il s’agit d’un combat sur Internet opposant quelques personnes qui se font du bien. Nous sommes tous humains, ça arrive. Cela semble être le résultat de l'impossibilité de collaborer / coopérer, probablement en raison d'un conflit de personnalité ou de visions incompatibles sur la manière dont le projet devrait être géré.

Donc, l’autre moyen de défense est d’être ouvert à la collaboration et au changement, mais comprenez que si cela ne fonctionne pas et que les visions divergent ... eh bien, c’est la raison pour laquelle vous pouvez choisir de créer votre propre projet.

Il est très humain et compréhensible que les sentiments de propriété et de popularité rendent les projets de logiciels très, très complexes. Mais l'objectif de l'open source est d'essayer de transcender cela et de permettre au meilleur logiciel d'être disponible librement pour tous.

En bout de ligne, définissez clairement vos objectifs lorsque vous décidez d’obtenir une licence et comprenez-en les implications pour votre contrôle et votre direction futurs du projet. Si vous voulez juste faire un don au plus grand bien, l'open source est la voie à suivre. Si vous souhaitez contrôler votre projet plus étroitement et en avoir la propriété et au moins une action en justice si quelqu'un essaie de commercialiser votre projet ou de l'intégrer (en tout ou en partie), vous aurez besoin d'une licence différente et vous devrez probablement régler le problème avec un avocat.

La publication d'un projet sous licence MIT donne aux utilisateurs la permission de créer le projet. Une partie de la philosophie du logiciel libre est de donner aux utilisateurs et aux développeurs le droit d'utiliser, de modifier et de publier le logiciel d'une manière qui ne serait normalement pas autorisée. Si vous ne voulez pas que les gens fassent cela, alors n'utilisez pas la licence MIT. Vous ne pouvez pas vraiment vous plaindre lorsque des personnes utilisent du code selon les termes de la licence que vous leur avez attribuée.

Les Forks sont une chose assez normale dans la communauté du logiciel libre. Il semble que les développeurs de la fourchette aient essayé de contribuer au projet initial, mais ils n’ont pas accepté et ont donc contribué à leur propre projet. Les logiciels libres encouragent cela afin que les développeurs ne soient pas empêchés de modifier les logiciels car les propriétaires n'aiment pas leurs modifications.

En outre, en publiant quelque chose sous une licence de logiciel libre, vous bénéficiez des contributions d'autres personnes, contributions que vous n'auriez peut-être pas reçues s'il s'agissait d'une autre licence. Si vous acceptez des contributions sous licence, respectez vous-même les termes de la licence.

Une façon de garder le contrôle sur une version officielle consiste à s’appuyer sur des éléments tels que les marques. Mozilla Corporation, par exemple, a une marque déposée sur Firefox qui leur permet de dicter ce que les gens peuvent faire avec Firefox même s'il est open source (voir Iceweasel pour plus de précision).

D'autres licences telles que LGPL autorisent toujours les forks, mais gardez le code ouvert. De cette façon, vous pouvez au moins intégrer les modifications apportées à la fourche dans votre projet d'origine et bénéficier du développement sur la fourche. Le code LGPL peut utiliser n’importe quel code sous licence MIT. Par conséquent, si vous souhaitez davantage de contrôle sur le projet, vous pouvez utiliser LGPL à la place.

Je n'appellerais pas cela contraire à l'éthique. Je dirais que c'est anti-sportif. Il existe une attente non écrite que vous fassiez un effort de bonne foi pour améliorer la version originale avant de décider de modifier, et il semble que l'auteur original pense que des efforts de bonne foi n'ont pas été faits.

Cela dit, le meilleur moyen d'éviter que votre logiciel ne soit acheminé est de répondre aux demandes des clients de manière à ce que votre logiciel ait un attrait aussi large que possible. Personne ne va soutenir une fourchette s'il sait que l'original est supérieur. En dehors de cela, votre seule protection consiste à modifier les conditions de licence.

• L'action de Xamarin et la façon dont l'action a-t-elle été menée étaient-elles éthiques ou non?

Beaucoup de gens confondent la situation juridique et éthique. La licence X11 permet à quiconque "d'utiliser, de copier, de modifier, de fusionner, de publier, de distribuer, de concéder en sous-licence et / ou de vendre des copies du logiciel, et de permettre aux personnes à qui le logiciel est fourni de le faire", ce qui est tout à fait légal .

Ethiquement cependant, c'est plus compliqué. Dans les communautés open source, il est généralement préférable d'optimiser le logiciel d'origine plutôt que de créer un fork. Dans le lien que vous avez donné , Miguel de Icaza dit:

Comme vous le savez, nous avons beaucoup contribué à Cocos2D-XNA et nous ne pouvions tout simplement pas continuer à travailler ensemble.

Une fois que nous avons atteint un point où nous ne pouvions plus collaborer, j'ai décidé de mener le projet dans la direction que je souhaitais au détriment de la compatibilité en amont.

La raison pour laquelle ils "ne pouvaient pas collaborer ensemble" n'est pas claire, mais il semblerait que Xamarin ait consenti un effort raisonnable pour travailler sur le projet d'origine avant de décider de le lancer.

• Est-il possible d'éviter une telle situation si vous êtes un développeur unique ou un petit groupe de développeurs non financé?

Légalement, vous pouvez choisir d'utiliser une licence qui n'autorise pas la falsification en interdisant la redistribution du code source (pour le moment, ce ne serait pas un "logiciel libre"). Une autre option consiste à laisser le code non encombré mais à ne pas autoriser la redistribution des actifs statiques tels que des images ou du texte sans code (certains jeux possèdent des licences de ce type).

Sur le plan social, vous pouvez empêcher de fourrer en:

• Faciliter la tâche des personnes pour apporter des modifications à votre projet.
• Passer en revue les correctifs rapidement.
• Permettre des changements qui ne vous profitent pas directement.
• Être poli. Un nombre surprenant de forks est dû au fait que les contributeurs ne sont plus disposés à travailler ensemble.

Le logiciel Forking demande beaucoup de travail, et la plupart des gens sensés ne le feront pas s'ils ont une option plus facile. S'ils n'ont pas d'autre choix, les empêcher de saisir votre code les forcera simplement à utiliser le code de quelqu'un d'autre ou à réécrire votre logiciel à partir de zéro. Cela peut les ralentir, mais cela ne vous aidera pas vraiment beaucoup.

En outre, l'utilisation d'une licence plus restrictive rendra certaines personnes moins susceptibles de contribuer. Xamarin a apparemment "largement contribué à Cocos2D-XNA", et je doute qu'ils l'auraient fait si la licence ne leur permettait pas de la redistribuer.

Ce que Xamarin a fait est légal et éthique ... ou presque.

Jetons un coup d'œil à la correction de la licence de la licence et aux corrections de typos diverses dans le fichier Lisez-moi :

LicenseAndCredit.txt (diff)

-Copyright (c) 2010-2012 cocos2d-x.org
-
-Copyright (c) 2008-2010 Ricardo Quesada
-Copyright (c) 2011      Zynga Inc.
-Copyright (c) 2011-2012 openxlive.com
-Copyright (c) 2012      Totally Evil Entertainment, LLC
-Copyright (c) 2012      Gena Minchuk
-Copyright 2012 Xamarin Inc
+Copyright (c) The Cocos2D-XNA Team

Il n'y a qu'une seule exigence dans la licence MIT:

L'avis de copyright ci-dessus et cet avis de permission doivent être inclus dans toutes les copies ou parties substantielles du logiciel.

Et Xamarin a fait exactement ce qui était interdit. Xamarin peut penser que cela rend la licence "plus jolie" si elle contient moins de mentions de copyright, mais elle n’a pas la permission (légale ou déontologique) de supprimer la "redondance".

Bien sûr, s’ils réparent le fichier de licence, ils se retrouveront dans le domaine juridique. L'auteur de la bibliothèque d'origine peut ne pas être d'accord, mais il a fait le choix de la licence et il ne peut en vouloir à personne d'avoir fait ce que la licence permet explicitement.

Il serait malhonnête de permettre aux gens de tirer des conclusions inexactes sur la paternité de n'importe quel code de la fourche, même si la légalité est couverte en fournissant les avis nécessaires et l'historique de révision à ceux qui choisissent de regarder de près. Donc, peut-être que la présentation de Xamarin est contraire à l'éthique, peut-être que non, mais je pense que c'est sur cette base que l'on peut juger: est-ce que cela induit en erreur?

La licence stipule l’autorisation d’utiliser le code et l’obligation d’inclure des notices de copyright pertinentes avec des copies du code. C'est tout à un niveau assez bas. Il ne discute pas de la manière dont vous devriez résumer publiquement qui a contribué quoi, mais ce n'est pas parce que cela dépasse le cadre de la licence et n'est pas prévu dans l' accord juridique que rien ne va éthiquement . L'éthique varie, mais donner un crédit honnête là où il est dû est un principe assez répandu, il est donc facile de comprendre pourquoi le non-respect de celui-ci offensera.

Comme tout le monde le dit, la licence du MIT ne contient aucune intention de prévenir les forks, ce qui n’est pas contraire à l’éthique. Si «changez de nom et personnalisez-le» est un code pour «faire des réclamations publiques de crédit que vous ne méritez pas», alors assurez-vous que ce serait contraire à l'éthique si cela est vrai.

Pour ce qui est d'éviter que cela ne vous arrive: si vous voulez éviter que quelqu'un d'autre insinue que votre code leur appartient, vous avez alors besoin d'une voix forte pour réclamer un crédit. Si vous voulez éviter que quelqu'un crée un fork de votre code qui pourrait éventuellement s'avérer plus populaire que votre original (soit en raison de leurs ressources plus importantes, soit simplement en se concentrant sur les "bons" besoins des utilisateurs), alors je pense que vous êtes absent. de chance dans l'OSS. Vous ne pouvez pas décider d'avoir raison si un autre groupe souhaite utiliser le logiciel avec des fonctionnalités différentes de celles que vous souhaitez, et si (de l'avis des utilisateurs) vous vous trompez, vous devriez perdre, même si vous y êtes le premier. C’est une conséquence du principe primaire de l’open source (ou bien du principe du logiciel libre) selon lequel l’auteur ne contrôle pas le logiciel, mais les personnes qui l’exécutent le font.

Une extension du sujet de la marque:

Dans Apache Software Foundation, tout le code est AL. Et, comme pour la licence BSD dont il est question ici, il est parfaitement clair que l’AL autorise les fourches. Période. Fin de la conversation. En fait, comme indiqué dans d'autres réponses, toutes les vraies licences open source autorisent les forks. Tout ce qu'ils contrôlent, c'est la licence / l'utilisation du code forké.

La fondation Apache a choisi d’enregistrer et de défendre des marques. Si une entité autre qu'un projet de fondation forge, oh, 'Apache Tomcat', tout va bien ... mais ils ne peuvent pas l'appeler Apache Tomcat et, lorsque nous pouvons défendre la marque, ils ne peuvent pas l'appeler Tomcat .

Le problème ici est que les marques ne sont pas pour les faibles de cœur. Si vous êtes un petit groupe de personnes, sans structure juridique ni financement, vous ne pouvez pratiquement pas utiliser le droit des marques pour protéger votre nom.

En fin de compte, ce genre de chose est l’une des raisons qui ont motivé les diverses fondations existantes.

D'un point de vue éthique, s'il y a une fission interne entre les contributeurs, qui doit dire qui "mérite" de garder le nom? Si, en revanche, un étranger n'apparaît pas, ce n'est probablement pas la chose la plus éthique au monde de laisser le nom inchangé. Ce n'est pas un acte odieux, non plus.

Github est plein de fourches . Parfois, les gens changent le nom, le package Java ou autre, surtout s'ils souhaitent publier sur Maven central. Souvent, ils ne le font pas, et les utilisateurs sont obligés de naviguer dans un labyrinthe de confusion. Ce n'est pas idéal, mais ce sont les pauses avec l'anarchie.