web-dev-qa-db-fra.com

Comment éviter d'être bifurqué 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 multiplateforme pouvant être incluse dans des projets PCL.

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

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

Bien qu'il ne soit pas illégal, il est contraire à l'éthique.

Il semble que le GitHub page du nouveau projet n'indique même pas qu'il s'agit d'un fork d'une manière GitHub typique, optant plutôt pour une section Historique facilement amovible (voir en bas).

Mes questions sont donc:

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

J'espère que cela pourrait être une question wiki ou il y aura des réponses objectives basées sur l'éthique/philosophie OSS moderne.

124
Den

L'action de Xamarin et la manière dont l'action a été menée étaient-elles éthiques ou non?

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

La licence MIT (MIT)

Copyright (c)

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:

L'avis de droit d'auteur ci-dessus et cet avis d'autorisation doivent être inclus dans toutes les copies ou parties substantielles du logiciel.

LE LOGICIEL IS FOURNI "TEL QUEL", SANS GARANTIE D'AUCUNE SORTE, EXPRESS OR IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER LES GARANTIES DE QUALITÉ MARCHANDE, D'ADÉQUATION À UN OBJECTIF PARTICULIER ET NON-CONTREFAÇON. EN AUCUN CAS LES AUTEURS OR LES DÉTENTEURS DE DROITS D'AUTEUR NE SERONT RESPONSABLES DE TOUTE RÉCLAMATION, DOMMAGE OR AUTRE RESPONSABILITÉ, QUE CE SOIT DANS UNE ACTION DE CONTRAT, TORT OR AUTREMENT, DÉCOULANT DE, SUR OR EN CONNEXION AVEC LE LOGICIEL OR L'UTILISATION OR AUTRES OPÉRATIONS DANS LE LOGICIEL.

Si quelqu'un - particulier ou entreprise - publie un logiciel/code source avec une licence MIT, cela signifie que quiconque - particulier ou entreprise peut "traiter le Logiciel sans restriction". Tant que le droit d'auteur l'avis reste intact, ils sont à peu près 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 comprenait pas la licence ou ses implications, elle ne faisait pas preuve de diligence raisonnable. L'Initiative Open Source fournit de nombreuses autres ressources Nice pour nous aider à comprendre des licences comme la variante MIT. Voyons quelques clauses de leur définition Open Source:

1) Redistribution gratuite - La licence ne doit pas empêcher une partie de vendre ou de céder le logiciel en tant que composant d'une distribution de logiciel agrégée contenant des programmes provenant de plusieurs sources différentes. La licence ne doit pas exiger de redevance ou d'autres frais pour une telle vente.

3) Œuvres dérivées - La licence doit autoriser les modifications et les œuvres dérivées et doit permettre leur distribution dans les mêmes conditions que la licence du logiciel d'origine.

5) Aucune discrimination contre les personnes ou les groupes - La licence ne doit pas discriminer contre une personne ou un groupe de personnes.

6) Aucune discrimination contre les domaines d'activité - La licence ne doit pas empêcher quiconque d'utiliser le programme dans un domaine d'activité spécifique. Par exemple, il peut ne 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 open source, en particulier avec la licence MIT, permet à quelqu'un de prendre librement le logiciel, de le changer, de l'empaqueter et de le vendre à peu près n'importe qui ils aiment, tant qu'ils ne suppriment pas votre avis de droit d'auteur et prétendent qu'il s'agit de leur propre travail unique .

En tant qu'auteur, vous renoncez explicitement au droit d'être pointilleux et exigeant. Vous ne pouvez pas décider qui ou quoi peut bénéficier de votre logiciel ou l'utiliser, et vous ne pouvez pas décider pourquoi ils l'utilisent. Vous renoncez explicitement à ce droit.

L'idée est que vous contribuez au plus grand bien 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 fait. Si Microsoft veut débourser votre projet FluffBall et le vendre pour 2 000 $ par siège en tant que WindowsSpongeCake, ils le peuvent. Ne laissait-on pas les gens faire tout ce qu'ils veulent en premier lieu?

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

En quelque sorte! Tout d'abord, utilisez une licence qui vous convient ainsi qu'aux objectifs et aux désirs de votre organisation. 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 Open Source - 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 un version copyleft de la GPL . Si vous voulez une licence non commerciale, vous devriez probablement demander conseil à un avocat spécialisé dans les droits d'auteur/licences, car il n'est souvent pas du tout considéré comme un logiciel "open source" et il n'y a pas de licence pré-écrite majeure pour prendre en charge cette affaire.

