Mais bien sûr. La phrase complète est But Microsoft (and our co-sponsors, Intel and Hewlett-Packard) went further and have agreed that our patents essential to implementing C# and CLI will be available on a "royalty-free and otherwise RAND" basis for this purpose.
Explique moi un instant pourquoi l'ingénieur de chez MS n'a pas utilisé le mot "and" seul ? Parce que ça ne veut rien dire ! On ne peut pas être à la fois royalty-free et RAND, sauf si on interprète RAND comme royalty-free, ce qui n'est évidemment pas le cas. La présence du otherwise est cruciale puisqu'elle montre qu'il y a justement une différence. Et on ne sait pas au final quels seront les critères de décision de MS pour le choix entre ces alternatives.
De plus, ce mail n'a AUCUNE valeur légale. Ne trouve tu pas étrange que le site web de MS qui contient de nombreux modèles d'accord de licence n'en propose aucun pour .NET ?
Enfin, obtenir une licence royalty-free ne signifie en aucun cas que tu pourras redistribuer une implémentation open source, comme je le démontre par des exemples de chez Microsoft dans le texte.
Oué mais justement j'ai pas trouvé, d'où ma demande.
Et bien va lire le brevet : http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HIT(...) (et c'est seulement un des brevets). Il est possible que certaines API ne soient pas couvertes, ceci dit. Dans une révision de mon article, je remplacerais toute l'API par une grande partie de l'API, ça sera plus prudent.
Evidemment que MS peut obtenir des brevets qui peuvent être "génant" pour Mono. Mais les APIs de MS n'innovent quasiment pas, alors soient d'autres plateformes seront impactés (autour des web services comme le laisse entendre une des tes sources), soient un prior-art sera démontré.
En effet, tout est possible dans le monde des Bisounours. Le problème est qu'il suffit de ne pas pouvoir implémenter UN appel de méthode ou UNE classe pour que tout tombe à l'eau.
De plus, je ne considère pas les professions de foi des ingénieurs (même hauts placés) de MS comme des engagements. MS est une entreprise privée, dirigée par ses chefs. Il y a chez MS des gens très bien qui aimeraient faire plus d'open source, qui ne sont pas contre la GPL, etc. La direction les laisse collaborer avec l'extérieur et même produire de l'open source. Mais à la fin, c'est la direction qui décide, comme dans les autres entreprises. Je ne vois pas en quoi .NET n'est pas stratégique pour MS. Au contraire, je pense même que c'est un des projets les plus stratégiques pour Microsoft qui veut s'imposer de plus en plus au niveau serveur. Contrairement à ce que tu racontes, il n'y a aucune raison pour que MS ne défende pas très fortement .NET. Et d'ailleurs tu le dis toi même au sujet des API non standardisées. Et au fait, ASF n'est pas un codec mais un format de fichier...
Pourquoi tu ne reprends pas mon argumentation, la 2ème partie de mon post ?
Parce que ça n'a aucun intérêt. Le bla bla sur Mono n'est pas plus dangereux que le noyau linux parce qu'il existe pleins de brevets logiciels n'apporte rien à la discussion et nie la spécifificité de .NET (ou de Java, c'est pourquoi je n'ai pas utilisé ce "non argument" au sujet de Java). Les brevets sur .NET on pour but explicite de protéger .NET, alors que les brevets qui peuvent toucher linux ont pour but de protéger certaines fonctionnalités qu'on peut être ammené à inclure dans un noyau. Ce n'est pas la même chose.
Quant à la solution, elle est toute trouvée, obtenir l'accord officiel de Microsoft ou de Sun pour les implémentations open source de leur technologie. Et alors que tu te gargarises de documents sans valeur légale (comme le fameux mail tant cité), dans le monde Java, des accords officiels ont déjà été passés. C'est le point que les gens de mauvaise foi comme toi passent toujours sous silence : une partie de Java est implémenté en open source de façon officielle, avec l'accord signé de Sun. Il s'agit bien sur de la partie J2EE en version 1.4 implémentée par JBoss et par Jonas. C'est ces faits qui prouvent que la situation est différente : SUN est officiellement d'accord pour qu'au moins certaines parties de Java soient implémentées sous forme libre.
Enfin, le bla bla sur la protection des utilisateurs est comique. Où sont les versions forkées de Perl et de Python, pour ne prendre que ces exemples ?
En conclusion, je ne te trouve pas très constructif. Tu ne cesses de t'abriter derrière de supposition, en ne retenant des documents disponibles sur le web que les moins officiels et en refusant d'apprendre du passé. Tu te caches derrière Novell qui "a étudié les brevets en question", etc. N'es tu pas capable de lire les brevets et de te faire une opinion ? Puisque que tu aimes les arguments d'autorité, pourquoi croire plus Novell que RedHat ?
la conclusion biaisée pas étonnant vu que l'auteur est un expert Java
Quelle puissance dans l'argumentation ! Si j'avais aujourd'hui à choisir un langage et une plateforme sur des arguments exclusivement techniques, je prendrais C# et .NET car je pense que c'est ce qui se fait de mieux. Je suis d'autant plus dégouté que Mono pose potentiellement des problèmes légaux que c'est pour moi une superbe réalisation logicielle. Contrairement aux projets open source Java, Mono a dès le début pris ses distances avec les API canoniques en proposant des choses très intéressantes comme gtk#. Oui, je suis un expert Java (merci), mais je n'ai rien contre le framework de MS, au contraire.
Concernant le caractère biaisé de ma conclusion, je vois que tu te contentes d'une affirmation pour seule critique d'une argumentation de 20 pages et je ne vois donc pas l'intérêt de te répondre.
Au fait, j'ai oublié un point très important : il est très peu probable que j'autorise la diffusion de versions modifiées. Ce texte comporte une grande partie factuelle, mais aussi mon opinion et je ne veux pas qu'une version modifiée reprenne les faits et propose une conclusion différente. Pour que j'autorise ça, il faudrait que le texte change de titre, et que ma conclusion reste présente verbatim (ou presque).
C'est effectivement une bonne piste, mais les langages sont très différents du couple Java/C# et les API beaucoup moins riches. Il est donc assez difficile de comparer, à mon avis.
Kodak et Sun ont passé un accord. Les implémentations alternatives n'ont pas cet accord auprès de Kodak. J'ai donc beaucoup de mal à comprendre en quoi tu arrives à conclure de manière "positive".
Parce que Sun a indiqué explicitement que l'accord couvrait les licences officielles de Java et qu'une implémentation légale a nécessairement une licence officielle. Lis les documents donnés en référence.
Et pout finir, une citation de Steve Ballmer, traduite de l'allemand (pas par moi) : Responding to questions about the opening-up of the .NET framework, Ballmer announced that there would certainly be a "Common Language Runtime Implementation" for Unix, but then explained that this development would be limited to a subset, which was "intended only for academic use". Ballmer rejected speculations about support for free .NET implementationens such as Mono: "We have invested so many millions in .NET, we have so many patents on .NET, which we want to cultivate."
J'ai l'autorisation de Denis pour faire évoluer le document. Effectivement, personne d'autre ne peut faire des modifications et/ou des traductions. Comme j'ai vendu ce texte aux Editions Diamond, je trouve ça parfaitement normal. Cependant, il est tout à fait possible que j'obtienne un jour le droit de passer le texte en vraiment libre, ce que j'aimerais. Mais un refus des Editions Diamond me semblerait aussi parfaitement légitime. Bref, ce document, financé par les Editions Diamond, est mis à disposition du public gratuitement et si j'en ai le temps sera maintenu. C'est le mieux que je puisse faire actuellement.
Tu es vraiment le roi des trolleurs, mais je ne tomberais pas dans le piège et j'invite les autres lecteurs à faire de même et à te laisser troller tout seul. Oui, un jour, quand j'aurais le temps, mon article sur .Net vs Java de Linuxmag sera disponible en ligne et tu pourras le lire et enfin comprendre pourquoi tu racontes n'importe quoi.
Mais non, tu mélanges tout. Mono et mp3, c'est comparable, car c'est une histoire de brevets. Et ça n'a rien à voir avec la notion de logiciel libre, c'est simplement le respect de la loi. Et ouai, on peut être contre les brevets logiciels, ou contre la pénalisation du shit, le fait est que dans un pays qui applique l'un ou l'autre, on risque des ennuis légaux si on ne respecte pas la loi.
Donc RedHat est effectivement à cheval sur le respect du logiciel libre, ce qui est super, mais l'entreprise est aussi à cheval sur le respect de la loi, ce qui est aussi super, mais n'a rien à voir.
Quand je lis "Entièrement libre, Fedora Core n'intègre aucun composant propriétaire tel que le support des fichiers MP3.", ça m'ennerve.
Le support du format mp3 est soumis dans les pays qui reconnaissent les brevets logiciels à un accord de licence avec les dententeurs des brevets associés (fraunhofer et compagnie, cf http://www.mp3licensing.com/).(...) Tout ça a des liens avec le libre, mais la présentation qui en est faite dans la news est pour le moins imprécise. Elle contribue à maintenir une confusion entre ce qui est légal ou pas, entre ce qui est libre ou pas, entre ce qui est propriétaire ou pas.
En fait, RedHat n'a pas le droit de distribuer un décodeur (ou encodeur) mp3, mais c'est parfaitement légal pour des entreprises européennes qui distribuent seulement en Europe (ça c'est pour l'aspect brevet). Il existe des implémentations libres et légales d'encodeur et décodeur (ça c'est pour l'aspect libre) et bien sûr des implémentations propriétaires et légales (ça c'est pour l'aspect propriétaire).
Décidément, tu n'as toujours rien compris au concept de licence royalty free (cf Mono et C#). Le fait que cela ne soit pas payant (royalty free) n'implique pas qu'il n'y aura pas de restriction. Certaines licences royalty free de Microsoft sont connues pour n'être données que si les logiciels produits ne sont pas sous GPL.
C'est faux (encore actuellement sur un kernel 2.6.8.1 base Debian).
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.
C'est donc permis dans plein de pays, comme pour n'importe quel soft.
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.
Dans le droit positif (romain, napoléon, français, etc.), tu as raison, même si l'interprétation de la loi par la cours de cassation et ses équivalents soit en fait le point final pour déclarer ce qui est légal ou pas. Par contre, ce n'est pas vrai en droit coutumier (anglo-saxon pour faire court). Il faut un jugement pour déterminer si quelque chose est légal ou non.
Aucun ne faisait ce que faisait BK (enfin, de mémoire), mais ce n'est pas le seul modèle de gestion de source. Linus ne voulait pas entendre parler d'un autre modèle et ne pouvait donc rien utiliser d'autre, tout en moins de son point de vue. Je pense que si Linus avait accepté de ne pas faire sa tête de mule, il aurait pu se satisfaire de moins bien que BK à ce moment là et l'outil choisi aurait vite progressé. L'accélération du développement du noyau, j'ai tendance à considérer que c'est relativement récent (depuis la sortie du 2.6) et je pense que depuis cette sortie, il existe des outils de qualité.
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.
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 ?)
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...
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;
Je pense que Linus est bien mieux placé que nous deux pour en juger, et il est plus que clair là dessus.
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.
D'autant plus que McVoy a dit lui-même que certains développeurs linux employés pas de grosses boites comme IBM ont acheté des licences BK. Et la seule raison pour laquelle ils l'ont fait, c'est que Linus a utilisé BK. Donc McVoy a bien tiré un profit direct de l'utilisation de BK pour le développement de Linux. Et ce sans tenir compte de la pub.
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.
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.
La plupart considerent qu'il est tout a fait legitime de faire ce qu'il a fait.
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.
Enfin, j'ai un id inférieur à 100 (je ne me rappelle plus de la valeur), je suis sûrement l'un des plus vieux comptes actifs (et plus vieux cons toujours d'ailleurs), mais je ne connaissais pas. Bouh. Il est vrai que je me spécialise plutôt dans les trolls sur Java.
[^] # Re: héhé
Posté par boubou (site web personnel) . En réponse au journal Java, .NET et les logiciels libres. Évalué à 2.
Mais bien sûr. La phrase complète est But Microsoft (and our co-sponsors, Intel and Hewlett-Packard) went further and have agreed that our patents essential to implementing C# and CLI will be available on a "royalty-free and otherwise RAND" basis for this purpose.
Explique moi un instant pourquoi l'ingénieur de chez MS n'a pas utilisé le mot "and" seul ? Parce que ça ne veut rien dire ! On ne peut pas être à la fois royalty-free et RAND, sauf si on interprète RAND comme royalty-free, ce qui n'est évidemment pas le cas. La présence du otherwise est cruciale puisqu'elle montre qu'il y a justement une différence. Et on ne sait pas au final quels seront les critères de décision de MS pour le choix entre ces alternatives.
De plus, ce mail n'a AUCUNE valeur légale. Ne trouve tu pas étrange que le site web de MS qui contient de nombreux modèles d'accord de licence n'en propose aucun pour .NET ?
Enfin, obtenir une licence royalty-free ne signifie en aucun cas que tu pourras redistribuer une implémentation open source, comme je le démontre par des exemples de chez Microsoft dans le texte.
Oué mais justement j'ai pas trouvé, d'où ma demande.
Et bien va lire le brevet : http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HIT(...) (et c'est seulement un des brevets). Il est possible que certaines API ne soient pas couvertes, ceci dit. Dans une révision de mon article, je remplacerais toute l'API par une grande partie de l'API, ça sera plus prudent.
Evidemment que MS peut obtenir des brevets qui peuvent être "génant" pour Mono. Mais les APIs de MS n'innovent quasiment pas, alors soient d'autres plateformes seront impactés (autour des web services comme le laisse entendre une des tes sources), soient un prior-art sera démontré.
En effet, tout est possible dans le monde des Bisounours. Le problème est qu'il suffit de ne pas pouvoir implémenter UN appel de méthode ou UNE classe pour que tout tombe à l'eau.
De plus, je ne considère pas les professions de foi des ingénieurs (même hauts placés) de MS comme des engagements. MS est une entreprise privée, dirigée par ses chefs. Il y a chez MS des gens très bien qui aimeraient faire plus d'open source, qui ne sont pas contre la GPL, etc. La direction les laisse collaborer avec l'extérieur et même produire de l'open source. Mais à la fin, c'est la direction qui décide, comme dans les autres entreprises. Je ne vois pas en quoi .NET n'est pas stratégique pour MS. Au contraire, je pense même que c'est un des projets les plus stratégiques pour Microsoft qui veut s'imposer de plus en plus au niveau serveur. Contrairement à ce que tu racontes, il n'y a aucune raison pour que MS ne défende pas très fortement .NET. Et d'ailleurs tu le dis toi même au sujet des API non standardisées. Et au fait, ASF n'est pas un codec mais un format de fichier...
Pourquoi tu ne reprends pas mon argumentation, la 2ème partie de mon post ?
Parce que ça n'a aucun intérêt. Le bla bla sur Mono n'est pas plus dangereux que le noyau linux parce qu'il existe pleins de brevets logiciels n'apporte rien à la discussion et nie la spécifificité de .NET (ou de Java, c'est pourquoi je n'ai pas utilisé ce "non argument" au sujet de Java). Les brevets sur .NET on pour but explicite de protéger .NET, alors que les brevets qui peuvent toucher linux ont pour but de protéger certaines fonctionnalités qu'on peut être ammené à inclure dans un noyau. Ce n'est pas la même chose.
Quant à la solution, elle est toute trouvée, obtenir l'accord officiel de Microsoft ou de Sun pour les implémentations open source de leur technologie. Et alors que tu te gargarises de documents sans valeur légale (comme le fameux mail tant cité), dans le monde Java, des accords officiels ont déjà été passés. C'est le point que les gens de mauvaise foi comme toi passent toujours sous silence : une partie de Java est implémenté en open source de façon officielle, avec l'accord signé de Sun. Il s'agit bien sur de la partie J2EE en version 1.4 implémentée par JBoss et par Jonas. C'est ces faits qui prouvent que la situation est différente : SUN est officiellement d'accord pour qu'au moins certaines parties de Java soient implémentées sous forme libre.
Enfin, le bla bla sur la protection des utilisateurs est comique. Où sont les versions forkées de Perl et de Python, pour ne prendre que ces exemples ?
En conclusion, je ne te trouve pas très constructif. Tu ne cesses de t'abriter derrière de supposition, en ne retenant des documents disponibles sur le web que les moins officiels et en refusant d'apprendre du passé. Tu te caches derrière Novell qui "a étudié les brevets en question", etc. N'es tu pas capable de lire les brevets et de te faire une opinion ? Puisque que tu aimes les arguments d'autorité, pourquoi croire plus Novell que RedHat ?
[^] # Re: héhé
Posté par boubou (site web personnel) . En réponse au journal Java, .NET et les logiciels libres. Évalué à 2.
Quelle puissance dans l'argumentation ! Si j'avais aujourd'hui à choisir un langage et une plateforme sur des arguments exclusivement techniques, je prendrais C# et .NET car je pense que c'est ce qui se fait de mieux. Je suis d'autant plus dégouté que Mono pose potentiellement des problèmes légaux que c'est pour moi une superbe réalisation logicielle. Contrairement aux projets open source Java, Mono a dès le début pris ses distances avec les API canoniques en proposant des choses très intéressantes comme gtk#. Oui, je suis un expert Java (merci), mais je n'ai rien contre le framework de MS, au contraire.
Concernant le caractère biaisé de ma conclusion, je vois que tu te contentes d'une affirmation pour seule critique d'une argumentation de 20 pages et je ne vois donc pas l'intérêt de te répondre.
[^] # Re: licence du doc
Posté par boubou (site web personnel) . En réponse au journal Java, .NET et les logiciels libres. Évalué à 1.
[^] # Re: Alternative
Posté par boubou (site web personnel) . En réponse au journal Java, .NET et les logiciels libres. Évalué à 3.
[^] # Re: héhé
Posté par boubou (site web personnel) . En réponse au journal Java, .NET et les logiciels libres. Évalué à 5.
Non. Il est indiqué royalty-free and otherwise RAND, ce qui ne se traduit pas par et, mais par "et dans d'autres cas", ce qui veut dire ou.
D'où provient l'affirmation que les brevets en questions concernent l'ensemble des APIs et qu'il est impératif de les implémenter ?
Tu as lu mon texte, mais tu n'as pas lu les documents pointés, c'est ça ? Lis les références et on rediscute. Cf donc
http://www.theregister.co.uk/2003/02/11/ms_patents_everything/(...) et http://news.com.com/2100-1001_3-984052.html(...)
Kodak et Sun ont passé un accord. Les implémentations alternatives n'ont pas cet accord auprès de Kodak. J'ai donc beaucoup de mal à comprendre en quoi tu arrives à conclure de manière "positive".
Parce que Sun a indiqué explicitement que l'accord couvrait les licences officielles de Java et qu'une implémentation légale a nécessairement une licence officielle. Lis les documents donnés en référence.
Et pout finir, une citation de Steve Ballmer, traduite de l'allemand (pas par moi) :
Responding to questions about the opening-up of the .NET framework, Ballmer announced that there would certainly be a "Common Language Runtime Implementation" for Unix, but then explained that this development would be limited to a subset, which was "intended only for academic use". Ballmer rejected speculations about support for free .NET implementationens such as Mono: "We have invested so many millions in .NET, we have so many patents on .NET, which we want to cultivate."
Et ouai, ça fout la trouille, hein ? (source http://swpat.ffii.org/players/microsoft/(...) ).
[^] # Re: licence du doc
Posté par boubou (site web personnel) . En réponse au journal Java, .NET et les logiciels libres. Évalué à 4.
[^] # Re: Libre, propriétaire et mp3
Posté par boubou (site web personnel) . En réponse à la dépêche La Fedora Core 4 débarque. Évalué à 3.
[^] # Re: Libre, propriétaire et mp3
Posté par boubou (site web personnel) . En réponse à la dépêche La Fedora Core 4 débarque. Évalué à 3.
[^] # Re: Libre, propriétaire et mp3
Posté par boubou (site web personnel) . En réponse à la dépêche La Fedora Core 4 débarque. Évalué à 3.
Donc RedHat est effectivement à cheval sur le respect du logiciel libre, ce qui est super, mais l'entreprise est aussi à cheval sur le respect de la loi, ce qui est aussi super, mais n'a rien à voir.
# Libre, propriétaire et mp3
Posté par boubou (site web personnel) . En réponse à la dépêche La Fedora Core 4 débarque. Évalué à 10.
Le support du format mp3 est soumis dans les pays qui reconnaissent les brevets logiciels à un accord de licence avec les dententeurs des brevets associés (fraunhofer et compagnie, cf http://www.mp3licensing.com/).(...) Tout ça a des liens avec le libre, mais la présentation qui en est faite dans la news est pour le moins imprécise. Elle contribue à maintenir une confusion entre ce qui est légal ou pas, entre ce qui est libre ou pas, entre ce qui est propriétaire ou pas.
En fait, RedHat n'a pas le droit de distribuer un décodeur (ou encodeur) mp3, mais c'est parfaitement légal pour des entreprises européennes qui distribuent seulement en Europe (ça c'est pour l'aspect brevet). Il existe des implémentations libres et légales d'encodeur et décodeur (ça c'est pour l'aspect libre) et bien sûr des implémentations propriétaires et légales (ça c'est pour l'aspect propriétaire).
Bref, un peu de précision ne tuera personne.
[^] # Re: Et les logiciels libres ?
Posté par boubou (site web personnel) . En réponse à la dépêche La guerre des formats continue !. Évalué à 7.
[^] # Re: qmail toujours bien
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. É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: Le paternalisme, c'est mal.
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. Évalué à 4.
[^] # Re: Adieu et merci pour le poisson
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. Évalué à 2.
[^] # Re: Le paternalisme, c'est mal.
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. É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: bel exemple...
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. Évalué à 2.
[^] # Re: bel exemple...
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. É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: Le paternalisme, c'est mal.
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. É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 boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. É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: bel exemple...
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. É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: Le paternalisme, c'est mal.
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. Évalué à 3.
Si, c'est explicitement interdit dans la licence commerciale.
[^] # Re: Adieu et merci pour le poisson
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. Évalué à 8.
[^] # Re: Adieu et merci pour le poisson
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. É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 boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. É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: Revers pour Linus
Posté par boubou (site web personnel) . En réponse à la dépêche BitKeeper : plus de version gratuite. Évalué à 2.