BitMover a annoncé dans un communiqué de presse, le 5 avril, qu'elle cessait le développement de la version gratuite de BitKeeper. Il semblerait qu'un employé de l'OSDL ait commencé à réaliser de l'ingénierie inverse sur le protocole de BitKeeper et que cela n'ait pas plu à Larry McVoy, le principal interlocuteur de BitMover auprès des développeurs du noyau. Ce dernier a notamment déclaré : « ceci est vraiment un problème de la communauté open source et je dois dire que la communauté open source n'aurait pas pu échouer plus qu'elle ne l'a fait. »
BitMover livrera une dernière version gratuite de son outil qui pourra gérer plus de 64 000 modifications. Linus envisage la migration vers un autre système de gestion de version.
Ce brusque changement dans la politique de BitMover montre un des problèmes que peut poser l'utilisation de logiciels propriétaires dans le développement de Logiciels Libres ou de manière plus générale dans les entreprises. L'article de KernelTrap revient en détail sur les raisons du choix de BitKeeper par Linus, les bénéfices qu'ont tiré les développeurs du noyau de son utilisation, puis les motivations de BitMover à supprimer la version gratuite de leur produit.
Aller plus loin
- KernelTrap : No More Free BitKeeper (32 clics)
- BitMover : communiqué de presse (12 clics)
- Journal LinuxFr (9 clics)
- DLFP : BitKeeper et Logiciel Libre (14 clics)
- DLFP : BitKeeper, RMS et PLONK (15 clics)
# Adieu et merci pour le poisson
Posté par Wawet76 . Évalué à 10.
Bah... Apparement leurs parts de marché ont bien bien augmentés ces dernières années. Ça serait marrant de les voir redescendent si ils se mettent les développeurs de libre à dos.
[^] # Re: Adieu et merci pour le poisson
Posté par dco . Évalué à 10.
[^] # Re: Adieu et merci pour le poisson
Posté par let antibarbie = xp <- xp - 1 . Évalué à 5.
Je sais, d'un autre coté BitKeeper est pas libre et sai mal(tm).
[^] # Re: Adieu et merci pour le poisson
Posté par Marc (site web personnel) . Évalué à 8.
Je vois mal comment ça pourrait être autrement. Déjà que jusqu'à maintenant, les projets qui utilisent BitKeeper se voit muni d'un contournement pour pouvoir utiliser cvs/arch/svn/... parceque tous le monde n'aime pas bitkeeper.
Personelement, je ne le trouve pas très user friendly ;)
Comme Lary l'explique, leurs marchés principaux sont plus du coté de windows (il explique comment mettre un document word binaire est super important...). Sans doute que le monde de l' "open source" n'a pas été si bénéfique que ça (et ne l'est sans doute plus du tout).
Espérons que ça boost le dev d'autres outils
[^] # Re: Adieu et merci pour le poisson
Posté par pasBill pasGates . Évalué à 8.
Chacun sa traduction, moi je traduis en :
On a propose de vous aider en vous donnant gratuitement notre soft, et tout ce que vous trouvez a faire c'est du reverse engineering sur notre soft pour nous couler, donc on va arreter de vous aider.
Et tout de suite la position de BitMover devient plus logique et comprehensible
[^] # Re: Adieu et merci pour le poisson
Posté par Benjamin François (site web personnel) . Évalué à 9.
Ça serait pleinement compréhensible si une majorité de devs avait reverse-engineeré le soft, mais là il s'agit tout de même d'un seul type. Pourquoi ne pas avoir tout simplement attaqué ce toto en justice ?
Bien évidemment, ils sont en droit de faire ce qu'ils ont fait et de réagir comme ils l'ont fait, mais ça n'interdit pas de trouver cette réaction disproportionnée.
[^] # Re: Adieu et merci pour le poisson
Posté par gc (site web personnel) . Évalué à 4.
Le problème c'est que des gens employés d'OSDL ont fait du reverse-engineering. D'une part ce n'est pas comme si c'était n'importe qui, et d'autre part c'est l'employeur de Linus. BitMover trouve que c'est du foutage de gueule et çe se comprend.
[^] # Re: Adieu et merci pour le poisson
Posté par Benjamin François (site web personnel) . Évalué à 10.
Larry explained that a contracter still under pay from OSDL for an unrelated project was also actively working on reverse engineering the BitKeeper protocol. Discussion began about five weeks ago to try and resolve the situation, getting so far as to obtain a verbal agreement that the individual would stop his efforts. After that time, however, it turned out that the reverse engineering effort had continued. Although OSDL wasn't directly paying for the reverse engineering effort, they were still employing someone who was actively developing a competing product, something the free BitKeeper license doesn't allow.
Donc UN mec employé d'OSDL a fait du reverse-engineering et ça n'est pas dans le cadre des activités pour lesquelles OSDL l'emploie. La réaction de BitMover est compréhensible, mais à mes yeux exagèrée.
Si un jour on découvre que pendant ses temps libres un employé d'une société X pirate des DVD, on sanctionne la société ?
[^] # Re: Adieu et merci pour le poisson
Posté par pasBill pasGates . Évalué à -2.
Si OSDL a ete averti et n'a rien fait, a eux d'assumer.
[^] # Re: Adieu et merci pour le poisson
Posté par un_brice (site web personnel) . Évalué à 10.
C'est pas pour dire, mais le reverse enginering qui a eu lieu avait pour but la compatibilité.
Imagine que MS fasse un procès à ceux qui implémentent un logiciel compatible MSN ou word, tout le monde hurlerais. Là on plaint ces types tellement soucieux d'aider le logiciel libre qu'ils ont un protocole fermé et propriétaire.
Et le pire c'est que ça a l'air d'être pareil sur kerneltrap... ça me tue.
[^] # Re: Adieu et merci pour le poisson
Posté par Denis Bodor (site web personnel) . Évalué à 4.
"Imagines que MS fasse un procès à ceux qui reversent le client MSN (ou le Word) qu'ils avaient le droit d'utiliser gratuitement à la condition qu'ils ne fassent pas de reverse dessus, justement."
Le problème n'est pas forcément l'éditeur du logiciel qui fait ce qui lui chante. C'est son choix.
Le problème est, peut-être, du côté des utilisateurs ayant décidé d'utiliser ce soft sachant que la "faveur" (gratuité du logiciel) pouvait disparaître du jour au lendemain.
La prérénité est quelque chose de propre aux logiciels libres, pas au graticiels.
[^] # Le paternalisme, c'est mal.
Posté par un_brice (site web personnel) . Évalué à 4.
Et je suis d'accord sur ta remarque quand au danger des "gratuiciels". C'est d'ailleurs probablement dans cette optique que le type écrivait son reverse : voir ce que donnerais un logiciel libre contre Bitkeeper, dans compétition non biaisée par la compatiblité.
Moi j'appelle pas ça un couteau dans le dos. C'est juste un challenge équitable.
Et ça me surprends de voir le point auquel on critique ce type qui n'a fait que rejetter le paternalisme de l'éditeur d'un logiciel propriétaire.
On était censé se contenter de vivre au bon vouloir de bitkeeper ? "Quel villain garnement ! Il a désobéit. Maintenant on est tous punis, on va lui casser la gueule à la récré".
[^] # Re: Le paternalisme, c'est mal.
Posté par pasBill pasGates . Évalué à -1.
Ils sont libres de faire du reverse engineering sur BitKeeper si ca leur chante, il leur suffit de _payer pour les licences_ et de desassembler le soft, et BitMover n'a jamais interdit cela.
[^] # Re: Le paternalisme, c'est mal.
Posté par boubou (site web personnel) . Évalué à 3.
Si, c'est explicitement interdit dans la licence commerciale.
[^] # Re: Le paternalisme, c'est mal.
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: Le paternalisme, c'est mal.
Posté par boubou (site web personnel) . Évalué à 3.
You may not yourself and may not permit or enable anyone to: (i) modify or
translate the Software; (ii) reverse engineer, translate, port, clone, decom-
pile, or disassemble the Software or otherwise reduce the Software to a form
understandable by humans, except to the extent this restriction is expressly
prohibited by applicable law notwithstanding this limitation;
Ca te va ?
[^] # Re: Le paternalisme, c'est mal.
Posté par pasBill pasGates . Évalué à -2.
prohibited by applicable law notwithstanding this limitation;
C'est donc permis dans plein de pays, comme pour n'importe quel soft.
[^] # Re: Le paternalisme, c'est mal.
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # Re: Le paternalisme, c'est mal.
Posté par boubou (site web personnel) . Évalué à 9.
Des fois, t'es vraiment super chiant tellement tu es de mauvaise foi. Le reverse de BK est explicitement interdit dans la licence commerciale du logiciel, contrairement à ce que tu as écrit. La clause que tu indiques est seulement présente pour éviter de rendre la licence illégale dans les pays qui autorisent le reverse et donc pour avoir une unique licence.
Pour une fois, tu pourrais reconnaître que tu t'es trompé, ça ne coûte rien.
[^] # Re: Le paternalisme, c'est mal.
Posté par pasBill pasGates . Évalué à 6.
[^] # Re: Le paternalisme, c'est mal.
Posté par boubou (site web personnel) . Évalué à 4.
[^] # Re: Le paternalisme, c'est mal.
Posté par Zorglub . Évalué à 2.
Tout a fait, c'est absolument valable pour le developpeur de l'OSDL qui faisait du reverse-engineering, ou pour tous ceux qui ont tente de contourner la licence bitkeeper alors qu'ils developpaient d'autres systemes similaires.
Quid de A. Nonyme, qui programme un projet open-source de son cote, qui a bien lu la licence bitkeeper, qui a accepte de la suivre tout comme il faut, et a qui on vient dire "desole, vous n'avez rien fait de mal, mais un abruti en Oregon l'a fait, alors on vous retire la licence" ?
Je sais que Larry McVoy a justifie cela par l'exemple de l'armee, ou tout le monde est puni pour la faute d'une personne (une des choses que j'ai le plus deteste a l'armee d'ailleurs - je me souviens plus si tu avais fait ton ecole de recrue ?), mais comment choisir d'utiliser un logiciel sur le long-terme (gratuit ou pas) si (1) meme en respectant la licence, tu peux perdre le droit de l'utiliser, et (2) ton droit de l'utiliser depend du comportement de n'importe quel abruti sur la planete ?
Ceci ne serait bien sur pas un probleme si BitMover annoncait qu'ils arretent simplement de developper la version gratuite et la laissent dans sa version actuelle -- mais d'apres ce que j'ai compris, elle ne sera plus utilisable du tout d'ici 3 mois (par contre, le serveur qui heberge les sources de differentes versions du noyau restera disponible).
Zorglub
[^] # Re: Le paternalisme, c'est mal.
Posté par boubou (site web personnel) . Évalué à 0.
C'est marrant, j'ai écrit plus bas que McVoy était un con car il "justifiait" son action par l'exemple des punitions collectives de l'armée et ce commentaire est noté très négativement... Peut être aurais-je du plutôt employer des grands mots et dire que la notion même de punition collective est contraire à certains principes fondamentaux des droits de l'homme. Bref...
[^] # Re: Le paternalisme, c'est mal.
Posté par pasBill pasGates . Évalué à 0.
Il y a surement dans le tas des gens qui ont condamne l'acte du gars et qui se retrouvent avec un BitKeeper non fonctionnel, mais a mon avis BitMover a surtout voulu sanctionner la communaute dans on ensemble pour son manque de reaction.
Sinon, oui j'ai fait mon ecole de recrue malheureusement, par contre la bonne nouvelle c'est que l'annee prochaine ca fera 6 ans que je hors de la Suisse, donc plus de cours de repetition :+)
[^] # Re: Le paternalisme, c'est mal.
Posté par reno . Évalué à -1.
Bitkeeper, pour la version gratuite lui ne dependait en rien de l'achat d'autre chose.
Ceci dit, "punir" une communauté parce qu'un de ses membres fait quelque-chose de "répréhensible" (du point de vue de Larry Mc Voy), sans commentaire.
Enfin, Bitkeeper aura quand même eu le gros avantage de faire avancer Linux plus rapidement durant une certaine période, par contre la migration des données ne devrait pas être drole..
[^] # Re: Le paternalisme, c'est mal.
Posté par un_brice (site web personnel) . Évalué à 2.
Et, comme je l'ai déjà dit, le prix n'est pas la question, on parle de la compatiblité et d'une concurrence non faussée. Un logiciel propriétaire gratuit plutôt qu'un payant, franchement, c'est presque kif kif, à la rigueur plus dangereux par ce que les gens sont moins conscients des contraintes.
[^] # Re: Adieu et merci pour le poisson
Posté par dcp . Évalué à 10.
L'open-source c'est des individus, des sociétés, des associations. Ce n'est pas un bloc unique et uni. OSDL rémunere plusieurs développeurs pour un travail donné (qui n'a rien à voir avec du versionning), mais qui travaillent en parallèle sur des projets de versionning... D'ou une colère affichée de BitMover.
Mon analyse personnelle est que BitKeeper ne vend pas grand chose sur Linux/UNIX et que le support de cette plateforme était avant tout publicitaire : BitKeeper est utilisé par des centaines de développeurs répartis aux 4 coins de la planète pour un projet (célèbre) de plusieurs millions de lignes de code... Cela crédibilise un produit, sans parler d'une publicité énorme à peu de frais... Qui connaissait BitKeeper (et BitMover) avant que Linus décide de l'utiliser ?
D'autre part, Trolltech a-t-elle arrêté de distribuer Qt en GPL alors qu'une partie de la communauté développait Gtk ? MySQL AB rechigna-t-elle à distribuer sa base de données dès lors que la communauté participe à d'autres produits (postgreSQL...) ? Non. Il se trouve que BitMover n'a pas le même business model que les deux sociétés sus-citées (support, formation, custom engineering), mais un modèle basé sur la vente de licences, ce qui est très honorable et ne me choque nullement.
Dès lors, la rupture était inévitable et prévisible (facile à postuler après l'évenement, il est vrai). Mais il serait fort étonnant que BitMover n'ait pas prévu cette rupture de longue date tout en sachant que la renommée, la crédibilité et la publicité de leur produit n'avait pas de meilleur chemin que celui la. Je pense donc qu'ils font beaucoup de cinéma et de simagrées pour un évenement, qu'ils avaient de toute manière prévu de déclencher.
Cordialement
[^] # Re: Adieu et merci pour le poisson
Posté par B. franck . Évalué à 7.
avec les sources.
<mode_parano>
imaginons qu'il insère du code sans le notifier
</mode_parano>
de toute façon on a toujours le droit de faire du reverse à des fins d'opérabilité. (pour combien de temps, ça c'est une question de référendum hors sujet ici)
Et ils devraient plutôt être heureux qu'on les ai prévenu pour qu'il change leur business-plan.
[^] # Re: Adieu et merci pour le poisson
Posté par pasBill pasGates . Évalué à 4.
On te donne qqe chose en echange d'une promesse de ta part, tu tiens pas la promesse, ben on te reprend ce qqe chose, tout ce qu'il y a de plus normal.
[^] # Re: Adieu et merci pour le poisson
Posté par boubou (site web personnel) . Évalué à 3.
C'est tout aussi normal que de punir une classe entière parce qu'un élève parle ou de faire faire 50 pompes à une section parce qu'elle contient un tire au flanc. Le problème n'est pas d'annuler la licence du mec qui fait du reverse (c'est même logique), mais plutôt de supprimer la version gratuite pour tout le monde, alors qu'un mec fait du reverse.
[^] # Re: Adieu et merci pour le poisson
Posté par pasBill pasGates . Évalué à 1.
Resultat, ca donne evidemment pas envie a BitMover d'aider ce genre de communaute, il y a certainement des gens qui vont payer pour les autres, mais au final je dirais plutot que l'attitude generale de la communaute(et pas uniquement sur ce cas precis) a donne ce resultat. A vouloir cloner tout ce qu'on touche, on finit par ne plus rien recevoir gratuitement.
[^] # Re: Adieu et merci pour le poisson
Posté par Emmanuel Seyman . Évalué à 4.
Je vais te demander un lien vers les stats que tu as établi.
Tous les commentaires que j'ai lu jusqu'a présent condamnent McVoy d'avoir puni tous les utilisateurs de cette version de son logiciel pour les actions d'une personne et Linux pour avoir utilisé un logiciel propriétaire alors qu'on l'a prévenu maintes et maintes fois du danger que cela impliquait.
Les seuls commentaires que j'ai lu sur le responsable s'intérrogeait sur la légalité de ses actions sans pouvoir donner de réponses (on n'a pas assez d'infos).
[^] # Re: Adieu et merci pour le poisson
Posté par pasBill pasGates . Évalué à 3.
C'est justement ce que j'ai vu aussi, bcp se demandaient si c'etait legal ou pas, mais peu ont condamne l'acte d'un point de vue morale.
Perso, je suis pas du tout sur que ce soit illegal, par contre je trouve ca tres deplace d'un point de vue morale.
[^] # Condamnations morales
Posté par Pierre Thierry . Évalué à 0.
Pour moi, ce qui est condamnable moralement, c'est la clause interdisant le reverse-engineering. A noter que dans tout endroit où des lois protègeraient l'interopérabilité, cette clause serait illégale.
Ne pas respecter des clauses abusives d'un contrat, c'est une liberté essentielle.
[^] # Re: Adieu et merci pour le poisson
Posté par Éric (site web personnel) . Évalué à 4.
Pas possible, je dois me tromper de site là.
[^] # Re: Adieu et merci pour le poisson
Posté par pasBill pasGates . Évalué à -1.
[^] # Re: Adieu et merci pour le poisson
Posté par briaeros007 . Évalué à 3.
Alors ensuite ca va etre le respect des developpeurs (ce que je comprend par ailleurs ), puis le respect de la boite; etc... on s'en sort pas.
[^] # Re: Adieu et merci pour le poisson
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: Adieu et merci pour le poisson
Posté par briaeros007 . Évalué à 2.
Je veux dire je comprend tres bien ton raisonnement ; mais ca reste
1° tres proche d'un proces d'intention je trouve.
2° je vois pas trop en quoi le fait de payer une licence donne plus de droit moralement a developper un soft "concurrent" parce que la licence est une goutte "infime" dans le cout reel du soft (et on s'est arrete au reverse engeenering donc le soft "concurrent" on en est loin)
[^] # Re: Adieu et merci pour le poisson
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: Adieu et merci pour le poisson
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Adieu et merci pour le poisson
Posté par boubou (site web personnel) . Évalué à 2.
Moi le premier. Protocole fermé = mal. Ca n'a aucun rapport avec le clonage, c'est une question de principe. Ceci étant, ça reste une punition collective.
[^] # Re: Adieu et merci pour le poisson
Posté par Emmanuel Seyman . Évalué à 2.
Je ne suis pas sur que ca soit une tres représentation des choses.
Ici, UN developpeur libre a violé la licence (admettons que la clause en question soit légale) et c'est TOUS les clients qui sont punis, même ceux qui ont respectés la licence.
Larry McVoy compare la situation aux Marines américains. Dans les Marines, si quelqu'un fait une connerie, c'est tout le groupe (peu importe qui a commis la faute) qui est puni.
[^] # Re: Adieu et merci pour le poisson
Posté par boubou (site web personnel) . Évalué à -3.
Larry McVoy est donc un sale con. Ca ne m'étonne pas plus que ça, mais au moins on en a maintenant une preuve. J'espère sincèrement que sa boite va couler.
[^] # Re: Adieu et merci pour le poisson
Posté par Littleboy . Évalué à 1.
Personne a rien payé pour la version gratuite que je sache!
[^] # Re: Adieu et merci pour le poisson
Posté par modr123 . Évalué à 2.
tout devellopeur de arch/svn/subversion ne pouvait donc pa l'utiliser gratuitement
[^] # Re: Adieu et merci pour le poisson
Posté par ookaze . Évalué à 8.
Ce qui contredit la raison qu'il a évoqué pour arrêter le dév de la version gratuite, puisque je suis sûr que les personnes qui faisaient du reverse-engineering sur BK n'avaient pas l'intention d'implémenter une version Windows ou pour autre chose que le kernel.
En tout casn je suis sûr que c'était pas fait pour couler BK.
Pour moi, la position de BM reste logique, mais aussi incompréhensible si l'on met en jeu seulement les principes et la morale (comme c'est ce qui est mis en avant par L. Mc Voy).
Si je met les profits en jeu, tout de suite, ça devient plus compréhensible. En somme, je soupçonne une forte dose d'hypocrisie.
[^] # Re: Adieu et merci pour le poisson
Posté par pasBill pasGates . Évalué à 0.
Tu en es sur ? Tu en sais quoi ? Parce que les gars qui ont fait ca ils avaient probablement en tete de sortir un soft en GPL qui ferait ce que tu mentionnes, resultat 1 semaine plus tard qq'un prendra ce code et l'adaptera.
Pour moi, la position de BM reste logique, mais aussi incompréhensible si l'on met en jeu seulement les principes et la morale (comme c'est ce qui est mis en avant par L. Mc Voy).
Si je met les profits en jeu, tout de suite, ça devient plus compréhensible. En somme, je soupçonne une forte dose d'hypocrisie.
Moi je trouve que le probleme moral il se pose, mais plutot du cote des devs du libre.
BitMover a paye des salaires, la location d'un immeuble,... pour donner a ces devs un soft gratuit, et en retour ces devs lui plantent un couteau dans le dos qui risque de faire baisser ses revenus, sympa comme remerciement.
[^] # Re: Adieu et merci pour le poisson
Posté par briaeros007 . Évalué à 2.
on a dis un dev deja...
"BitMover a paye des salaires, la location d'un immeuble,... pour donner a ces devs un soft gratuit, "
Pas que pour ca ; il fait aussi payer certaines de ses versions...
on peux considerer aussi que le fait de leurs passer l'outil gratuit n'etait qu'un coup de pub car de toutes facons ils ne l'auraient pas acheter ; donc autant qu'ils utilisent mon soft ; comme c'est un gros groupe d'expert qui est "mediatise" (dans leurs milieu) si ils utilisent mon soft ca se sait .
Et donc le retour sur investissemnt il est peut etre deja fait..
chacun vois le cote qui l'arrange...
[^] # Re: Adieu et merci pour le poisson
Posté par boubou (site web personnel) . Évalué à 8.
# bel exemple...
Posté par SkizoRutabaga . Évalué à 10.
"J'vous l'avais dit !"
[^] # Re: bel exemple...
Posté par Security__Watch . Évalué à 10.
[^] # Re: bel exemple...
Posté par patrick_g (site web personnel) . Évalué à 10.
Voir même visionnaire....
Larry McVoy a toujours été très belliqueux envers RMS et les soit-disant intégristes du libre lors des flame-war sur la LKML. Maintenant on a la preuve que l'utilisation d'un logiciel propriétaire est dangereuse pour la communauté du libre : il est probable que le dev du kenel va être perturbé ces prochains mois.
C'est RMS qui aura eu raison en disant dès le début que BK était peut- être le best tool mais qu'a long terme l'utilisation d'un logiciel non libre est dommageable.
j'ai toujours trouvé les arguments de McVoy discutables : c'était en gros "vous avez le droit d'utiliser mon soft mais pas pour développer un logiciel du même type qui sera un concurrent pour moi et ma boite".
BORDEL mais on est ou là ? Vous imaginez Renault disant "vous avez le droit de conduire une Renault sauf si vous voulez vous rendre dans une usine citroën" ?
[^] # Re: bel exemple...
Posté par dco . Évalué à -2.
[^] # Re: bel exemple...
Posté par Marc (site web personnel) . Évalué à 10.
Le 2ème, c'est que quand tu reposes sur un soft proprio et qu'un jour, l'éditeur passe ce logiciel à la trappe, tu va passer du temps à chercher autre chose etc etc parceque tu n'as plus accès au soft...
[^] # Re: bel exemple...
Posté par Guillaume Thomassin . Évalué à 5.
[^] # Re: bel exemple...
Posté par kesako . Évalué à 8.
avec du proprio qui disparait, les fonctions d'export sont soit inexistantes soit minimales ou minimalistes. Donc on perd tout : le soft et le travail fait avec le soft.
[^] # Re: bel exemple...
Posté par Marc (site web personnel) . Évalué à 4.
sans avoir le droit ni la possibilité de corriger les bugs trouvés plus tard... Je trouve pas ça super, et je considère vraiment que c'est un problème. Image qu'on tombe sur une autre limitation du genre du nombre limités de changement? On a l'air bien con
[^] # Re: bel exemple...
Posté par applex . Évalué à 1.
[^] # Re: bel exemple...
Posté par Guillaume Knispel . Évalué à 8.
Concretement que ce qui va se passer ? A long terme on peut raisonnablement supposer une migration. A cours terme des ennuis sont potentiellements envisageable si jamais les anciennes versions gratuites se mettent à merder (et vu la mentalité de BM on ne peut pas négliger cette hypothèse).
Cette histoire montre que Linus a clairement sous estimé les problèmes potentiels qui étaient pourtant connus depuis le début et d'une probabilité même assez grande quand on connait la mentalité des propriotaristes de BM. Parce que laissé une composante majeure du process de devel de Linux entre les mains de gens qui n'aiment pas l'interroperabilité au point de faire des coups d'éclat comme ca, on peut quand meme pas prétendre qu'on est pas conscient des risques. Ou alors c'est clairement de l'aveuglement.
[^] # Re: bel exemple...
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
A mon avis non. Si Torvalds n'avait pas migré vers BitKeeper, il y a pas mal de gens qui seraient restés a CVS sans se poser de questions. Le coup de pied dans la fourmilière a permis de montrer qu'on pouvait faire mieux, et du coup, des alternatives intéressantes se développent.
Résultat, d'ici quelques mois, il aura quelque chose de comparable a BitKeeper en open-source. Ça n'aurait probablement pas été le cas autrement.
[^] # Re: bel exemple...
Posté par jeanmarc . Évalué à 4.
Devant la pression de voir le kernel développé en utilisant un outil propriétaire, beaucoup de développeurs auraient été trés motivés pour offrir une version libre équivalente.
Ton argument du passage vers le propriétaire pour booster le développement du libre est faux et dangereux je trouve.
Les projets qui ont essayé de rattraper bitkeeper auront une forte exposition maintenant mais uniquement parce que bitmover a décidé de laisser tomber la communauté.
Penses-tu que le logicel libre a besoin d'introduire le loup dans la bergerie pour avancer?
Je ne pense pas du tout que ça soit la bonne solution et, bien heureusement, beaucoup d'adhérents à la philosophie du libre on la patience d'attendre que certaines fonctionnalités apparaissent dans les logiciels libres plutôt que de céder à la facilité du logiciel propriétaire bardé de fonctionnalités souvent inutiles.
[^] # Re: bel exemple...
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
> mêmes fonctionalités que bitkeeper au moment où il a décidé de l'adopter, tu
> ne penses pas qu'il y aurait des solutions beaucoup plus évoluées à l'heure actuelle?
C'est un peu ce qu'il s'est passé, non ? Arch est né avec comme objectif affiché de remplacer BK pour le kernel par exemple. Linus dit dans son mail: « I sure had hoped that it would have happened only once there was a reasonable open-source alternative. », ce qui veut bien dire qu'il aurait migré vers une solution open-source si elle avait été a la hauteur.
La licence de BitKeeper fait ch**r, tout le monde préfère que Linux utilise autre chose. En attendant, je suis bien content d'avoir un noyau Linux qui marche bien avec un développement actif et rapide. C'est en partie grace a BK, on ne peut pas le nier.
[^] # Re: bel exemple...
Posté par boubou (site web personnel) . Évalué à 3.
Ouai, mais Linus a vraiment été très arrogant sur ce coup. Monsieur Linus ne voulait pas des outils que des milliers de développeurs dans le monde utilisaient avant lui et il a préféré prendre un risque assez important pour satisfaire son égo. Des projets aussi gros que Linux, comme KDE ou Gnome fonctionnent très biens et sont très actifs, et ceci sans BK.
En attendant, je suis bien content d'avoir un noyau Linux qui marche bien avec un développement actif et rapide. C'est en partie grace a BK, on ne peut pas le nier.
Si, je peux. Rien ne permet de prouver que l'accélération de l'inclusion des nouveautés dans le noyau est due à BK. Elle est certainement du à la modification du processus de développement, mais BK n'est qu'une partie de cette modification. Il y a aussi les changements d'équipe, l'absence de noyau 2.7, etc. Peut être que tout se serait passé aussi vite avec un autre gestionnaire de versions.
[^] # Re: bel exemple...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Linus arrogant ? C'est un pléonasme ;-)
> Rien ne permet de prouver que l'accélération de l'inclusion des nouveautés dans le noyau est due à BK.
Je pense que Linus est bien mieux placé que nous deux pour en juger, et il est plus que clair là dessus.
> l'absence de noyau 2.7, etc.
L'abscence de noyau 2.7, elle est due a la possibilité de tester les patchs dans des branches différentes avant inclusion dans la mainline. Tu te vois sérieusement faire ça avec CVS ?
[^] # Re: bel exemple...
Posté par boubou (site web personnel) . Évalué à 2.
Je me suis mal exprimé. Ce que je voulais dire, c'est que rien ne permet d'affirmer que l'utilisation d'un autre outil n'aurait pas permis une accélération aussi grande que celle de BK. Je ne nie pas l'accélération induite par BK.
[^] # Re: bel exemple...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: bel exemple...
Posté par boubou (site web personnel) . Évalué à 3.
De toute manière, le point fondamental est que le seul fait relativement incontestable est que le développement du noyau semble plus rapide en ce moment (et à mon avis depuis le début du 2.6). Les causes sont au minimum obscures et il est impossible de savoir ce qui se serait passé si Linus n'avait pas choisi BK. On peut argumenter pendant des heures, on ne saura jamais. Alors on peut avoir une attitude "positive" et dire que l'expérience a été super positive et tout et tout. Mais de la à parer BK de vertues extraordinaires, il y a un pas que je refuse de faire.
[^] # Re: bel exemple...
Posté par reno . Évalué à 2.
D'abord, chaque projet a ses spécificité, ensuite KDE est en train de migrer de CVS a Subversion, donc apparemment ils ne doivent pas être si satisfait que ça de CVS..
Quel était l'état de Subversion, il y a 3 ans quand Linus est passé a bitkeeper?
Il était peut-etre possible de changer le style de developpement en gardant CVS, mais avec des si on ne va pas bien loin..
[^] # Re: bel exemple...
Posté par pasBill pasGates . Évalué à 3.
BORDEL mais on est ou là ? Vous imaginez Renault disant "vous avez le droit de conduire une Renault sauf si vous voulez vous rendre dans une usine citroën" ?
A une difference pres: cette limitation n'est valable que pour la licence gratuite, tu crois que Renault transporterait gratuitement les employes de Citroen pour qu'ils se rendent a leur travail ?
[^] # Re: bel exemple...
Posté par boubou (site web personnel) . Évalué à 0.
Est-ce vrai ? Il me semble que McVoy pratique la culture du secret, en particulier pour les prix de son soft, et j'aimerais bien savoir si la licence commerciale du soft est disponible quelque part, et, le cas échéant, si elle n'interdit pas le développement de softs concurrents...
[^] # Re: bel exemple...
Posté par boubou (site web personnel) . Évalué à 3.
[^] # Re: bel exemple...
Posté par pasBill pasGates . Évalué à 1.
Rien dans la licence commerciale ne l'interdit.
[^] # Re: bel exemple...
Posté par Marc (site web personnel) . Évalué à 3.
http://www.bitmover.com/cgi-bin/license.cgi(...) :
"(ii) reverse engineer, translate, port, clone, decom-
pile, or disassemble the Software or otherwise reduce the Software to a form
understandable by humans, except to the extent this restriction is expressly
prohibited by applicable law notwithstanding this limitation;"
[^] # Re: bel exemple...
Posté par pasBill pasGates . Évalué à 2.
[^] # Re: bel exemple...
Posté par boubou (site web personnel) . Évalué à 4.
[^] # Re: bel exemple...
Posté par Marc (site web personnel) . Évalué à 1.
[^] # Re: bel exemple...
Posté par pasBill pasGates . Évalué à 1.
Arch / Subversion / ... ne sont pas des clones de BitKeeper, pourtant ils font le meme genre de boulot.
[^] # Re: bel exemple...
Posté par Zenitram (site web personnel) . Évalué à 3.
Et?
Ce n'est pas une difference, c'est juste le business-model de BitMover pour se faire connaitre.
Gratuit ou pas, la licence est la, et c'est la licence qui compte.
PS : le sujet n'est pas la, celui-la est un vieux troll :)
[^] # Re: bel exemple...
Posté par gc (site web personnel) . Évalué à 4.
Tu es de mauvaise foi. L'analogie correcte est Renault disant "je vous donne ou prête gratuitement une Renault mais vous ne vous rendez pas dans une usine Citroën avec". Ben désolé mais je trouve ça compréhensible. Tu aides quelqu'un et tu lui demandes de ne pas te niquer par derrière.
[^] # Re: bel exemple...
Posté par Marc (site web personnel) . Évalué à 2.
[^] # Re: bel exemple...
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: bel exemple...
Posté par VoixOff . Évalué à 2.
Je sais, -->[ ]
[^] # Re: bel exemple...
Posté par Croconux . Évalué à 1.
Ce serait plutot : "Je vous prête une Renault gratuitement mais si vous l'acceptez, il vous sera interdit à vie de travailler pour un autre constructeur automobile".
Désolé mais c'est largement excessif. Les constructeurs automobiles essaient les voitures des concurrents pour voir ce qu'elles valent et je trouve ça normal. Un employé de Citroen peut très bien se faire passer pour un acheteur potentiel, aller dans une concessions Renault et demander à essayer une voiture. Dans la plupart des domaines, on teste ses concurrents pour voir comment on se situe par rapport à eux. Il n'y a que dans l'informatique qu'on arrive à imposer des limitations de ce genre.
[^] # Re: bel exemple...
Posté par pasBill pasGates . Évalué à 1.
Tu vois ou que BitMover interdit a vie de travailler sur un soft concurrent ?
[^] # Re: bel exemple...
Posté par bmc . Évalué à 4.
J'avoue que parfois tu es un poil agaçant, mais souvent très pertinent et en général bien argumenté / documenté.
Sinon, le logiciel propriétaire ça suxor des ours en rut.
[^] # Re: bel exemple...
Posté par Emmanuel Seyman . Évalué à 2.
C'est une interprétation très populaire de la licence de BitKeeper dont même Larry McVoy a admis qu'elle était possible d'un point de vue juridique. J'ai cru comprendre qu'il avait prévu de modifier la licence dans un futur proche pour lever l'ambuiguité.
[^] # Re: bel exemple...
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: bel exemple...
Posté par Emmanuel Seyman . Évalué à 2.
Je ne vois pas en quoi ta perception de la légalite d'une clause d'un contrat te dispense de la respecter. Il faudra que tu m'expliques...
Pour que ca soit illégale, il faut que quelqu'un porte plainte et qu'un juge déclare la cause comme étant abusive. Les kernel hackers ayant d'autres chats a fouetter, ce n'est pas près d'arriver.
J'ai enfin retrouvé le post de McVoy sur la ml kernel ou il présente les modifications qu'il vaut apporter a la licence de BitKeeper. Son intention était bien d'interdire aux gens de travailler sur un concurrent mais de réduire l'intervalle de temps a un an.
Je te laisse deviner les réactions. Comme toi, beaucoup de gens s'interrogent sur la légalité d'une telle clause.
http://marc.theaimsgroup.com/?l=linux-kernel&m=110834709016000&(...)
[^] # Re: bel exemple...
Posté par Éric (site web personnel) . Évalué à 4.
> juge déclare la cause comme étant abusive.
Je ne connais pas à ce point le juridique mais quelque chose est légal ou n'est pas légal. Si ça n'est pas légal ça n'est pas légal, pas besoin de passer devant le juge. Le juge ne fait que constater et trancher le désaccord (ou éventuellement punir si besoin), ce n'est pas lui qui rend illégal quelque chose, ça l'était (éventuellement) déjà avant.
[^] # Re: bel exemple...
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: bel exemple...
Posté par briaeros007 . Évalué à 2.
Enfin il y a des clauses qui peuvent etre "manifestement illegales"
Exemple:"Ce logiciel vous oblige a un sacrifice humain a chaque utilisation..."
[^] # Re: bel exemple...
Posté par Sylvain Sauvage . Évalué à 2.
Oh, ho...
[^] # Re: bel exemple...
Posté par dco . Évalué à -1.
[^] # Re: bel exemple...
Posté par Khâpin (site web personnel) . Évalué à 10.
Ça va donner doublement raison à RMS: Linux va relentir son développement pendant la phase de recherche et transition vers un au Versionning System. Et du coup, Linux va se faire doubler par ... Hurd!
[c'est au fond à droite? bon, d'accord!]
[^] # Re: bel exemple...
Posté par B. franck . Évalué à 0.
# Avocat du diable mais bon...
Posté par dco . Évalué à 4.
Pas d'accord, rendons à cesar ce qui lui appartient : la réaction est sans doute exagérée mais le problème n'a rien à voir avec libre/propriétaire. Si l'utilisation de la version gratuite interdisait l'ingénierie inverse et que ce point ait été clairement spécifié dans la licence, personne ne peut leur reprocher ce cesser la distribution si cette condition était violée par un qqn de l'OSDL...
On peut pas reprocher aux boites de logiciels propriétaires de s'assoir sur la GPL si le respect n'est pas mutuel.
Par contre, un concilliation aurait pu aboutir à une solution moins abrupte que simplement un arrêt du dev...
[^] # Re: Avocat du diable mais bon...
Posté par Hardy Damien . Évalué à 10.
Dam
[^] # Re: Avocat du diable mais bon...
Posté par Sam Hocevar (site web personnel) . Évalué à 9.
C’est le droit à la décompilation qui n’est pas révocable par contrat (article L122-6-1.IV). En revanche ce dernier est limité aux fins d’interopérabilité et il n’est pas permis de communiquer les informations obtenues à des tiers, sauf nécessité avérée, par exemple -- là j’interprète -- quand c’est dans le code source et qu’on est obligé de faire de l’opensource (ça tombe bien, tiens !).
[^] # Re: Avocat du diable mais bon...
Posté par Stéphane Salès . Évalué à 2.
Et par défaut qu'est ce qui s'applique ? (ie: si le contrat ne précise rien)
[^] # Re: Avocat du diable mais bon...
Posté par Sam Hocevar (site web personnel) . Évalué à 2.
[^] # Re: Avocat du diable mais bon...
Posté par romain . Évalué à 7.
L'ingénierie inverse est et reste légale en Europe, de façon générale (pour le moment) ; seule façon de lutter contre : la boîte noire scellée.
[^] # Re: Avocat du diable mais bon...
Posté par Sam Hocevar (site web personnel) . Évalué à 6.
Je t’invite à relire cet article, alors :
La personne ayant le droit d'utiliser le logiciel, peut sans l'autorisation de l'auteur observer, étudier ou tester le bon fonctionnement de ce logiciel afin de déterminer les idées et les principes qui sont à la base de n'importe quel élément du logiciel, lorsqu'elle effectue toute opération de chargement, d'affichage, d'exécution, de transmission ou de stockage du logiciel qu'elle est en droit d'effectuer.
Rien à voir avec les modifications apportées à un logiciel précis, je ne vois pas où tu vas chercher ça. Le « déterminer les idées et les principes qui sont à la base [...] du logiciel », c’est exactement ce qu’est l’ingénierie inverse.
[^] # Re: Avocat du diable mais bon...
Posté par Security__Watch . Évalué à 1.
McVoy n'a qu'à faire un procès au développeur en question pour violation de licence/contrat, ca marche du tonnerre, c'est ce que fait la FSF.
[^] # Re: Avocat du diable mais bon...
Posté par dco . Évalué à -2.
[^] # Re: Avocat du diable mais bon...
Posté par kesako . Évalué à 5.
[^] # Re: Avocat du diable mais bon...
Posté par Jiel (site web personnel) . Évalué à 8.
Ce n'est pas une punition mais un enseignement pour la communauté: n'utilisez pas un logiciel sous une licence pas conviviale, même s'il est performant, ca se retournera contre vous. D'ailleurs, plusieurs voix de la communauté s'étaient élevées contre ce choix de BitKeeper.
[^] # Re: Avocat du diable mais bon...
Posté par boubou (site web personnel) . Évalué à 9.
Bien sûr que si. La licence peut être révoquée pour le fautif. Ici, il s'agit d'une "punition" collective (pour quelque chose qui est légal dans de nombreux pays) pour la faute d'un individu (ou de quelques individus). Et c'est parfaitement lié au caractère propriétaire du logiciel.
En tout cas, cela me fera bien plaisir de voir que ce logiciel propriétaire dans toute sa splendeur (avec une licence illégale dans certains pays, avec tous les problèmes de formats fermés, de licences discriminatoires, etc.) ne va plus être associé au développement de Linux.
# avant de troller
Posté par gaaaaaAab . Évalué à 1.
je trouve que Larry McVoy est quand même de super bonne volonté. Dans une logique propriétaire, il peut difficilement faire mieux. Et il respecte suffisament les développeurs pour pas leur planter un couteau dans le dos.
Je suis quand même bien content de voir une évolution vers un outil libre à définir.
[^] # Re: avant de troller
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Je passe sur sa confusion propriétaire/commercial et son côté « je suis votre meilleur ami ».
[^] # Re: avant de troller
Posté par gaaaaaAab . Évalué à 3.
RMS rulez ! :)
# Tant mieux !
Posté par Foxy (site web personnel) . Évalué à 8.
L'équipe de développement du kernel va être un peu embétée pendant un moment car certains développeurs vont devoir se passer du client BitKeeper non commercial.
Mais on peut espérer que le développement du Linux kernel passe sur un système de gestion de version libre et open-source : Subversion et Arch sont tout à fait à même d'être utilisé pour remplacer BK (même s'ils manquant encore des fonctionnalités). D'ailleurs certains devs comme Andrea Archangeli utilise déjà des passerelles BK - CVS - Subversion pour leur dev et s'en sortent très bien.
Cela permettra aussi que d'autres projets open-source suivent cette voie car à l'heure actuelle, difficile de faire bouger les gens pour ne plus utiliser l'antique CVS.
[^] # Re: Tant mieux !
Posté par Christophe Lucas (site web personnel) . Évalué à 2.
Sur le fond je suis tout à fait d'accord avec toi. Ce sera flou un moment, mais bon ils y arrivaient avant, il y arriveront bien un moment le temps de trouver ou développer un autre logiciel de versionning.
L'équipe de développement du kernel va être un peu embétée pendant un moment car certains développeurs vont devoir se passer du client BitKeeper non commercial.
Mais on peut espérer que le développement du Linux kernel passe sur un système de gestion de version libre et open-source : Subversion et Arch sont tout à fait à même d'être utilisé pour remplacer BK (même s'ils manquant encore des fonctionnalités). D'ailleurs certains devs comme Andrea Archangeli utilise déjà des passerelles BK - CVS - Subversion pour leur dev et s'en sortent très bien.
En revanche, je n'ai aucune idée des performances de logiciels tels Subversion , Arch sur 311Mo de sources. Alors de là à affirmer que ces logiciels s'en sortiront tout autant que Bitkeeper ... Je te laisse l'affirmer.
Cela permettra aussi que d'autres projets open-source suivent cette voie car à l'heure actuelle, difficile de faire bouger les gens pour ne plus utiliser l'antique CVS.
Alors là je suis tout à fait d'accord.
[^] # Re: Tant mieux !
Posté par let antibarbie = xp <- xp - 1 . Évalué à 4.
Il se pose aussi le problème si N développeurs développent des modifications concurrentes, alors N-1 de ces développeurs sont obligés de se synchroniser avec la version courante pour pouvoir soumettre leurs modifications, ils perdent alors la version actuelle sur laquelle ils étaient en train de travailler..
De plus il y a d'autre points subtils sur la gestion des changements, on doit pouvoir travailler sur une version en excluant certains "patchs" de l'arbre sur lequel on travaille, ce qui permet d'éviter que quelqu'un casse tout l'arbre courant en ayant rendu des modifications bancales..
Bref c'est plein de possibilités.. Notez que c'est pas un post anti-subversion, j'essaye de faire passer mon équipe à subversion... même si bitkeeper serait top si on avait les moyens de le payer et de former tout le monde à son utilisation.
[^] # Re: Tant mieux !
Posté par un_brice (site web personnel) . Évalué à 6.
[^] # Re: Tant mieux !
Posté par farib . Évalué à 1.
[^] # Re: Tant mieux !
Posté par Romain Vinot . Évalué à 3.
Le commentaire suivant sur les méthodes de management de branche, etc est bien plus génant que les problèmes de performance amha.
[^] # Re: Tant mieux !
Posté par tgl . Évalué à 4.
Ça apparait très clairement dans les discussions actuelles sur LKML, et c'est aussi bien expliqués par les devs de Subversion eux-même :
http://subversion.tigris.org/subversion-linus.html(...)
[^] # Re: Tant mieux !
Posté par Christophe Lucas (site web personnel) . Évalué à 1.
Mais je citais cela :
Larry noted that Linus tried monotone, but a simple import of flat files without versioning information took 2 hours, far too slow.
C'est bien que les performances entre monotone & cie et Bitkeeper sur ce genre d'opérations et donc d'autres sont loin d'être les même (Ce qui rejoins mon précédent post disant que je n'étais pas vraiment sûr que : Subversion et Arch sont tout à fait à même d'être utilisé pour remplacer BK (même s'ils manquant encore des fonctionnalités)).
Maintenant, je souhaite fortement qu'un projet libre soit aussi performant et puisse prendre la relève de bitkeeper et aussi que cette histoire serve de leçons.
[^] # Re: Tant mieux !
Posté par or zax . Évalué à 2.
Une chose qu'il faut retenir est la gestion des branches auquel on ajoute la gestion des branches. Donc ce n'est pas la taille globale du projet qui influencera les performances mais surtout son organisation
La conséquence est que tu peux avoir une grande arborescence même de 1 Go pour carricaturer, mais qui dit une arborescence aussi grande dit projet complexe souvent découpé en projet plus simple de 100 Mo. Et là Arch permettra de réduire l'effort de traitement à la sous-branche concerné uniquement, tout en gérant la cohérence globale.
Personnellement je ne connais pas trop l'organisation de noyau pour le développement, mais si quelqu'un connait, qu'il fasse un test grandeur nature.
Sachant que la charge est au niveau de la machine client, à savoir nous pourrions être surpris.
Le pire que j'ai testé c'est jusqu'à 40 méga, et ça ne change rien pour Arch.
Je ne connais pas trop monotone, qu'elle sont ses caractéristiques par rapport à Arch ?
[^] # Re: Tant mieux !
Posté par or zax . Évalué à 0.
[^] # Re: Tant mieux !
Posté par SoWhat . Évalué à 0.
C'est currieux, j'avais cru comprendre qu'il y avait pas mal de soucis avec Subversion et que justement ils pensaient choisir BitKeeper ! J'avais lu ça il n'y a pas longtemps ici : http://rootprompt.org/article.php3?article=8524(...)
[^] # Re: Tant mieux !
Posté par Nicolas Schoonbroodt . Évalué à 2.
D'ailleurs, on en a parlé ici (entre autre) : http://linuxfr.org/~pitrou/17664.html#554517(...)
# Un test de maturité...
Posté par charlieecho . Évalué à 1.
Mais c'est un vrai test pour la communauté OpenSource :
- soit l'ingénierie inverse s'intensifie (par esprit de revanche), et qqn sort un produit compatible (même protocole) sous peu, qui prendra le pas sur BitKeeper
- soit on grandit un peu, et on abandonne l'ingénierie inverse pour passer à autre chose que BitKeeper.
Je présume que si la solution 1 est adoptée, il y aura des procès, etc.
Bref, il faut que la communauté "présente ses excuses" pour le développeur inélégant et ait un comportement digne ; sous peine de perdre tout crédit.
[^] # Re: Un test de maturité...
Posté par EmacsFR . Évalué à 10.
Sans ces reverse, on en serait toujours à nous demander comment lire un DVD sur nos plateformes, ...
Bref, ça n'a pas plus à la société éditrice, et ça se comprend, de là à dire que le gars de l'OSDL doit présenter des excuses pour ça, ...
[^] # Re: Un test de maturité...
Posté par thomas . Évalué à 4.
[^] # Re: Un test de maturité...
Posté par David Sporn (site web personnel) . Évalué à 0.
Quoi qu'il en soit, BitMover a légitimement le droit de réagir comme ça, tout comme un développeur de PearPC a décidé de faire valoir ses droits face à Maui-X (éditeur de Cherry OS qui aurait simplement pompé PearPC en le remaquillant à minima), et dans l'intervalle, interdit à cette société d'utiliser son code.
Cette affaire illustre bien, si ce n'était pas déjà fait, que le danger d'un logiciel non-libre n'est pas seulement l'impossibilité éventuelle d'obtenir les sources, mais aussi les licenses d'utilisations qui peuvent contrecarrer l'exercice des droits dont on dispose (législation autorisant le reverse-engineering par exemple, ou encore liberté de s'exprimer sur les performances ou la fiabilité -tests à l'appui-, etc...)
[^] # Re: Un test de maturité...
Posté par Tobu . Évalué à 3.
Le gars n'avait pas du tout tort de reverse-engineerer le protocole, parce qu'il fallait le faire tôt ou tard. La licence de Larry avait une clause de modification rétroactive de la licence et devenait de plus en plus parano, dans ces conditions il faut réaliser que les clauses contre le reverse-engineering sont illégales et s'y mettre. Larry a mis fin à cette escalade de sa license et on peut le remercier de cette décision qui mettra fin à ce qui a longtemps été considéré comme un troll.
Ce qui compte ce sont les données, plus que l'outil, et un outil qui limite l'accès à des données que l'on possède pourtant est franchement du coté obscur, client pseudo open-source ou pas.
# Revers pour Linus
Posté par jeanmarc . Évalué à 10.
Ce qu'il faut retenir dans cette histoire, c'est que c'est un énorme camouflet pour Linus.
Il a beau être tout ce qu'il est ça n'en reste pas moins un être humain.
Il n'a jamais caché qu'il s'intéressait principalement au logiciel plutôt qu'à la philosophie gravitant autour.
C'est pour celà qu'il est bon d'avoir Linus mais aussi un RMS à côté qui défend bec et ongle la philosophie parce que c'est ce qui est primordial dans le logiciel libre.
Les lignes de codes s'alignent et s'aligneront toujours tant qu'il y aura des gros doigts boudinés pour frapper sur les claviers. Ce qui peut changer, c'est la liberté qu'on pourra avoir d'utiliser ce que l'on programme.
Si on extrapole, dans un monde où il faudra avoir un o'reilly de 320586 pages contenant toutes les pratiques couvertes par un brevet (bouquin remis à jour toutes les 2 semains avec des ajouts de 5000 pages à chaque fois) pour écrire un petit script shell, mieux vaudra garder ce qu'on programme pour soi ou le faire pour le compte d'une trés grosse société avec beaucoup d'avocats...
Tout ça pour dire que, plus important que son code, ce sont les idées de Linus qui sont les plus importantes. Il ne faut pas être aveuglé par sa notoriété pour contester ses idées.
Enormément de gens l'avaient averti concernant bitkeeper (dont RMS) en se basant sur l'aspect idéologique et il était resté insensible à toute discussion comme n'importe quel humain peut l'être en voulant rester fidèle à SA philosophie: le code d'abord.
J'espère que cette claque inévitable (McVoy n'est pas un mec trés soft et on le voit venir de trés loin) fera réfléchir Linus et lui montrera qu'en ne faisant pas attention à la philosophie, il peut à lui tout seul emmener le kernel dans des directions dangereuses.
La communauté doit se rappeler que sa force vient d'abord de ses idées et de son envie de liberté, pas de quelques individus qui lui dicterait le chemin à prendre.
On peut penser à MDI et son mono qui est encore un bel exemple à ne pas suivre.
Pour résumer ma pensée et ne pas attirer les commentaires basiques parlant d'intaigrisme, ce que je souligne ici, c'est l'importance de la philosophie sans tomber dans un excés néfaste et l'utilisation de ce que le monde du libre permet: la réflexion et le remise en question perpétuelle.
[^] # Re: Revers pour Linus
Posté par boubou (site web personnel) . Évalué à 2.
Absolument ! Et ça montre qu'il faut aussi se méfier des McVoy (a.k.a. "mais si, les mecs, j'aime l'open source, vous êtes mes amis'). Retrospectivement, KDE a bien eu de la chance avec Trolltech.
On peut penser à MDI et son mono qui est encore un bel exemple à ne pas suivre.
Là, par contre, je ne vois pas le rapport, excepté l'aspect faire confiance à des tiers. Je pense qu'on peut faire autant confiance à McVoy qu'à Microsoft (lire pas du tout), mais la situation est quand même radicalement différente. Quand il n'y aura plus de BitTruc gratuit, les sources du noyau ne changeront pas de nature. Par contre, si Mono devient un jour illégal (ce qui est du domaine du possible), le code construit autour sera bon pour la poubelle car aucune implémentation libre de .NET de sera possible...
Tu ne risques rien pour intaigrisme ;-)
[^] # Re: Revers pour Linus
Posté par _ . Évalué à 2.
Ils avaient quand même pris leurs précautions en commençant à dévélopper une alternative libre de QT à côté. Et ils ont tjrs été conscients du problème et ont, ils n'ont pas fermé les yeux.
[^] # Re: Revers pour Linus
Posté par Matthieu Moy (site web personnel) . Évalué à -1.
Qt est GPL. Si trolltech déconne, il y a un fork dans les 5 minutes.
Par ailleurs, il y a un accord plus ou moins formel entre KDE et Trolltech, j'ai plus l'URL en tête, mais en gros, si Trolltech arrête la version GPL, les versions disponibles passent carrément en BDS.
[^] # Re: Revers pour Linus
Posté par boubou (site web personnel) . Évalué à 5.
Tu sais, dans mon message, il y avait écrit Rétrospectivement ;-) Qt n'était pas GPL au début de KDE. En fait, c'était un logiciel commercial standard, mais avec une exception pour le développement de logiciels libres. Puis c'est devenu libre. Donc, rétrospectivement, KDE a eu de la chance de ne pas tomber sur un McVoy de plus.
[^] # Re: Revers pour Linus
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # Re: Revers pour Linus
Posté par Croconux . Évalué à 2.
Mouais, on ne peut pas comparer la licence originale de QT avec celle de BitKeeper. La licence de QT était "presque" libre. La version gratuite de QT était librement redistribuable ainsi que les sources. Seule contrainte : Il était interdit de redistribuer des versions modifiées mais on pouvait redistribuer ses modifications sous forme de patch par rapport aux source officielles. C'était juste un moyen de garder le contrôle sur leur bébé et d'éviter les forks sauvages dans la nature.
[^] # Re: Revers pour Linus
Posté par boubou (site web personnel) . Évalué à 2.
Soit. Mais tu as vu l'état de qmail actuellement ? qmail est aussi presque libre, exactement comme l'était qt. Et c'est peu à peu devenu une bouse. Ca ne compile pas sous un linux récent, ça n'a aucune de fonctionnalités avancées de postfix (par exemple), etc. Le seul moyen d'utiliser ce vénérable logiciel, c'est de le patcher à mort, et franchement, c'est tellement chiant que j'ai bien l'impression que les nouveaux convertis sont peu nombreux...
[^] # qmail toujours bien
Posté par Olivier Jeannet . Évalué à 1.
C'est faux (encore actuellement sur un kernel 2.6.8.1 base Debian).
ça n'a aucune de fonctionnalités avancées de postfix (par exemple)
Au contraire (avec les patchs) on peut en faire plus que postfix. Et c'est utilisé par plusieurs personnes de manière tout à fait professionnelle (pour des sociétés).
Le seul moyen d'utiliser ce vénérable logiciel, c'est de le patcher à mort
Certes, et il existe des packages prêts à l'emploi avec tous les patchs.
et franchement, c'est tellement chiant que j'ai bien l'impression que les nouveaux convertis sont peu nombreux...
C'est vrai que c'est TROP compliqué pour les nouveaux qui vont choisir postfix. En revanche quand on sait patcher/compiler, qmail est le plus puissant et riche en terme de fontionnalité et le plus secure.
[^] # Re: qmail toujours bien
Posté par briaeros007 . Évalué à 3.
sans partir sur un troll qmail /postfix
courier me semblait pas mal aussi
http://www.courier-mta.org/(...)
Perso j'ai commence par qmail (qui n'est pas particulierement complique a installer , meme patcher) puis j'ai essaye courier.
donc il y a de "nouveaux" utilisateurs meme si ce n'est qu'occasionnel ;)
[/HS]
[^] # Re: qmail toujours bien
Posté par boubou (site web personnel) . Évalué à 1.
Ouai, bien sûr (sur une Mandrake 10.1 avec le noyau 2.6.8.1) :
make setup check
...
./compile auto-str.c
auto-str.c:9: warning: conflicting types for built-in function 'puts'
auto-str.c: In function `main':
auto-str.c:17: warning: return type of 'main' is not `int'
./load auto-str substdio.a error.a str.a
substdio.a(substdo.o)(.text+0x47): In function `allwrite':
: undefined reference to `errno'
collect2: ld returned 1 exit status
make: *** [auto-str] Erreur 1
C'est sûr, ça marche super bien.
Au contraire (avec les patchs) on peut en faire plus que postfix.
Des exemples ?
Et c'est utilisé par plusieurs personnes de manière tout à fait professionnelle (pour des sociétés).
Trop puissant comme argument. Exchange aussi est utilisé de façon professionnelle pour des sociétés.
Certes, et il existe des packages prêts à l'emploi avec tous les patchs.
Si ces packages sont compilés, c'est illégal au sens de la pseudo licence de DJB.
C'est vrai que c'est TROP compliqué pour les nouveaux qui vont choisir postfix.
Mais les mecs qui en ont vont choisir qmail, c'est ça ? Tu sais, j'ai utilisé qmail entre la 1.0 et la 1.3, puis voilà, ça n'a plus été maintenu, alors tu vois...
En revanche quand on sait patcher/compiler, qmail est le plus puissant et riche en terme de fontionnalité et le plus secure.
Quel humour. En termes de fonctionnalités, aucun serveur SMTP n'atteind le niveau de sendmail, donc tu repasseras pour le plus puissant et le plus riche. Quant à la sécurité, le qmail de base est peut être assez sur (bien que certains ne soient pas d'accord, il y a en particulier des vulnérabilités au DOS qui n'ont jamais été corrigées), mais pour les versions patchées, permets moi de duoter fortement.
[^] # Re: Revers pour Linus
Posté par jeanmarc . Évalué à 1.
Tout à fait. Je disait ça dans le sens ou une partie de la communauté se laisse embarquer derrière un leader charismatique au risque de se retrouver bien dépourvu (du simple changement d'outil comme le noyau à la perte totale du projet comme pour mono).
C'est en celà que je compare les cas kernel/Linus et mono/MDI. Bien sûr, la comparaison s'arrête là entre Linus qui fait un travail extraordinaire sur le noyau même s'il se trompe quelque fois et MDI qui est un caractériel dangereux pour la communauté :)
Tu ne risques rien pour intaigrisme ;-)
Ouf, tu me rassures :) On a brulé tellement de gens ici sur le buché de l'intaigrisme que je préfère balancer des rappels ignifugeants en fin de post ;)
[^] # Re: Revers pour Linus
Posté par boubou (site web personnel) . Évalué à 1.
Euh, c'était juste une petite blague sur le fait qu'on écrit intégrisme, pas intaigrisme...
[^] # Re: Revers pour Linus
Posté par jeanmarc . Évalué à 2.
Tu ne devais pas encore trainer par ici à la grande époque des trolls velus mdk/debian, kde/gnome, slip/caleçon, grue/hameçon,...qui pullulaient sur linuxfr :)
C'est à cette époque qu'est né l'intaigrisme sur linuxfr pour se démarquer du vrai intégrisme qui saivit dans la vraie vie et qui fait vraiment mal.
Ben oui, ici on discute et même si ça chauffe, on ne peux pas encore faire exploser son LCD à la tête d'un mec qui raconte n'importe quoi sur linuxfr.
[^] # Re: Revers pour Linus
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: Revers pour Linus
Posté par jeanmarc . Évalué à 0.
lol
Ca doit être un problème de mémoire alors :)
Rassures-toi, tu n'as rien manqué. La période pendant laquelle il y avait des posts à 300 commentaires trollesques parce qu'on avait aperçu le pdg de mandrake faire la manche dans le métro ou qu'un programme java avait tourné plus d'1mn30 sans planter n'était pas des plus glorieuses.
J'avoue que je débarque ici aprés une trés longue période d'abstinence et à première vue, les choses se sont un peu calmées.
Maintenant, c'est plus du genre "c'est pas bien d'avoir espionné le programme du gentil McVoy qui aide tant Linus".
Par contre, pasbillpasgates est toujours là à débiter invariablement sa même rhétorique fondamentaliste. Je suis sûr que c'est un bot!
[^] # Re: Revers pour Linus
Posté par pasBill pasGates . Évalué à 1.
Ca me fait toujours autant marrer de voir des gens me traiter de fondamentaliste alors qu'ils ne sont pas foutus d'accepter qu'on ait un point de vue different du leur.
oeil, poutre, toussa...
[^] # Re: Revers pour Linus
Posté par jeanmarc . Évalué à 1.
J'vous dit que c'est un bot...
Je savais bien que tu allais rappliquer. Tu ne laisses jamais rien passer même une honey blague à 2 cts.
Tu n'as pas capté le ton léger de mon intervention?
Tu es une figure emblématique de linuxfr avec ton positionnement qui est clairement en contradiction avec le thème du site. Assumes un peu cette notoriété.
En fait, j'aurais dû te traiter d'intaigriste, tu aurais mieux accepté la blague peut-être...
Rhétorique fondamentaliste, ça ne veut pas dire grand chose comme ça (sauf ce que tu as bien voulu y voir...Quel mal y a-t-il à défendre ses idées? Tu as un problème avec ça?) mais ça fait plus sérieux, c'est vrai.
Bref, y'a pas de quoi fouetter un chat et tu ne fais que nous montrer ta rigidité.
Pourtant, tu devrais être plus zen vu ton positionnement...
[^] # Re: Revers pour Linus
Posté par pasBill pasGates . Évalué à 2.
Figure emblematique je sais pas, en contradiction, certaines fois oui, pas toujours, il y a juste qqe sujets "sensibles"...
Bref, y'a pas de quoi fouetter un chat et tu ne fais que nous montrer ta rigidité.
Les smileys ont ete inventes pour une bonne raison, je te laisse deviner laquelle...
[^] # Re: Revers pour Linus
Posté par jeanmarc . Évalué à 2.
Hum, je crois avoir trouvé. Ce n'est pas pour aider ceux qui ne savent pas déceler tout seuls le second degré dans une phrase?
[^] # Re: Revers pour Linus
Posté par Jean-Emmanuel LACÔTE . Évalué à 3.
Je sais où Brice de Nice trouve son inspiration maintenant...
[^] # Re: Revers pour Linus
Posté par Gniarf . Évalué à 3.
là, c'est juste le fournisseur d'un outil qui change les règles du jeu (ses conditions de vente), il va très certainement s'entendre répondre "oui mais non, au revoir !", le projet prendra au pire du retard le temps de changer de fournisseur et d'outil... et c'est tout.
Bitkeeper n'est pas plus critique ou indispensable qu'un éditeur de texte ou qu'un bête clavier. alors devoir considérer que je me prends une claque parce que le fabricant de clavier monte ses prix ou ne fait plus mon modèle préféré, ah ah ah, je rigole, et je prends un autre modèle ou une autre marque. et si j'en suis vraiment dépendant, c'est qu'il y a un problème.
[^] # Re: Revers pour Linus
Posté par Marc (site web personnel) . Évalué à 4.
[^] # Re: Revers pour Linus
Posté par Gniarf . Évalué à 3.
[^] # Re: Revers pour Linus
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Par contre, il y a pleins de bonnes idées qui se balladent sous différentes formes en matière de gestions de versions. En rassemblant un peu les forces, il y a moyen de faire quelque chose de très bon en open-source.
[^] # Re: Revers pour Linus
Posté par modr123 . Évalué à 0.
[^] # Re: Revers pour Linus
Posté par Yusei (Mastodon) . Évalué à 3.
Le seul problème potentiel avec Mono, c'est qu'il viole plein de brevets... et c'est le cas de plein de logiciels libres, y compris Linux. Le "bel exemple à ne pas suivre", c'est celui des brevets logiciels à l'américaine, et malheureusement on est train de le suivre.
# remplacement?
Posté par flyer . Évalué à -2.
[^] # Re: remplacement?
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
[^] # Re: remplacement?
Posté par Marc (site web personnel) . Évalué à 3.
https://www.linuxfr.org/comments/556237.html#556237(...)
Mais je ne sais pas si on peut écouter ce qu'il dit ou non =)
[^] # Re: remplacement?
Posté par bmc . Évalué à 5.
[^] # Re: remplacement?
Posté par FueL . Évalué à 3.
Utilisé pour le developpement de vim.
Et pourquoi faut-il un getsionnaire décentralisé pour le versionning du noyau ?
[^] # Re: remplacement?
Posté par Colin Leroy (site web personnel) . Évalué à 2.
Parce qu'il y a des centaines de contributeurs; la plupart des contributeurs importants sont spécialisés dans certains sous-systèmes, ils ont ainsi la possibilité d'avoir un noyau normal, sans souffrir des bugs bleeding-edge du sous-système d'à côté, tout en développant dans leur coin. Lorsqu'ils considèrent leur travail stable (merge-able dans l'arbre de Linus), Torvalds n'a qu'à "tirer" les patches de gauche et de droite.
# Réaction de Linus
Posté par Matthieu Moy (site web personnel) . Évalué à 9.
# Arrêtez moi
Posté par peco . Évalué à 0.
(Pas taper, je pose la question.)
[^] # Re: Arrêtez moi
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Ben justement, pas tous les autres.
Un des rôles de Torvalds, c'est d'animer une communauté autour du noyau. BitKeeper était déjà source de conflits avec la version gratuite, là, c'est la goute d'eau qui fait déborder le vase. La bourde, ça serait de continuer avec BK. Cf. son mail sur la lkml ou il explique ça très bien.
# Linus sur la LKML
Posté par Marc (site web personnel) . Évalué à 4.
# darcs?
Posté par bobefrei . Évalué à 4.
[^] # Re: darcs?
Posté par Tobu . Évalué à 2.
Cela dit si on accepte de liquider les historiques locaux et de se prendre quelques petits de conflits de renommage c'est une bonne solution.
[^] # Re: darcs?
Posté par Tobu . Évalué à 2.
http://zooko.com/revision_control_quick_ref.html(...) .
C'est un comparatif concis des différents SCM libres. A noter que linus s'est récemment mis à réécrire à partir de zéro quelque chose qui est l'équivalent de monotone - en particulier l'approche pool de hash.
# vote sur kerneltrap
Posté par wilk . Évalué à 2.
Si vous n'avez pas d'idée je vous conseille d'aller voir le petit dernier : http://bazaar-ng.org(...) ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.