Le problème avec le kerfuffle Xamarin et Coco n'est pas une question d'éthique ou de légalité - il s'agit d'une lutte sur Internet entre quelques personnes qui ont un boeuf entre elles. 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 façon dont le projet doit ê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 l'option est de créer et d'avoir votre propre projet.

C'est très humain et compréhensible pour les sentiments d'appartenance et de popularité de rendre les projets logiciels très, très compliqués. Mais l'objectif de l'open source est d'essayer de transcender cela et de permettre au meilleur logiciel d'être disponible gratuitement pour tous.

En fin de compte, soyez clair sur vos objectifs lorsque vous décidez d'une licence, et comprenez ses implications pour votre futur contrôle et direction du projet. Si vous voulez simplement faire un don pour le plus grand bien, l'open source est la voie à suivre. Si vous voulez contrôler votre projet plus étroitement et avoir la propriété et au moins un cas juridique si quelqu'un essaie de commercialiser votre projet ou de l'absorber (partiellement ou entièrement), vous aurez besoin d'une licence différente et devrez probablement régler avec un avocat.

73
BrianH

La publication d'un projet sous la licence MIT donne aux utilisateurs la permission de bifurquer le projet. Une partie de la philosophie du logiciel libre consiste à donner aux utilisateurs et aux développeurs le droit d'utiliser, de modifier et de publier le logiciel dans des moyens qui ne seraient normalement pas autorisés. Si vous ne voulez pas que les gens le fassent, n'utilisez pas la licence MIT. Vous ne pouvez pas vraiment vous plaindre lorsque les gens utilisent du code sous le termes de la licence que vous leur avez donnée.

Les fork sont une chose assez normale dans la communauté du logiciel libre. Il semble que les développeurs de Fork aient essayé de contribuer au projet d'origine, et n'étaient pas d'accord, ils ont donc plutôt contribué à leur propre projet. Le logiciel libre encourage cela afin que les développeurs ne soient pas empêchés de modifier le logiciel parce que les propriétaires n'aiment pas leurs changements.

De plus, 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 si c'était sous une licence différente. Si vous acceptez des contributions sous licence, vous devez vous-même respecter les termes de la licence.

Une façon de garder le contrôle sur une version officielle est de s'appuyer sur des choses comme 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 la fourchette de ceci).

D'autres licences comme LGPL autorisent toujours les fourches, mais gardez le code ouvert. De cette façon, vous pouvez au moins intégrer toutes les modifications de 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 donc si vous vouliez plus de contrôle sur le projet, vous pourriez utiliser LGPL à la place.

121
fgb

Je n'appellerais pas cela contraire à l'éthique. Je dirais que c'est antisportif. Il y a une attente non écrite que vous ferez un effort de bonne foi pour améliorer la version originale avant de décider de bifurquer, et il semble que l'auteur original pense que l'effort de bonne foi n'a pas été fait.

Cela étant dit, la meilleure façon d'éviter que votre logiciel ne soit bifurqué 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 fourche s'il sait que l'original est supérieur. En dehors de cela, votre seule protection est de modifier les conditions de licence.

18
Karl Bielefeldt
  • L'action de Xamarin et la façon dont l'action a é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 sous-licencier et/ou de vendre des copies du Logiciel, et de permettre aux personnes à qui le Logiciel est fourni de le faire ", donc c'est définitivement légal.

D'un point de vue éthique, c'est plus compliqué. Dans les communautés open source, il est généralement considéré comme préférable d'améliorer le logiciel d'origine plutôt que de créer un fork. En le lien que vous avez donné , Miguel de Icaza dit:

Comme vous le savez, nous avons largement 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 prendre le projet dans la direction que je souhaitais au détriment de la rétrocompatibilité.

On ne sait pas pourquoi ils "n'ont pas pu collaborer ensemble", mais il semble que Xamarin ait fait un effort raisonnable pour travailler sur le projet original avant de décider de le bifurquer.

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

Légalement, vous pouvez choisir d'utiliser une licence qui ne permet pas de bifurquer en interdisant la redistribution du code source (à ce stade, ce ne serait pas un "logiciel libre"). Une autre option consiste à laisser le code non encombré mais à ne pas permettre la redistribution des actifs statiques comme les images ou le texte non codé (certains jeux ont des licences comme celle-ci).

Socialement, vous pouvez empêcher le bifurcation en:

  • Permettre aux gens d'apporter facilement des modifications à votre projet.
  • Examen rapide des correctifs.
  • Permettre des changements qui ne vous profitent pas directement.
  • Être poli. Un nombre surprenant de fourchettes est dû au fait que les contributeurs ne sont plus disposés à travailler les uns avec les autres.

