Journal BitKeeper ou Arch

Posté par  (site web personnel) .
Étiquettes :
0
18
nov.
2004
Après avoir lu la méga flame-war sur http://www.kerneltraffic.org/kernel-traffic/latest.html(...) je me pose certaines questions.

le contexte

Pour le développement du noyau Linus Torvalds a choisi un outil propriétaire non libre (BitKeeper) car il est (était ?) supérieur techniquement.
Andréa arcangeli (un autre kernel hacker) demande sur la liste de diffusion si on ne pourrait pas utiliser le logiciel libre Arch qui a fait beaucoup de progrès depuis un an.

petit résumé de la flame-war

Linus répond (assez brutalement) qu'il n'existe rien de comparable à BitKeeper.
Andrea lui indique que au vu de sa réponse il n'a pas suivi le developpement de Arch depuis au moins trois ans.
ensuite grande discussion sur la scalabilité réelle de Arch par rapport à BitKeeper.
Linus veut mettre fin à la discussion en disant qu'il choisit les outils qu'il veut pour son travail et que du moment qu'il n'impose rien aux autres on ne doit rien lui imposer (voir ci-dessous l'extrait):
Andrea, shut up.
It's not _your_ decision to make, or your decision to complain about. It's the developers decision. It was mine, Jeff's, David's, Andrew's... Not yours.
It's your decision is to not use BK. Fine. But then complaining when people decide to use the best tool available is fricking impolite. Not just to Larry, but to the people who made the choice.
You whine about BK taking rights away, but the fact is, BK is an _option_ for people to use. _YOU_ are the one trying to limit what people are supposed to do.
In short, BK isn't the problem. You are.


cela continue encore et encore....

mes questions

je suis d'accord (comme tout le monde je pense) pour reconnaitre que chacun a la liberté d'utiliser les logiciels qu'il souhaîte, même des logiciels non libres.
le problème ici est ; est-ce que ce choix fait par linus impacte d'une quelconque façon les autres developpeurs ?
il semble que oui au vu de cette reflexion faite par un autre hacker à Linus:
nobody cares what you are using privately, but your decisions as kernel maintainer have an effect on other people, may this be the patches you include in the next release or the tools you distribute them with.

Comment ça marche le dev du noyau ? les hackers puristes du libre et utilisant Arch peuvent-ils soumettre leurs patchs sans aucun problème pour inclusion dans l'arbre BitKeeper de Linus ?
  • # BK conçu pour Linus

    Posté par  . Évalué à 8.

    il y a un point que tu ne mentionne pas:
    Au départ a été conçu pour les besoins de Linus, par un dev du noyau. A mon avis, ça joue beaucoup dans la tête de Linus.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: BK conçu pour Linus

      Posté par  (site web personnel) . Évalué à 1.

      Il manque un mot dans ta phrase qui manque
      c'est arch (je suppose) qui a été construit pour le noyau ? pourquoi cela joue en mal ?!
      • [^] # Re: BK conçu pour Linus

        Posté par  (site web personnel) . Évalué à 3.

        C'est bitkeeper, à la base.

        Mais un des objectifs de Arch était de pouvoir remplacer BK pour le développement de Linux. Pour l'instant, il est encore à la traine sur un bon nombre de points.
        • [^] # Re: BK conçu pour Linus

          Posté par  (site web personnel) . Évalué à 2.

          Mais un des objectifs de Arch était de pouvoir remplacer BK pour le développement de Linux. Pour l'instant, il est encore à la traine sur un bon nombre de points.

          Tu saurais quels sont ces points a la traine ? Ou une url qui les listerait ?
          • [^] # Re: BK conçu pour Linus

            Posté par  (site web personnel) . Évalué à 10.

            Je ne connais pas trop BK, à part les deux trois trucs que j'ai pu lire ça et là, et c'est très difficile de faire une bonne comparaison vu que les personnes qui pourraient le mieux la faire (devs de tla) ne sont pas éligibles pour la license gratuite de BK ... mais les points faibles de Arch, à mon avis :

            * Tous les messages de log sont conservés dans l'arbre de travail, chacun dans un fichier séparé. Pour le développement de Xtla, qui est un tout petit projet par rapport à Linux, l'ensemble des fichiers de log prends 8 fois plus de place sur le disque que les sources ! Résultat, il faut de temps en temps effacer des fichiers, et on perd les traces de l'historique.

            * Le mode de fonctionnement par défaut de BK, c'est que le programmeur doit dire quel fichiers il modifie (en pratique, il programme son éditeur de texte pour le faire). Résultat, la plupart des operations sur l'arbre sont en O(nombre de fichiers modifiés) et non en O(nombre total de fichiers).

            * Arch utilise des expressions régulières pour classifier les fichiers. C'est très pratique, sauf que le moteur d'expression régulières n'est pas des plus efficaces, donc, il y a un assez gros problème de performances a ce niveau là.

            * La réactivité de l'équipe de devs. J'ai du m'y reprendre à 3 fois pour faire accepter un patch de une ligne. Si on regarde l'historique de tla depuis la version 1.2, c'est assez drôle : Une faille de sécurité dont la correction a mis plusieurs mois à être intégrée à une release officielle, une 1.2.2rc2 qui n'est jamais devenue 1.2.2 pour cause de conflits personnels entre développeurs, le changelog entre la 1.2 et la 1.3rc2 qui se trouve du coup ridiculement petit par rapport aux mois de développement qui séparent ces deux versions. La moitié des liens du site officiel www.gnuarch.org qui pointent sur une erreur 404, ... Bref, dans l'état actuel des choses, généraliser l'utilisation de arch pour un projet de grande taille me parait bien risqué ...
  • # bk et linux

    Posté par  . Évalué à 3.

    Linus, pour développer, utilise aussi un PC avec un BIOS non libre, avec des périphériques dont les firmware sont non libre, etc. Linux n'en reste pas moins libre.

    C'est pour l'image du libre que ce n'est pas terrible.
    Pour allimenter le troll sur "je me prend pour un hacker de noyau donc je veux un outils pour hacker de noyau :
    http://www.darcs.net/(...)

    Qui nous fait un Bk vs Arch vs Darcs pour les hackers de noyau ?
    • [^] # Re: bk et linux

      Posté par  (site web personnel) . Évalué à 4.

      ma question c'était : est-ce que ce choix fait par Linus impacte les autres developpeurs ? est-ce qu'ils ont des problèmes de compatibilité avec l'arbre BitKeeper de Linus ?
      • [^] # Re: bk et linux

        Posté par  . Évalué à 3.

        Non.
        Un patch est un patch. Tu l'envoies à Linus et il l'applique ou pas à son arbre.
        Le dernier snapshots de Linus est ici :
        http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/(...)

        Il n'y a pas de problème de compatibilité, mais c'est plus chiant.

        Si Linus utilisait Subversion et que quelqu'un veut lui "imposer" Arch, il y aurait les même désagréments.
        • [^] # Re: bk et linux

          Posté par  (site web personnel) . Évalué à 6.

          >Un patch est un patch. Tu l'envoies à Linus et il l'applique ou pas à son arbre.

          Ah non, tu envoies à Linus un patch corrigeant un bug pour le 2.6.7, bug toujours présent dans le 2.6.9. Manque de bol, c'est pas synchronisé avec les derniers patchs de Linus, car le code a beaucoup changé sur la forme... bah ton patch a de fortes chances d'etre rejeté.

          Donc non, le probleme d'un patch, c'est qu'il doit etre relativement synchronisé avec la version de dev. Tous les patchs ne se valent pas.

          Donc comme j'explique plus bas, utiliser BitKeeper n'est pas une obligation mais permet d'etre sur de soumettre des patchs que Linus a de fortes chances de ne pas rejeter pour cause de desynchronisation avec son arbre.

          >Si Linus utilisait Subversion et que quelqu'un veut lui "imposer" Arch, il y aurait les même désagréments.

          Non arch et SVN ont des formats de patchsets connus, et rien n'empeche de creer des passerelles equifonctionnelles pour qu'un patchset arch soit repercuté sur le repository SVN et vice versa.

          Avec BitKeeper, tu pries pour que Larry accepte de te coder la passerelle dont tu reves, et surtout comme tu connais pas ce que fait bitkeeper, tu reves pour que un patchset ne soit pas dégradé au passage. eg: BitKeeper -> CVS est un changement à perte, puisque tu n'es plus capable d'extraire un patchset particulier en raison du fait que CVS versionne par fichier et non l'arbre complet.
          • [^] # Re: bk et linux

            Posté par  . Évalué à 7.

            > Manque de bol, c'est pas synchronisé avec les derniers patchs de Linus

            T'as un snapshot quotidien de la branche Linus sur www.kernel.org !
            Ce n'est pas le bout du monde de synchroniser ton patch.

            > Donc comme j'explique plus bas, utiliser BitKeeper n'est pas une obligation mais permet d'etre sur de soumettre des patchs que Linus a de fortes chances de ne pas rejeter pour cause de desynchronisation avec son arbre.

            Ça ne change rien. BitKeeper ou pas tu dois synchroniser ton patch.
            Sans BitKeeper c'est moins pratique mais tout a fait réalisable sans grande difficulté.

            Andrew Morton utilise Bk depuis peu de temps. Avant il faisait sans Bk et il en brasse des patchs.
            Alan Cox n'utilise pas Bk.
            etc.
            • [^] # Re: bk et linux

              Posté par  . Évalué à 4.

              T'as un snapshot quotidien de la branche Linus sur www.kernel.org !
              Ce n'est pas le bout du monde de synchroniser ton patch.


              Mieux t'as le repository cvs via "rsync rsync://rsync.kernel.org/pub/scm/linux/kernel/bkcvs/linux-2.5/"
      • [^] # Re: bk et linux

        Posté par  . Évalué à 1.

        Après les passerelles Instant Messaging , inventons les passerelles SCM pour satisfaire les fanas du libre et les assujettis au proprio

        Clearcase <--> SVN <-> Arch <--> BK<-->Perforce<-->PVCS

        Qui dit mieux ?

        Bien sûr que le choix d'un outil de gestion de conf impacte une équipe et même plus, il influe sur le mode et le processus de développement.

        Va essayer de faire du dev libre (massivement distribué) avec du Clearcase (si'il etait opensouce, bine sùr).
        Y'en a même qui ont essayé.
        http://www.netcraft.com.au/geoffrey/katie/(...)

        Il n'en reste pas moins que l'auteur de Linux est Linus et qu'il a le droit de choisir avec quel outil il veut développer. Les autres s'adaptent ou s'en vont à moins qu'on lui prouve qu'Arch est vraiment mieux que Bk.

        Une migration, ca se fait pas en 5 mn et en plus, il faut que les gens se forment, surtout quand on voit le design d'arch(tla) et sa complexité. La dernière fois que j'ai jeté un oeil dessus, il y'avait 3 modes pour gérer l'ajout automatique des fichiers au contrôle de version avec des cas particuliers partout, une vraie UAG.Mais on comprend que ca plaise aux fanas du s/ruby/$_/
        Et comme Linus pose la question est-ce que ca tient la charge.

        Il est poilu cui là ... Hein
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: bk et linux

            Posté par  . Évalué à 2.

            Autant pour moi ta as raison, vu sur http://www.linux.org/info/gnu.html(...) Linux is written and distributed under the GNU General Public License ... Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Moi, qui était persuadé que Linus etait l'auteur de Linux , il en a fait don à la FSF. Quel Saint Homme ! A moins qu'on renonce toujours à ses droits d'auteurs quand on diffuse un soft sous GPL. Quelqu'un pour confirmer ?
            • [^] # Re: bk et linux

              Posté par  . Évalué à 1.

              C'est le texte de la GPL qui est copyright FSF pas Linux.
              • [^] # Re: bk et linux

                Posté par  . Évalué à 2.

                c'est bien ce qui me semblait donc le copyright(left) de Linux appartient bien à Linus alors. Donc c'est quand même légitime qu'il choisisse les outils avec lesquels il veut travailler, et les autres doivent s'adapter.

                En plus, il me parait raisonnable ce monsieur donc si les arguments pour abandonner Bk pour un autre gestionnaire de source étaient décisifs , il ne s'entêterait pas.
                • [^] # Re: bk et linux

                  Posté par  (site web personnel) . Évalué à 3.

                  Non.

                  Linus est propriétaire de la marque déposée "Linux", et il est propriétaire de ses propres contributions à Linux. Or, la grande majorité du code de Linux vient de contributions extérieures, le rôle de Linus étant de s'assurer de la qualité et de l'abscence de backdoor dans le code avant de l'intégrer au noyau officiel. Donc, la grande majorité du code ne lui appartient pas.

                  Par contre, c'est lui le "chef de projet", et il fait bien ce qu'il veut avec Linux. Si les gens ne sont pas d'accord avec lui, ils peuvent forker, mais je crois que personne ne serait assez fou pour ça ...
                • [^] # Re: bk et linux

                  Posté par  . Évalué à 3.

                  Suivant les projets, il est demandé aux contributeurs de donner leur copyright à la structure organisationnelle ou pas. Les développeurs Gentoo doivent donner leur copyright à la foncdation Mentoo. Même chose pour Mozilla (ce n'était pas le cas avant mais je crois que ça l'est maintenant). Pour Linux, non. Linus a décidé que chaque contributeur conserverait son copyright sur ses lignes de code.
                  Ce qui a comme conséquence indirecte qu'il est pratiquement absolument impossible de changer la licence de Linux de GPL à autre chose car il faudrait demander leur accord à plusieurs milliers d'individus.
                  Donc, non. Linus n'est pas le détenteur légitime de Linux, uniquement de ses propres lignes de code, ce qui ne doit plus faire un si grand pourcentage...
            • [^] # Re: bk et linux

              Posté par  (Mastodon) . Évalué à 0.

              vu sur http://www.linux.org/info/gnu.html(...(...)) Linux is written and distributed under the GNU

              Ouiménon. Un whois linux.org n'arrive pas à me convaincre que linux.org est quelqu'un qui fait parti du monde Linux. Surtout quand tu regarde le site du type: http://www.invlogic.com/(...)

              Tu as donc PERDU.
              • [^] # Re: bk et linux

                Posté par  . Évalué à 2.

                et tu la trouve où la license de Linux et à qui elle appartient

                A tout le monde

                man os ????
                man GPL

                moi qui croyais que les dev libres faisaient ca pour la gloire , si ils ont même pas le droit de voir figurer leur nom, ils seront tous canonisés

                Allelluia
                • [^] # Re: bk et linux

                  Posté par  (site web personnel) . Évalué à 2.

                  > si ils ont même pas le droit de voir figurer leur nom,

                  Bien sur que si, ils ont leur nom !

                  Tu télécharges les sources de Linux, et tu regardes le fichier CREDITS à la racine de l'arbre. (Il y a du monde !!)
            • [^] # Re: bk et linux

              Posté par  (site web personnel) . Évalué à 1.

              euh c'est la GPL qui est copyright FSF pas linux...
        • [^] # Re: bk et linux

          Posté par  . Évalué à 1.

          t'as oublié continuus
  • # Pourquoi ca impacte tous les devs...

    Posté par  (site web personnel) . Évalué à 10.

    Linus a fait le choix d'utiliser BitKeeper, soit, voyons pourquoi ce choix n'impacte pas seulement son workflow mais bien le workflow de tous les contributeurs importants.

    Le principal point à prendre en considération est que linus est celui qui pour l'instant maintient la branche principale, les autres devs maintiennent des branches secondaires et donc l'une des taches les plus courantes pour ces developpeurs, c'est de se resynchroniser avec la branche principale sous peine de se rajouter de la charge de travail à devoir réadapter leurs patchs par pans entiers.

    Or si linus n'expose ses derniers changements que via BitKeeper, les autres devs sont obligés d'utiliser BitKeeper... ce qui en soit ne serait pas ultra choquant même s'il est non libre. LE plus gros problème est la license de BitKeeper, qui non content d'etre non libre (ce qui deja réduit la liberté des hackers noyaux qui doivent l'utiliser pour se resynchroniser), elle impose que tout utilisateur renonce à travailler sur des projets pouvant concurrencer BitKeeper. Donc tu renonces au droit de modifier/acceder aux sources de BitKeeper, mais en plus tu renonces carrement à participer au developpement d'un gestionnaire de source.

    Donc le choix de Linus n'impacte pas seulement comment les autres développeurs doivent travailler (via BitKeeper pour ne pas morfler), il réduit de facon indirecte les options de travail d'un dévéloppeur noyau. Donc prend n'importe quel dev noyau, qui aime CVS/Arch/SVN/Darcs/Monotone, bah s'il respecte la license, il aurait pas le droit de contribuer activement a ces projets.

    PS: ce genre de clause doit surement etre illégale en France, un peu comme la clause de non concurrence d'un contrat de travail doit etre limité dans le temps, dans l'espace et le domaine d'activité, ou bien compensée financièrement.

    PPS: la clause super tordue de BitKeeper n'est la que pour la version Freeware dispo pour tout un chacun, la version payée ne l'integre pas il me semble.
    • [^] # Re: Pourquoi ca impacte tous les devs...

      Posté par  (site web personnel) . Évalué à 6.

      > Or si linus n'expose ses derniers changements que via BitKeeper, les autres devs sont obligés d'utiliser BitKeeper...

      Il y a tout de même une passerelle BK -> CVS, si j'ai bonne mémoire : [http://lwn.net/Articles/25203/(...)]. J'ai même cru ouïr quelque chose à propos d'une passerelle vers SubVersion, mais je n'en jurerais pas.

      > LE plus gros problème est la license de BitKeeper, qui […] impose que tout utilisateur renonce à travailler sur des projets pouvant concurrencer BitKeeper

      Larry McVoy pense que, si quelqu'un veut écrire un projet concurrent au sien avec son soft, il n'a qu'à le payer (comme tu l'indiques, la version commerciale n'a pas cette restriction). On peut discuter longtemps pour savoir si cette attitude est injuste, immorale, etc., mais en fin de compte, je trouve l'affaire BitKeeper un peu hors de proportions. Linus semble apprécier M. McVoy et son logiciel, c'est son droit. De toute manière, si vraiment ça agace trop de monde, tout ce que Linus va gagner à s'obstiner, c'est des forks hostiles, des devs qui vont s'en aller rejoindre d'autres projets, etc. Si ça ne se produit pas, à mon avis c'est qu'en fin de compte les gens arrivent à travailler sans gros problèmes, BK ou pas BK.

      Envoyé depuis mon PDP 11/70

      • [^] # dans une réponse d'andrea

        Posté par  . Évalué à 3.

        "AFIK Miles tried to buy a copy of BK but Larry refused to sell it"
        il ne veut pas develloper un produit concurrent avec BK , mais le fait de l'utiliser BK l'empeche de develloper un produit concurrent
      • [^] # Re: Pourquoi ca impacte tous les devs...

        Posté par  . Évalué à 2.

        Il y a tout de même une passerelle BK -> CVS, si j'ai bonne mémoire : [http://lwn.net/Articles/25203/(...(...))]. J'ai même cru ouïr quelque chose à propos d'une passerelle vers SubVersion, mais je n'en jurerais pas.

        Elle ne marche plus a cause des pn de secu introduit par cvs.

        Par contre du peut recuperer le repository cvs via rsync :
        rsync rsync://rsync.kernel.org/pub/scm/linux/kernel/bkcvs/linux-2.5/
    • [^] # Précision

      Posté par  . Évalué à 3.

      N'étant pas au courrant de toute l'histoire, j'ai une question a propos de cette fameuse clause
      Elle interdit quoi exactement ?
      scenar 1) Utiliser BK pour n'importe quel projet à partir du moment ou on bosse sur un soft concurrent.
      scenar 2) Utiliser BK pour gérer le dev d'un concurrent.

      Avis perso :
      Si c'est le 1, ca mérite qu'on discute autour de cette clause.
      Si c'est le 2, c'est pas bien grave et ca ne vaut pas tout ce foin.
    • [^] # Re: Pourquoi ca impacte tous les devs...

      Posté par  . Évalué à 2.


      Donc tu renonces au droit de modifier/acceder aux sources de BitKeeper, mais en plus tu renonces carrement à participer au developpement d'un gestionnaire de source.


      Là , j'ai un doute:

      1/ les developpeurs kernel qui participent en plus au dev d'un projet de gestionnaire de source ne doivent pas être légion

      2/ la clause empêche que le projet de gestionnaire auquel ils participeraient soit hébergé sou Bk, mais il pourraient toujours utiliser Bk pour participer au dev du kernel
      • [^] # Re: Pourquoi ca impacte tous les devs...

        Posté par  . Évalué à 1.

        c'est bien ce que je disais:
        les clauses en question


        (d) No free use for competitors: Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a product which contains substantially similar capa- bilities of the BitKeeper Software, or, in the reasonable opinion of BitMover, competes with the BitKeeper Software.
        (e) No combination with competing products: Inclusion of the BitKeeper Software for use with a system having substan- tially similar capabilities of the BitKeeper Software requires prior written permission from BitMover.


        Ca ne précise pas qu'on ne peut pas utiliser Bk pour Linux si on on developpe un gestionnaire concurrent.
        Ce qu'il ne veulent pas, c'est heberger gratuitement un projet concurrent. Ca parait humain.
        Et même si c'était le cas je pense qu'il suffirait de leur demander la permission ou dans le pire des cas on prend une licence payante. Et on veut bien se cotiser pour la payer au gars en question.
        Quand on voit ce qu'on récolté l'équipe Firefox ca devrait pas être un pb.
        • [^] # Re: Pourquoi ca impacte tous les devs...

          Posté par  . Évalué à 2.

          T'as déjà pensé à prendre des cours d'anglais ?
          « (d) No free use for competitors: Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a product which contains substantially similar capa- bilities of the BitKeeper Software, or, in the reasonable opinion of BitMover, competes with the BitKeeper Software. »
          C'est écrit où que la seule restriction, ça concerne l'hébergement d'un project concurrent dans un repository bitkeeper si t'utilise la version gratuite ? De la façon dont je comprends cette licence (j'ai pas lu tout la licence, donc c'est peut être clarifié autre part), qqu'un qui bosserait dans la boîte qui développe ClearCase par exemple n'a pas le droit d'utiliser la licence gratuite de BitKeeper pour faire du développement noyau même s'il travaille sur un projet n'ayant aucune relation avec ClearCase.
          • [^] # Re: Pourquoi ca impacte tous les devs...

            Posté par  . Évalué à 1.

            D'accord avec toi

            Mais à mon avis dans leur esprit c'est plutôt héberger un projet concurrent qui les gêne
            et je pense qu'il n'imaginaient pas que quelqu'un puisse bosser sur deux projets en même temps. C'est un flou dans la license qu'ils n'avaient pas prévu.

            c'est pourquoi j'avais précisé

            Et même si c'était le cas je pense qu'il suffirait de leur demander la permission


            parce que moi non plus j'ai pas envie de me palucher à lire toute la license.
            J'ai déjà pris la peine de la rechercher les clauses qui me paraissaient coller alors à minuit tu comprendras que je m'embrouille .
            • [^] # Re: Pourquoi ca impacte tous les devs...

              Posté par  (site web personnel) . Évalué à 4.

              Non, c'est très clair dans la license : Tu contribue à un truc qui ressemble à un gestionnaire de version, tu n'est plus éligible pour la version gratuite de BK, point.

              En particulier, si tu développe un concurent à BK, tu ne peux pas récupérer BK gratuitement pour voir comment ça marche et reprendre des idées.
            • [^] # Re: Pourquoi ca impacte tous les devs...

              Posté par  . Évalué à 2.

              Larry McVoy a clairement répondu une fois à un mec (je sais plus qui). Il est contributeur au noyau ET à arch je crois.
              Il n'avais pas le droit d'utiliser bk pour le devel linux s'il contribuait à arch (y compris sans utiliser bk).
              Faudrait que je retrouve le message.
              • [^] # Re: Pourquoi ca impacte tous les devs...

                Posté par  . Évalué à 3.

                Qui est Larry Mc Voy le kernel developpeur ou un gars de chez Bk ?

                La question est de savoir si cette clause est volontaire,
                si des kernels developpeur ont essuyé un refus
                ou s'il est possible de negocier avec Bk peut-être, tout simplement parce qu'il y une ambiguité dans leur license.

                Est-ce quelqu'un s'est adressé à eux en expliquant, je développe un gestionnaire concurrent mais je travaille également sur un projet libre
                ai-je le droit d'utilser Bk sur ce projet ou peut on négocier ?

                Je me rabâche, mais c'est important car là on peut mesurer s'ils ont des pratique anti-concurrentielles.
                Si vraiment la clause est appliquée à la lettre ils sont critiquables.
                En attendant je préfère leur accorder le bénéfice du doute.
      • [^] # Re: Pourquoi ca impacte tous les devs...

        Posté par  (site web personnel) . Évalué à 3.

        >1/ les developpeurs kernel qui participent en plus au dev d'un projet de
        > gestionnaire de source ne doivent pas être légion

        1) à peut près toutes les distributions Linux

        2) plusieurs contributeurs de Arch sont aussi contributeurs de Linux.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.