Le logiciel de fork est 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 bifurquer votre code les forcera simplement à bifurquer le code de quelqu'un d'autre ou à réécrire votre logiciel à partir de zéro. Cela pourrait les ralentir, mais cela ne vous aidera pas beaucoup.

De plus, 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 avait pas permis de le redistribuer.

11
Brendan Long

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

Jetons un coup d'œil à la correction de la licence et aux corrections de faute de frappe diverses dans le fichier Lisezmoi :

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 l'ensemble MIT Licence:

L'avis de droit d'auteur ci-dessus et cet avis d'autorisation doivent être inclus dans toutes les copies ou parties substantielles du logiciel.

Et Xamarin a fait exactement la chose interdite. Xamarin peut penser que cela rend la licence "plus jolie" pour avoir moins d'avis de droits d'auteur en haut, mais ils n'ont pas la permission (légale ou éthique) de supprimer la "redondance".

Bien sûr, s'ils corrigent le fichier de licence, ils seront à nouveau dans le domaine juridique. L'auteur de la bibliothèque d'origine n'est peut-être pas d'accord, mais il a fait le choix de la licence et il ne peut blâmer personne d'avoir fait ce que la licence autorise explicitement.

10
Athari

Il serait louche de permettre aux gens de tirer des conclusions incorrectes sur la paternité du code fourni par le fork, même si les aspects juridiques sont couverts en fournissant les avis nécessaires et l'historique des révisions à toute personne qui choisit de regarder de près. Alors peut-être que la présentation de Xamarin est contraire à l'éthique, peut-être pas, mais je pense que c'est la base sur laquelle le juger: est-ce trompeur?

La licence prévoit l'autorisation d'utiliser le code et l'obligation d'inclure les avis de droit d'auteur pertinents avec des copies du code. C'est tout à un niveau assez bas. Il ne discute pas de la façon dont vous devez résumer publiquement qui a contribué quoi, mais simplement parce que cela sort du cadre de la licence et ne fait pas partie de l'accord légal ne signifie pas que quelque chose se passe éthiquement. L'éthique varie, mais accorder un crédit honnête là où elle est due est un principe assez répandu, il est donc facile de voir pourquoi ne pas le faire offensera.

Comme tout le monde le dit, il n'y a aucune intention dans la licence MIT d'empêcher les fourches, donc ce n'est pas contraire à l'éthique en soi. Si "renommer la vôtre" est un code pour "faire des réclamations publiques de crédit que vous accordez" t méritent ", alors sûr que ce serait contraire à l'éthique si cela est vrai.

Quant à empêcher que cela ne vous arrive: si vous voulez éviter la situation de quelqu'un d'autre insinuant que votre code est le leur, alors vous avez besoin d'une voix forte lors de la demande de crédit. Si vous voulez éviter que quelqu'un crée une fourchette de votre code qui pourrait éventuellement s'avérer plus populaire que votre version d'origine (soit en raison de leurs ressources plus importantes ou simplement en se concentrant sur les "bons" besoins des utilisateurs), alors je pense que vous êtes absent de chance en OSS. Vous ne pouvez pas simplement décider d'avoir raison si un autre groupe veut des fonctionnalités différentes de ce que vous voulez dans le logiciel, et si (du point de vue des utilisateurs) vous vous trompez, vous devriez perdre, même si vous y êtes en premier. C'est une conséquence du principe principal de l'open source (ou proprement, du principe du logiciel libre) que l'auteur ne contrôle pas le logiciel, les gens qui l'exécutent le font.

4
Steve Jessop

Une extension du thème des marques:

À l'Apache Software Foundation, tout le code est AL. Et, comme avec la licence BSD en discussion ici, il est parfaitement clair que l'AL autorise les fourches. Période. Fin de la conversation. En fait, comme discuté dans d'autres réponses, tous les vraies licences open source autorisent les fourches. 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 bifurque, oh, 'Apache Tomcat', ils vont bien ... mais ils ne peuvent pas l'appeler Apache Tomcat, et, quand nous pouvons défendre la marque, ils ne peuvent pas appeler il Tomcat.

Le problème ici est que les marques déposées 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 des différentes fondations.

D'un point de vue éthique, eh bien, s'il y a une fission interne entre contributeurs, qui veut dire qui "mérite" de garder le nom? Si, d'autre part, un fourche de l'extérieur, 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, ou le package Java, ou quoi que ce soit - en particulier s'ils veulent publier sur Maven central. Souvent, ils ne le font pas, et les utilisateurs naviguent dans un labyrinthe de confusion Ce n'est pas idéal, mais c'est la rupture avec l'anarchie.

2
bmargulies