X n'a nullement à accepter un contrat sans en connaitre les termes, il autorise simplement Y à redistribuer sous une autre licence. Y reste et restera lui toujours lié à X par la v2, pas par la v3. Y lui diffuse bien en v3 mais il a toute connaissance du contenu et l'a accepté. Z lui n'a même pas eu entre les mains la v2 donc n'a pas son mot à dire.
Personne n'a ici accepté un contrat sans en avoir vu les termes. Enfin pas plus que dans plein d'autres licences qui autorisent la redistribution sous d'autres termes (la BSD par exemple)
Bof; c'est totalement utopique.
- 5 seconde par mail ça veut dire multiplier énormément les couts des smtp des FAI de entreprises. En général ce sont déjà des serveurs surchargés et qui leurs posent problèmes. Jamais les FAI n'accepteront ça
- le SMTP qui reçoit doit payer aussi vu qu'il lui faut simplement vérifier le calcul de 5 secondes de l'expéditeur (sinon ça ne sert à rien), et ça ça devient moins acceptable
- ça va faire chier tout le monde, pas plus les spammeurs que les autres. Les spammeurs vont juste mettre plus de machines. Ca les empêchera comment de faire du spam ?
> Tous les sources GPL qu'utilise la Freebox sont récupérables... noyau µLinux pour
> les anciennes, noyau Linux pour la nouvelle, etc...
Ah ? qu'il y a t'il dans la freebox ? tu le sais ? ils ne communiquent pas beaucoup la dessus. Note qu'il ne suffit pas que ce soit récupérable, il faut qu'ils fournissent explicitement une manière de tout récupérer et de tout reproduire les compilations (donc les paramètres aussi). Ils ne le font pas.
Le fait que le noyeau linux soit dispo sur FTP ne dégage personne des obligations de la GPL quand ils distribuent ce même noyeau.
> mais font travaillé les contribs de VLC qui ont réalisé pour eux un portage de VLC
> pour la FB mais from scratch
Source ? eux parlent d'une puce dédiée, faut croire que ce n'est pas si clair.
Quand à un portage from scratch il faudra m'expliquer ce que ça veut dire. Soit tu te bases sur le source initial et ça doit respecter la licence, soit tu ne regardes pas ce source et ce n'est plus un portage.
> reverse tout leur développement dans les CVS sans ne jamais mettre le dawa,
> genre forkage à tout va...
source ?
> Free est une des entreprises qui contribue le plus au logiciel libre
Ils fournissent des mirroirs, sorti de là j'attend de voir des liens pour croire quoi que ce soit. et surtout pour dire "qui contribue le plus"
> et seraient donc tout à fait en règle vis à vis de la GPL.
Ils ne distribuent pas la licence de façon explicite, n'informent pas sur les droits accordés, non, ça ne serait pas un respect de la GPL. D'ailleurs si ce n'était pas le cas tu ne parlerais pas au conditionnel.
> pour autant que je sache rien n'oblige la diffusion du .config utilisé ...
Doit être diffusé tout ce qui est nécessaire pour créer le logiciel. Ca comprend logiquement la configuration normalement (même si effectivement l'intérêt est souvent moins grand)
Mais bon, Free s'est exprimé sur le sujet, ils considèrent qu'ils ne font pas redistribution de soft en prêtant la fbx donc pas de GPL qui rentre en jeu.
> Je parle de hifi, on est bien d'accord ? Pas d'un kit à 100 ¤, d'une installation hifi à
> disons 1000 ¤ (ampli + enceintes bibliothèques).
Tu veux que je te dise ? si tu as besoin d'une installation à 1000¤ pour voir une différence c'est que la sortie audio est effectivement très bonne.
En tout cas elle suffira à une très large majorité des gens qui n'ont pas une installation sonore si chère.
Free n'est pas vraiment connu pour sa "transparence" sur le fonctionnement interne de la freebox, au contraire. Ils utilisent du libre mais ont toujours jusqu'à présent refusé de livrer quoi que ce soit. Là ils vont avoir un petit vlc sur le poste client et ça suffit pour reprocher aux autres un manque de transparence ?
> En fait, la GPL me semble suffisamment ouverte pour ne pas entrer
> en conflit avec les législations nationales.
Bof, elle entre déjà plus ou moins en conflit avec le droit Français à cause de la langue dans laquelle elle est rédigée. Certains trouvent que ça reste acceptable en allant opposer d'autres principes de loi, certains trouvent que ça n'invalident pas pour autant le texte, mais dans l'ensemble c'est tout de même au moins un point de détail qui pose problème.
> Pour que la GPL reste la GPL, 1 seule version doit faire référence, une
> traduction à l'identique du sens étant impossible.
C'est pour moi l'argument premier qui fait qu'il nous faut un texte français. Ceux qui ne parlent pas à 100% l'anglais en maitrisant tous les détails et connotations risquent de mal comprendre en étant de bonne foi et en faisant des efforts, c'est qu'il y a problème. S'il est aussi impossible de traduire que tu le dis alors il y a tout a parier que ce soit effectivement le cas.
Entre un texte qu'on comprend et sur lequel les deux parties sont d'accord mais qui n'est pas exactement le même que celui que voudrait la FSF .. et un texte qu'on comprend mal et donc qu'on appliquera mal ou qui posera des ambiguité mais qui est exactement celui que veut la FSF .... mon choix est vite fait (pour la première solution)
Et si tu crois que la GPL est simple à comprendre, comptes donc le nombre de troll / engueulades / conflits / débats qu'on a eu sur le texte ici. Même en ne laissant que ceux ou interviennent des gens de bonne foi, renseignés, qui étudient avec détail le texte ... ça en laisse encore beaucoup.
Si tu es une entreprise et que tu t'adresses à un particulier tu risques d'entrer dans des cas plus sioux.
- déjà parce qu'il n'y a pas besoin de texte écrit pour un contrat ou un accord. Même s'il n'a pas de licence en français ça ne remet pas forcément en cause ses droits. C'est encore plus vrai si la société a reçu quelque chose (par exemple paiement d'une distrib) parce que ça implique une contre-partie donc des droits gagnés pour le particulier (qu'ils soient explicites ou pas)
- la protection est par défaut pour le particulier, je serai même tenté par dire qu'à défaut d'avoir un texte explicite et compréhensible il n'est engagé que par les contraintes qu'on trouve habituellement dans un contexte similaire ou qu'il est en droit d'attendre dans un contexte similaire.
Je doute encore plus que tu puisses décider de lui retirer des droits (sous prétexte qu'il n'a pas de contrat français) que tu a souhaité lui accorder dès qu'il cherche à faire appliquer la loi. Ca serait soumettre l'application de la loi à une condition et je doute que ce soit forcément très bien pris.
> Dans quelles mesures la ou les nouvelles versions peuvent modifier les droits et les
> devoirs ? La nouvelle version peut-elle être plus restricitive ou, au contraire,
> accorder plus de "libértés" ?
Oui, les deux (si tu accordes plus de libertés à une des parties ça devient plus restrictif pour l'autre). Si tu fais un changement ça va forcément paraitre mieux ou moins bien à quelqu'un.
> Si un soft est publié aujourd'hui en GPL, donc en version 2, lors de la sortie de'une
> nouvelle version, le soft sera-t-il toujours en version 2 ou la license évolue
> directement en version 3 ?
Un soft ne change pas de licence tout seul. Par contre celui qui a un soft en GPLv2 peut décider de le diffuser sous GPLv2 ou GPLv3, au choix.
Donc ton soft restera en v2 à moins que tu changes d'avis et passes volontairement en v3 ou que tu intègres une contrib qui est en v3.
> Bah tiens... Prends un projet de 1 million de ligne de code, avec 50
> développeurs, sur une durée de 3 ans
Oui, mais des projets de 150 ans/homme on en trouve pas non plus tous les jours. Ca n'est pas forcément représentatif. En tout cas ça ne concerne pas tout le monde.
Mais ce que tu dis ne contredit en rien mes propos. Tu es chef ? tu veux contrôler plus ton projet ? alors tu imposes à tes équipes de passer par l'analyseur qui contrôle les types.
Il n'y a aucune raison pour imposer à sur le langage (donc à tout le monde) juste pour quelques projets de taille énorme. Je ne dis pas que le contrôle est mal, ce que je dis c'est qu'il faut que ce soit un choix, pas une contrainte. Si c'est ton choix ou celui de ton chef tu lances cette vérification, ça s'arrête là.
Puis bon, si tes développeurs sont incompétents ce n'est malheureusement pas un typage statique contrôlé qui va résoudre tes problèmes ;)
> Le prochain Visual Studio permet cela avec des langages comme C#.
Intéressant.
> J'aime pas le "si" tu le souhaites. Je préfères que le langage le
> contraigne au développeur, pour le "forcer" à produire un code de
> meilleur qualité.
J'ai toujours eu l'opinion inverse en fait. L'informatique, la programmation, le langage, ce sont des outils pour aider l'utilisateur et le développeur. Dès qu'ils deviennent une contrainte c'est qu'il y a un défaut quelque part dans la procédure.
Si le développeur veux mettre des types partout il faut que le langage lui permette. Si le développeur pense aller plus efficacement sans les contrôles de type à court terme qu'il le fasse aussi. Si tu veux une contrainte alors demande à ton analyseur de code de te mettre un warning à chaque type manquant, mais ce n'est pas le rôle du langage.
Si tu veux forcer une syntaxe limitée pour rendre clair le code je comprend. Par contre je ne vois pas de raison de forcer le développeur à mettre des contrôles s'il n'en veut pas. S'il en veut il est assez grand pour les mettre et demander à un outil de vérifier qu'il les met.
Pour les gains de temps en développement je pense que ça dépend des habitudes. En fait je suis sûr de perdre du temps en typant mais je suis sur que ça se regagne de l'autre coté avec l'IDE qui peut proposer des completion plus pertinentes et plus souvent, ou aider beaucoup plus à la frappe. Ce qui me gêne beaucoup plus c'est la lecture du code qui contient tous les contrôles (types, accès, ...). C'est en général super lourd à lire et ça ça joue beaucoup dans la clarté pour quelqu'un qui n'a pas l'habitude. Je le comprend dans une phase de stabilisation/test, mais dans la phase de développement/conception je préfère un code clair et concis avec le moins de contrôles possibles.
> Mais bon d'une manière générale les langages dynamiques
> interprétés ne sont justement pas typés fortement, et encore moins
> statiquement.
Typage fort beaucoup de langages le sont (reste à voir ce qu'on met derrière le terme de typage fort mais je pense qu'il y a pas mal de langages qui peuvent valider ça). Typage statique effectivement, c'est moins habituel.
Mon idéal pour le genre d'appli auxquelles je participe ça serait un langage interprété ou semi interprété, types forts, avec un typage statique optionnel et un analyseur de code :
- tu profites de l'interpréteur "ca s'exécute à la moindre modif" voire du "debuggueur en cours de frappe"
- tu profites du typage statique : tu rajoutes les contraintes de type si tu le souhaites là où le code est plus délicat ou si tu souhaites renforcer les contrôles pour valider ton code
- tu as un analiseur potentiellement lent et long qui sait faire de la détection de type quand tu ne l'a pas déclaré toi même, et sait exploiter les types statiques pour vérifier les concordances.
Le problème c'est que je ne suis pas sûr que le tout soit conciliable avec la notion de langage dynamique tel qu'on la voit dans un python ou un ruby
> Autrement dit, ta variable n'est pas d'un type bien définie.
> Quand tu écris $a = "3 maisons" on lui a assigné une valeur de type chaîne de caractères.
Il n'y aurait pas contradiction entre ces deux phrases ?
Pour moi qu'une fonction gettype() puisse retourner un type déterminé non ambigue et toujours le même dans une situation similaire veut bien dire qu'un tel type existe (contrairement à d'autres domaines, je pense par exemple à sqlite pour qui tout est chaine de caractère et qui ne "résoud" les choses en nombre que lors des opérations genre addition).
> Mais lorsque tu fais $a + 1, si ta variable était de type fort, alors une erreur aurait
> été levée parce que l'on ne peut pas additionner une chaîne avec un entier.
Le fait que tu puisses faire "3 maisons " +1 ne veut pas dire que "3 maisons" n'a pas de type, ça veut dire qu'il y a transtypage implicite (le terme même de transtypage sous entend qu'il y a un type d'ailleurs).
Notes que des transtypages on peut aussi en avoir dans des langages très fortement typés comme en C ou C++ (jamais eu l'avertissement du compilo qui a casté un char dans un int ? un pointeur dans un int ? ou le contraire ?). Ca n'en fait pas des typages faibles pour autant.
> Si par contre, on avait $a = $a + 1 => "3 maisons1" alors on aurait pu dire
> qu'effectivement $a pourrait être de typage fort avec un transtypage implicite
> correcte qui est de convertir l'entier 1 en sa représentation chaîne de caractères
> avant de la passer à l'opération de concaténation '+' (si '+' est l'opérateur de
> concaténation bien sûr)
Ah ? donc si j'emploi l'opérateur de concaténation (en php c'est le point) et que ça donne ce que tu dis c'est un langage typé fort ? planté ... $a = $a . 1 donne effectivement "3 maisons1"
Pourquoi ? la seule différence entre ton $a = $a + 1 => "3 maisons1" et ce qu'il se passe réellement c'est qu'il n'a pas fait le transtypage sur la même donnée que tout. Il a fait le transtypage sur le $a au lieu de le faire sur le 1 (ce qui est plutot intelligent vu que dans l'exemple il s'agit d'une addition et pas d'une concaténation, qui sont des opérateurs différents). Mon addition est une opération qui attend deux nombres, on lui donne une chaine, il convertit donc la chaine en nombre implicitement. Ca ne contredit pas du tout la présence de typage.
Dans l'absolu l'opération est la même (transtypage), les principes mis en jeu sont les mêmes (repérer qu'une des valeurs n'a pas le type attendu et faire un transtypage implicite quand c'est possible pour faire concorder).
Ceci dit ça montre bien ce que je disais : la limite du typage fort et du typage faible n'a rien d'une limite claire et objective (même si on est tous les deux d'accord pour dire que le typage de PHP est on ne peut plus faible)
> En même temps tu prends exemple sur PHP qui est un langage interprété avec un
> typage dynamique.
> Moi je te parle de C++, Java ou C#, avec un vrai compilo qui vérifies le typage
> statiquement (quand c'est possible) et vrai IDE.
Tu n'as pas compris. Je parle de développer PHP, pas de développer "avec" PHP. Je parle donc bien de développer en C ou C++ (ici c'était du C++ mais ça ne change pas grand chose) avec un vrai compilo et un typage statique.
Et oui c'était horriblement lent. Dans les dernières phases je passais plus de temps en compil qu'en test/modif
> T'auras beau dire tout ce que tu veux, le compilo fait un nombre incalculable de
> tests, surtout avec un langage à typage fort et statique.
Oui. La question c'est : est-ce qu'il est indispensable que ton langage à typage fort et statique soit un langage compilé pour pouvoir faire ce genre de vérification ? la réponse est "non".
Donc non, que tu le veuilles ou non la compilation n'est pas nécessaire pour ta phase de test et non le fait de vouloir controler tous les types n'est pas une raison pour supporter la compilation.
> Visiblement tu n'as rien compris à ce qu'est un compilo, à ce qu'il est censé faire.
> Il n'est pas censer que "pondre" du code, un compilo c'est avant tout un
> analyseur lexical et syntaxique qui constitue une première couche de TESTS et un
> générateur de code. C'est loin d'être seulement la 2ème partie.
Je ne dis pas le contraire, mais il passe aussi un temps non négligeable sur tout le reste (pour reprendre mon exemple, recompiler les fichiers modifiés c'était rapide, c'était pour reconstruire les libs et binaires derrière avec toutes les liaisons qui était long, et là les contrôles de types et l'analyse lexicale étaient déjà faits).
Que tu veuilles faire toute cette analyse je comprend. Mais non faire toute cette analyse ne justifie pas de passer du temps supplémentaire pour faire la compilation.
Tu peux t'en servir comme ça, mais tu perd inutilement du temps sur des trucs qui ne servent pas à tester, et donc qui sont inutiles à ton but premier.
J'en profite pour rappeler que ce qui est sur wikipédia c'est ce que les gens y ont mis, rien de plus (et pas forcément La Vérité Objective)
Le problème du typage fort c'est que même avec ta définition (qui me convient assez bien) c'est assez flou. Exemple avec PHP (typage faible dynamique) :
Ma donnée a bien un type clairement défini et non ambigu, simplement on fait des conversions implicites entre les différents types un peu partout. Je suppose qu'on ne peut pas pour autant dire que tous les langages qui proposent des système de conversion implicites sont en typage faible pour autant (sinon on va finir par classer C et C++ dans les typages faibles)
Je pense que les séparations entre faible et strictes n'ont pas vraiment de délimitation forte. C'est plus une histoire de philosophie et d'orientation du langage.
(La question du typage statique/dynamique n'est pas tellement plus facile avec l'arrivée des languages qui savent parfois déterminer seuls les types avant exécution sans que l'utilisateur ne précise rien)
> La phase de compilation c'est de l'ordre de la seconde lors d'une phase de dev normale
Ah ? chez moi les compil prennent du temps. Pour avoir modifié des sources de PHP récement, à chaque modif ça recompilait le fichier, puis l'extension dont dépendait ce fichier, puis la libphp4 avec l'extension en statique (non, dynamique ça collait pas), puis finalement le php-cli qui va avec.
Le tout était *très* loin de la seconde et très loin d'être négligeable.
Et franchement non, la phase de test et la phase de compilation sont deux choses séparées.
Le but de la compilation c'est de produire du code machine. Le but d'une phase de test c'est de vérifier ton code. Certes le gcc pour pouvoir compiler fait des vérifications, mais rien n'empêcherait techniquement une phase de test sans compilation.
Si tu es concerné par les tests/vérifications l'avenir ce sont des outils d'analyse de code qui repèrent les mêmes choses (syntaxe, mauvais appels, contrôles de type, ...). Ca n'impose en rien une compilation (ou plutot ça ne devrait en rien l'imposer) et c'est une mauvaise justification de l'étape compilation.
Euh, attend, à chaque fois qu'un brevet complètement idiot comme le coup du double click sort on le sait toujours dans les deux jours. Le fait est que des gens surveillent déjà les brevets. Aucun idée de s'ils le font parce que c'est leur métier ou pour eux même mais ils le font déjà.
(notes aussi que vu les délais pour envoyer une contestation il suffirait de faire un bref passage par mot clé tous les deux mois pour retirer pas mal de trucs idiots)
Mais bon, je n'étais pas là pour dire "faites le" mais plus pour me poser la question de la bonne foi de ceux qui surveillent déjà tout ça et attendent le lendemain de la validation pour passer l'info.
Note: en France l'INPI a un système prévu pour ça, avec archive de son coté et ticket de réception. Il joue le tiers de confiance pour quelque chose comme 20 euro, c'est probablement une meilleure idée que le notaire. (par contre ils poinconnent l'enveloppe donc pas de CD ou matériaux durs à l'intérieur, que du papier).
Par cotnre, si ca permet de prouver la paternité d'une oeuvre intellectuelle, je doute que ce soit valable pour les brevets.
La clause d'invalidité des brevets est bien plus fondée sur la publication que la première paternité. Le fait que tu aies une idée similaire dans une enveloppe fermée n'y changera rien
Euh oui mais .... là va falloir se poser la question du "est-ce que c'est aux systèmes mis en place par l'état de protéger la restriction des connaissances ?"
Non parce que le système des brevets a été mis en place *pour* divulguer ce genre de secret et éviter qu'ils existent (et finissent par se perdre au lieu de profiter à tous). Difficile à ce compte là de reprocher au système de brevet de ne pas rendre possible le secret comme tu en parles.
C'est justement pour empêcher ce qui te semble impossible/difficile (garder l'invention secrête) qu'on fait tout ça. Faudrait pas le perdre de vue.
C'est surtout une clause très importante qui permet de limiter les interprétations multiples d'un brevet.
Ca peut (même si j'en doute) diminuer un peu le commerce de la peur basé sur les brevets. Le "donnes moi des sous parce que tu es sous mon brevet". Là il suffirait de dire "je ne crois pas" pour d'un coup risquer beaucoup moins ... et donc aborder la question du "qui a raison" plus sereinement.
Les temps de débat et d'opposition publiques sont déjà présent en Europe et je n'ai pas l'impression que ça soit la panacée (*1).
Le fait est que si personne ne s'oppose et ne se tient à jour pour tout vérifier ça ne sert à rien. C'est un peu comme les sociétés qui croient que parce qu'elles mettent sous GPL elles vont du jour au lendemain avoir 1500 contributeurs qui vont bosser gratuitement.
(*1) : d'ailleurs, quelqu'un s'est posé la question à propos de ces gens du libre qui ralent après tous les nouveaux brevets idiots le jour de leur sortie ? il suffirait qu'ils regardent les annonces de dépot et pas de publication pour bloquer ces mêmes brevets idiots avant leur validation au lieu de faire semblant d'être impuissants. Je ne veux pas être parano mais ...
Premier inventeur ou premier déposant ? si le but est de révéler les secrets et pas de récompenser la recherche c'est tout à fait cohérent. Sauf erreur de ma part c'est déjà le cas en Europe et personne ne rale la dessus.
> Suppression du "best mode" requirement
Arghhhh, ça veut plus ou moins dire qu'on peut faire un brevet volontairement obscur ou qui n'est pas là pour décrire l'implémentation optimale. On met par terre tout le but des brevets (divulguer la connaissance).
C'est CA qui est dramatique à long terme.
C'est un peu comme si dans la GPL on autorisait la publication des codes sources passés à l'offuscateur.
> et d'éliminer la plupart des causes de batailles judiciaires
C'est un but noble, mais complètement idiot. Quand une trop grosse part des brevets sont abusifs c'est normal qu'il y ait des batailles judiciaires. Ce qu'il faut c'est éviter les brevets abusifs, pas les réduire les possibilités d'attaquer (cf le "best mode" ci dessus).
C'est à vérifier mais en europe je crois bien qu'il n'y a *deja* pas besoin d'être inventeur. Et en fait c'est logique.
N'autoriser les brevets que de l'inventeur c'est considérer le brevet comme une récompense à l'innovation ou une contrepartie aux couts de recherche or les brevets sont là uniquement pour favoriser la divulgation des secrets. C'est un peu un "je te payes pour que tu révèles le secret publiquement". Peu importe si ce n'est pas l'auteur qui le fait, le but sera atteint.
> Ce système profite donc encore plus aux sociétés qui ont les moyens
> de déposer et défendre des brevets.
Bof, tant qu'ils imposeront le critère "pas de diffusion publique avant le dépot du brevet" les sociétés comme les particuliers seront dans le même équilibre. Ici un particulier peut autant "piquer" une idée d'une société que le contraire. Et les deux peuvent se contenter d'une diffusion publique pour empêcher le brevet
La copie n'est pas réservée aux diffusions privées mais "strictement réservées à l'usage privé du copiste". Quand tu donnes la copie à quelqu'un qui en fait la demande sur un forum public :
- tu sors du domaine privé
- la copie n'est plus à l'usage du copiste mais à l'usage du demandeur
> un nouveau secret est partagé à chaque nouvelle connexion, un man-in-the-middle
> suffit pour berner ton client, ce qui se fait très bien de la même manière
Le certificat du serveur reste le même. Tous les navigateurs mettent une grosse alerte si le certificat change. Ton attaque man-in-the-middle échouera si la personne est déjà allé sur le site en question auparavant
Même pour la première connexion, le certificat est signé, le navigateur vérifie la signature à chaque fois à partir de sa base d'autorités. Si le méchant n'a pas accès à ta configuration il pourra certes envoyer un faux certificat mais ce faux certificat ne sera pas signé et un avertissement méchant apparait sur ton navigateur.
Non, coté https, si tu n'ignores pas superbement toutes les boites de dialogue d'erreur que t'envoie ton navigateur et que tu ne laisses personne rajouter une autorité de certificat dans ta configuration, tu ne crains pas le man-in-the-middle et le HTTPs est sûr.
SSH c'est la même chose, avec la certification en moins. (on peut très bien certifier mais là il n'y a pas d'autorité centrale que tout le monde reconnait donc ça demande une volonté des deux cotés). Si tu as fait une première connexion correcte tu repèreras tout changement ou toute interception par la suite.
[^] # Re: Différentes versions ? Y-a-t-il un choix ?
Posté par Éric (site web personnel) . En réponse à la dépêche Version 3 de la GPL : les coulisses de l'adoption. Évalué à 2.
Y donne à Z sous GPLv3
X n'a nullement à accepter un contrat sans en connaitre les termes, il autorise simplement Y à redistribuer sous une autre licence. Y reste et restera lui toujours lié à X par la v2, pas par la v3. Y lui diffuse bien en v3 mais il a toute connaissance du contenu et l'a accepté. Z lui n'a même pas eu entre les mains la v2 donc n'a pas son mot à dire.
Personne n'a ici accepté un contrat sans en avoir vu les termes. Enfin pas plus que dans plein d'autres licences qui autorisent la redistribution sous d'autres termes (la BSD par exemple)
[^] # Re: Brevets?
Posté par Éric (site web personnel) . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 3.
- 5 seconde par mail ça veut dire multiplier énormément les couts des smtp des FAI de entreprises. En général ce sont déjà des serveurs surchargés et qui leurs posent problèmes. Jamais les FAI n'accepteront ça
- le SMTP qui reçoit doit payer aussi vu qu'il lui faut simplement vérifier le calcul de 5 secondes de l'expéditeur (sinon ça ne sert à rien), et ça ça devient moins acceptable
- ça va faire chier tout le monde, pas plus les spammeurs que les autres. Les spammeurs vont juste mettre plus de machines. Ca les empêchera comment de faire du spam ?
[^] # Re: La magie du libre
Posté par Éric (site web personnel) . En réponse à la dépêche La FreeBox devient un media center grâce à VLC. Évalué à 4.
> les anciennes, noyau Linux pour la nouvelle, etc...
Ah ? qu'il y a t'il dans la freebox ? tu le sais ? ils ne communiquent pas beaucoup la dessus. Note qu'il ne suffit pas que ce soit récupérable, il faut qu'ils fournissent explicitement une manière de tout récupérer et de tout reproduire les compilations (donc les paramètres aussi). Ils ne le font pas.
Le fait que le noyeau linux soit dispo sur FTP ne dégage personne des obligations de la GPL quand ils distribuent ce même noyeau.
> mais font travaillé les contribs de VLC qui ont réalisé pour eux un portage de VLC
> pour la FB mais from scratch
Source ? eux parlent d'une puce dédiée, faut croire que ce n'est pas si clair.
Quand à un portage from scratch il faudra m'expliquer ce que ça veut dire. Soit tu te bases sur le source initial et ça doit respecter la licence, soit tu ne regardes pas ce source et ce n'est plus un portage.
> reverse tout leur développement dans les CVS sans ne jamais mettre le dawa,
> genre forkage à tout va...
source ?
> Free est une des entreprises qui contribue le plus au logiciel libre
Ils fournissent des mirroirs, sorti de là j'attend de voir des liens pour croire quoi que ce soit. et surtout pour dire "qui contribue le plus"
[^] # Re: Précisions pour ceux qui auront la flemme de cliquer
Posté par Éric (site web personnel) . En réponse au journal Le free respectera la GPL pour VLC. Évalué à 3.
Ils ne distribuent pas la licence de façon explicite, n'informent pas sur les droits accordés, non, ça ne serait pas un respect de la GPL. D'ailleurs si ce n'était pas le cas tu ne parlerais pas au conditionnel.
> pour autant que je sache rien n'oblige la diffusion du .config utilisé ...
Doit être diffusé tout ce qui est nécessaire pour créer le logiciel. Ca comprend logiquement la configuration normalement (même si effectivement l'intérêt est souvent moins grand)
Mais bon, Free s'est exprimé sur le sujet, ils considèrent qu'ils ne font pas redistribution de soft en prêtant la fbx donc pas de GPL qui rentre en jeu.
[^] # Re: Sortie audio
Posté par Éric (site web personnel) . En réponse à la dépêche La FreeBox devient un media center grâce à VLC. Évalué à 7.
> disons 1000 ¤ (ampli + enceintes bibliothèques).
Tu veux que je te dise ? si tu as besoin d'une installation à 1000¤ pour voir une différence c'est que la sortie audio est effectivement très bonne.
En tout cas elle suffira à une très large majorité des gens qui n'ont pas une installation sonore si chère.
[^] # Re: La magie du libre
Posté par Éric (site web personnel) . En réponse à la dépêche La FreeBox devient un media center grâce à VLC. Évalué à 4.
[^] # Re: En langue de Beckham ... Et les cas concrets ?
Posté par Éric (site web personnel) . En réponse à la dépêche Version 3 de la GPL : les coulisses de l'adoption. Évalué à 4.
> en conflit avec les législations nationales.
Bof, elle entre déjà plus ou moins en conflit avec le droit Français à cause de la langue dans laquelle elle est rédigée. Certains trouvent que ça reste acceptable en allant opposer d'autres principes de loi, certains trouvent que ça n'invalident pas pour autant le texte, mais dans l'ensemble c'est tout de même au moins un point de détail qui pose problème.
> Pour que la GPL reste la GPL, 1 seule version doit faire référence, une
> traduction à l'identique du sens étant impossible.
C'est pour moi l'argument premier qui fait qu'il nous faut un texte français. Ceux qui ne parlent pas à 100% l'anglais en maitrisant tous les détails et connotations risquent de mal comprendre en étant de bonne foi et en faisant des efforts, c'est qu'il y a problème. S'il est aussi impossible de traduire que tu le dis alors il y a tout a parier que ce soit effectivement le cas.
Entre un texte qu'on comprend et sur lequel les deux parties sont d'accord mais qui n'est pas exactement le même que celui que voudrait la FSF .. et un texte qu'on comprend mal et donc qu'on appliquera mal ou qui posera des ambiguité mais qui est exactement celui que veut la FSF .... mon choix est vite fait (pour la première solution)
Et si tu crois que la GPL est simple à comprendre, comptes donc le nombre de troll / engueulades / conflits / débats qu'on a eu sur le texte ici. Même en ne laissant que ceux ou interviennent des gens de bonne foi, renseignés, qui étudient avec détail le texte ... ça en laisse encore beaucoup.
[^] # Re: En langue de Beckham ... Et les cas concrets ?
Posté par Éric (site web personnel) . En réponse à la dépêche Version 3 de la GPL : les coulisses de l'adoption. Évalué à 2.
- déjà parce qu'il n'y a pas besoin de texte écrit pour un contrat ou un accord. Même s'il n'a pas de licence en français ça ne remet pas forcément en cause ses droits. C'est encore plus vrai si la société a reçu quelque chose (par exemple paiement d'une distrib) parce que ça implique une contre-partie donc des droits gagnés pour le particulier (qu'ils soient explicites ou pas)
- la protection est par défaut pour le particulier, je serai même tenté par dire qu'à défaut d'avoir un texte explicite et compréhensible il n'est engagé que par les contraintes qu'on trouve habituellement dans un contexte similaire ou qu'il est en droit d'attendre dans un contexte similaire.
Je doute encore plus que tu puisses décider de lui retirer des droits (sous prétexte qu'il n'a pas de contrat français) que tu a souhaité lui accorder dès qu'il cherche à faire appliquer la loi. Ca serait soumettre l'application de la loi à une condition et je doute que ce soit forcément très bien pris.
[^] # Re: Différentes versions ? Y-a-t-il un choix ?
Posté par Éric (site web personnel) . En réponse à la dépêche Version 3 de la GPL : les coulisses de l'adoption. Évalué à 1.
> devoirs ? La nouvelle version peut-elle être plus restricitive ou, au contraire,
> accorder plus de "libértés" ?
Oui, les deux (si tu accordes plus de libertés à une des parties ça devient plus restrictif pour l'autre). Si tu fais un changement ça va forcément paraitre mieux ou moins bien à quelqu'un.
> Si un soft est publié aujourd'hui en GPL, donc en version 2, lors de la sortie de'une
> nouvelle version, le soft sera-t-il toujours en version 2 ou la license évolue
> directement en version 3 ?
Un soft ne change pas de licence tout seul. Par contre celui qui a un soft en GPLv2 peut décider de le diffuser sous GPLv2 ou GPLv3, au choix.
Donc ton soft restera en v2 à moins que tu changes d'avis et passes volontairement en v3 ou que tu intègres une contrib qui est en v3.
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
> développeurs, sur une durée de 3 ans
Oui, mais des projets de 150 ans/homme on en trouve pas non plus tous les jours. Ca n'est pas forcément représentatif. En tout cas ça ne concerne pas tout le monde.
Mais ce que tu dis ne contredit en rien mes propos. Tu es chef ? tu veux contrôler plus ton projet ? alors tu imposes à tes équipes de passer par l'analyseur qui contrôle les types.
Il n'y a aucune raison pour imposer à sur le langage (donc à tout le monde) juste pour quelques projets de taille énorme. Je ne dis pas que le contrôle est mal, ce que je dis c'est qu'il faut que ce soit un choix, pas une contrainte. Si c'est ton choix ou celui de ton chef tu lances cette vérification, ça s'arrête là.
Puis bon, si tes développeurs sont incompétents ce n'est malheureusement pas un typage statique contrôlé qui va résoudre tes problèmes ;)
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 4.
Intéressant.
> J'aime pas le "si" tu le souhaites. Je préfères que le langage le
> contraigne au développeur, pour le "forcer" à produire un code de
> meilleur qualité.
J'ai toujours eu l'opinion inverse en fait. L'informatique, la programmation, le langage, ce sont des outils pour aider l'utilisateur et le développeur. Dès qu'ils deviennent une contrainte c'est qu'il y a un défaut quelque part dans la procédure.
Si le développeur veux mettre des types partout il faut que le langage lui permette. Si le développeur pense aller plus efficacement sans les contrôles de type à court terme qu'il le fasse aussi. Si tu veux une contrainte alors demande à ton analyseur de code de te mettre un warning à chaque type manquant, mais ce n'est pas le rôle du langage.
Si tu veux forcer une syntaxe limitée pour rendre clair le code je comprend. Par contre je ne vois pas de raison de forcer le développeur à mettre des contrôles s'il n'en veut pas. S'il en veut il est assez grand pour les mettre et demander à un outil de vérifier qu'il les met.
Pour les gains de temps en développement je pense que ça dépend des habitudes. En fait je suis sûr de perdre du temps en typant mais je suis sur que ça se regagne de l'autre coté avec l'IDE qui peut proposer des completion plus pertinentes et plus souvent, ou aider beaucoup plus à la frappe. Ce qui me gêne beaucoup plus c'est la lecture du code qui contient tous les contrôles (types, accès, ...). C'est en général super lourd à lire et ça ça joue beaucoup dans la clarté pour quelqu'un qui n'a pas l'habitude. Je le comprend dans une phase de stabilisation/test, mais dans la phase de développement/conception je préfère un code clair et concis avec le moins de contrôles possibles.
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 3.
> interprétés ne sont justement pas typés fortement, et encore moins
> statiquement.
Typage fort beaucoup de langages le sont (reste à voir ce qu'on met derrière le terme de typage fort mais je pense qu'il y a pas mal de langages qui peuvent valider ça). Typage statique effectivement, c'est moins habituel.
Mon idéal pour le genre d'appli auxquelles je participe ça serait un langage interprété ou semi interprété, types forts, avec un typage statique optionnel et un analyseur de code :
- tu profites de l'interpréteur "ca s'exécute à la moindre modif" voire du "debuggueur en cours de frappe"
- tu profites du typage statique : tu rajoutes les contraintes de type si tu le souhaites là où le code est plus délicat ou si tu souhaites renforcer les contrôles pour valider ton code
- tu as un analiseur potentiellement lent et long qui sait faire de la détection de type quand tu ne l'a pas déclaré toi même, et sait exploiter les types statiques pour vérifier les concordances.
Le problème c'est que je ne suis pas sûr que le tout soit conciliable avec la notion de langage dynamique tel qu'on la voit dans un python ou un ruby
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
Comme quoi ....
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
> Quand tu écris $a = "3 maisons" on lui a assigné une valeur de type chaîne de caractères.
Il n'y aurait pas contradiction entre ces deux phrases ?
Pour moi qu'une fonction gettype() puisse retourner un type déterminé non ambigue et toujours le même dans une situation similaire veut bien dire qu'un tel type existe (contrairement à d'autres domaines, je pense par exemple à sqlite pour qui tout est chaine de caractère et qui ne "résoud" les choses en nombre que lors des opérations genre addition).
> Mais lorsque tu fais $a + 1, si ta variable était de type fort, alors une erreur aurait
> été levée parce que l'on ne peut pas additionner une chaîne avec un entier.
Le fait que tu puisses faire "3 maisons " +1 ne veut pas dire que "3 maisons" n'a pas de type, ça veut dire qu'il y a transtypage implicite (le terme même de transtypage sous entend qu'il y a un type d'ailleurs).
Notes que des transtypages on peut aussi en avoir dans des langages très fortement typés comme en C ou C++ (jamais eu l'avertissement du compilo qui a casté un char dans un int ? un pointeur dans un int ? ou le contraire ?). Ca n'en fait pas des typages faibles pour autant.
> Si par contre, on avait $a = $a + 1 => "3 maisons1" alors on aurait pu dire
> qu'effectivement $a pourrait être de typage fort avec un transtypage implicite
> correcte qui est de convertir l'entier 1 en sa représentation chaîne de caractères
> avant de la passer à l'opération de concaténation '+' (si '+' est l'opérateur de
> concaténation bien sûr)
Ah ? donc si j'emploi l'opérateur de concaténation (en php c'est le point) et que ça donne ce que tu dis c'est un langage typé fort ? planté ... $a = $a . 1 donne effectivement "3 maisons1"
Pourquoi ? la seule différence entre ton $a = $a + 1 => "3 maisons1" et ce qu'il se passe réellement c'est qu'il n'a pas fait le transtypage sur la même donnée que tout. Il a fait le transtypage sur le $a au lieu de le faire sur le 1 (ce qui est plutot intelligent vu que dans l'exemple il s'agit d'une addition et pas d'une concaténation, qui sont des opérateurs différents). Mon addition est une opération qui attend deux nombres, on lui donne une chaine, il convertit donc la chaine en nombre implicitement. Ca ne contredit pas du tout la présence de typage.
Dans l'absolu l'opération est la même (transtypage), les principes mis en jeu sont les mêmes (repérer qu'une des valeurs n'a pas le type attendu et faire un transtypage implicite quand c'est possible pour faire concorder).
Ceci dit ça montre bien ce que je disais : la limite du typage fort et du typage faible n'a rien d'une limite claire et objective (même si on est tous les deux d'accord pour dire que le typage de PHP est on ne peut plus faible)
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
> typage dynamique.
> Moi je te parle de C++, Java ou C#, avec un vrai compilo qui vérifies le typage
> statiquement (quand c'est possible) et vrai IDE.
Tu n'as pas compris. Je parle de développer PHP, pas de développer "avec" PHP. Je parle donc bien de développer en C ou C++ (ici c'était du C++ mais ça ne change pas grand chose) avec un vrai compilo et un typage statique.
Et oui c'était horriblement lent. Dans les dernières phases je passais plus de temps en compil qu'en test/modif
> T'auras beau dire tout ce que tu veux, le compilo fait un nombre incalculable de
> tests, surtout avec un langage à typage fort et statique.
Oui. La question c'est : est-ce qu'il est indispensable que ton langage à typage fort et statique soit un langage compilé pour pouvoir faire ce genre de vérification ? la réponse est "non".
Donc non, que tu le veuilles ou non la compilation n'est pas nécessaire pour ta phase de test et non le fait de vouloir controler tous les types n'est pas une raison pour supporter la compilation.
> Visiblement tu n'as rien compris à ce qu'est un compilo, à ce qu'il est censé faire.
> Il n'est pas censer que "pondre" du code, un compilo c'est avant tout un
> analyseur lexical et syntaxique qui constitue une première couche de TESTS et un
> générateur de code. C'est loin d'être seulement la 2ème partie.
Je ne dis pas le contraire, mais il passe aussi un temps non négligeable sur tout le reste (pour reprendre mon exemple, recompiler les fichiers modifiés c'était rapide, c'était pour reconstruire les libs et binaires derrière avec toutes les liaisons qui était long, et là les contrôles de types et l'analyse lexicale étaient déjà faits).
Que tu veuilles faire toute cette analyse je comprend. Mais non faire toute cette analyse ne justifie pas de passer du temps supplémentaire pour faire la compilation.
Tu peux t'en servir comme ça, mais tu perd inutilement du temps sur des trucs qui ne servent pas à tester, et donc qui sont inutiles à ton but premier.
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
J'en profite pour rappeler que ce qui est sur wikipédia c'est ce que les gens y ont mis, rien de plus (et pas forcément La Vérité Objective)
Le problème du typage fort c'est que même avec ta définition (qui me convient assez bien) c'est assez flou. Exemple avec PHP (typage faible dynamique) :
$a = "3 maisons" ;
echo ($a +1) ; // affiche 4
echo gettype($a) ; // affiche string
$b = "3" ; echo gettype($b) ; // affiche string
$c = 3 ; echo gettype($c) ; // affiche integer
Ma donnée a bien un type clairement défini et non ambigu, simplement on fait des conversions implicites entre les différents types un peu partout. Je suppose qu'on ne peut pas pour autant dire que tous les langages qui proposent des système de conversion implicites sont en typage faible pour autant (sinon on va finir par classer C et C++ dans les typages faibles)
Je pense que les séparations entre faible et strictes n'ont pas vraiment de délimitation forte. C'est plus une histoire de philosophie et d'orientation du langage.
(La question du typage statique/dynamique n'est pas tellement plus facile avec l'arrivée des languages qui savent parfois déterminer seuls les types avant exécution sans que l'utilisateur ne précise rien)
[^] # Re: Ruby On Rails
Posté par Éric (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 3.
Ah ? chez moi les compil prennent du temps. Pour avoir modifié des sources de PHP récement, à chaque modif ça recompilait le fichier, puis l'extension dont dépendait ce fichier, puis la libphp4 avec l'extension en statique (non, dynamique ça collait pas), puis finalement le php-cli qui va avec.
Le tout était *très* loin de la seconde et très loin d'être négligeable.
Et franchement non, la phase de test et la phase de compilation sont deux choses séparées.
Le but de la compilation c'est de produire du code machine. Le but d'une phase de test c'est de vérifier ton code. Certes le gcc pour pouvoir compiler fait des vérifications, mais rien n'empêcherait techniquement une phase de test sans compilation.
Si tu es concerné par les tests/vérifications l'avenir ce sont des outils d'analyse de code qui repèrent les mêmes choses (syntaxe, mauvais appels, contrôles de type, ...). Ca n'impose en rien une compilation (ou plutot ça ne devrait en rien l'imposer) et c'est une mauvaise justification de l'étape compilation.
[^] # Re: Oui et ?
Posté par Éric (site web personnel) . En réponse à la dépêche Une réforme du système des brevets aux Etats-Unis ?. Évalué à 2.
(notes aussi que vu les délais pour envoyer une contestation il suffirait de faire un bref passage par mot clé tous les deux mois pour retirer pas mal de trucs idiots)
Mais bon, je n'étais pas là pour dire "faites le" mais plus pour me poser la question de la bonne foi de ceux qui surveillent déjà tout ça et attendent le lendemain de la validation pour passer l'info.
[^] # Re: Vers un système plus raisonnable...
Posté par Éric (site web personnel) . En réponse à la dépêche Une réforme du système des brevets aux Etats-Unis ?. Évalué à 3.
Par cotnre, si ca permet de prouver la paternité d'une oeuvre intellectuelle, je doute que ce soit valable pour les brevets.
La clause d'invalidité des brevets est bien plus fondée sur la publication que la première paternité. Le fait que tu aies une idée similaire dans une enveloppe fermée n'y changera rien
[^] # Re: Vers un système plus raisonnable...
Posté par Éric (site web personnel) . En réponse à la dépêche Une réforme du système des brevets aux Etats-Unis ?. Évalué à 4.
Non parce que le système des brevets a été mis en place *pour* divulguer ce genre de secret et éviter qu'ils existent (et finissent par se perdre au lieu de profiter à tous). Difficile à ce compte là de reprocher au système de brevet de ne pas rendre possible le secret comme tu en parles.
C'est justement pour empêcher ce qui te semble impossible/difficile (garder l'invention secrête) qu'on fait tout ça. Faudrait pas le perdre de vue.
[^] # Re: lawyer love it !
Posté par Éric (site web personnel) . En réponse à la dépêche Une réforme du système des brevets aux Etats-Unis ?. Évalué à 2.
C'est surtout une clause très importante qui permet de limiter les interprétations multiples d'un brevet.
Ca peut (même si j'en doute) diminuer un peu le commerce de la peur basé sur les brevets. Le "donnes moi des sous parce que tu es sous mon brevet". Là il suffirait de dire "je ne crois pas" pour d'un coup risquer beaucoup moins ... et donc aborder la question du "qui a raison" plus sereinement.
# Oui et ?
Posté par Éric (site web personnel) . En réponse à la dépêche Une réforme du système des brevets aux Etats-Unis ?. Évalué à 6.
Le fait est que si personne ne s'oppose et ne se tient à jour pour tout vérifier ça ne sert à rien. C'est un peu comme les sociétés qui croient que parce qu'elles mettent sous GPL elles vont du jour au lendemain avoir 1500 contributeurs qui vont bosser gratuitement.
(*1) : d'ailleurs, quelqu'un s'est posé la question à propos de ces gens du libre qui ralent après tous les nouveaux brevets idiots le jour de leur sortie ? il suffirait qu'ils regardent les annonces de dépot et pas de publication pour bloquer ces mêmes brevets idiots avant leur validation au lieu de faire semblant d'être impuissants. Je ne veux pas être parano mais ...
Premier inventeur ou premier déposant ? si le but est de révéler les secrets et pas de récompenser la recherche c'est tout à fait cohérent. Sauf erreur de ma part c'est déjà le cas en Europe et personne ne rale la dessus.
> Suppression du "best mode" requirement
Arghhhh, ça veut plus ou moins dire qu'on peut faire un brevet volontairement obscur ou qui n'est pas là pour décrire l'implémentation optimale. On met par terre tout le but des brevets (divulguer la connaissance).
C'est CA qui est dramatique à long terme.
C'est un peu comme si dans la GPL on autorisait la publication des codes sources passés à l'offuscateur.
> et d'éliminer la plupart des causes de batailles judiciaires
C'est un but noble, mais complètement idiot. Quand une trop grosse part des brevets sont abusifs c'est normal qu'il y ait des batailles judiciaires. Ce qu'il faut c'est éviter les brevets abusifs, pas les réduire les possibilités d'attaquer (cf le "best mode" ci dessus).
[^] # Re: Vers un système plus raisonnable...
Posté par Éric (site web personnel) . En réponse à la dépêche Une réforme du système des brevets aux Etats-Unis ?. Évalué à 0.
N'autoriser les brevets que de l'inventeur c'est considérer le brevet comme une récompense à l'innovation ou une contrepartie aux couts de recherche or les brevets sont là uniquement pour favoriser la divulgation des secrets. C'est un peu un "je te payes pour que tu révèles le secret publiquement". Peu importe si ce n'est pas l'auteur qui le fait, le but sera atteint.
> Ce système profite donc encore plus aux sociétés qui ont les moyens
> de déposer et défendre des brevets.
Bof, tant qu'ils imposeront le critère "pas de diffusion publique avant le dépot du brevet" les sociétés comme les particuliers seront dans le même équilibre. Ici un particulier peut autant "piquer" une idée d'une société que le contraire. Et les deux peuvent se contenter d'une diffusion publique pour empêcher le brevet
[^] # Re: Illégal
Posté par Éric (site web personnel) . En réponse au journal OVNI et ARTE. Évalué à 2.
- tu sors du domaine privé
- la copie n'est plus à l'usage du copiste mais à l'usage du demandeur
La copie privée n'est pas concernée ici.
[^] # Re: meuh
Posté par Éric (site web personnel) . En réponse au message sécurité : LOGIN/PASSWORD DANS L'URL. Évalué à 3.
> suffit pour berner ton client, ce qui se fait très bien de la même manière
Le certificat du serveur reste le même. Tous les navigateurs mettent une grosse alerte si le certificat change. Ton attaque man-in-the-middle échouera si la personne est déjà allé sur le site en question auparavant
Même pour la première connexion, le certificat est signé, le navigateur vérifie la signature à chaque fois à partir de sa base d'autorités. Si le méchant n'a pas accès à ta configuration il pourra certes envoyer un faux certificat mais ce faux certificat ne sera pas signé et un avertissement méchant apparait sur ton navigateur.
Non, coté https, si tu n'ignores pas superbement toutes les boites de dialogue d'erreur que t'envoie ton navigateur et que tu ne laisses personne rajouter une autorité de certificat dans ta configuration, tu ne crains pas le man-in-the-middle et le HTTPs est sûr.
SSH c'est la même chose, avec la certification en moins. (on peut très bien certifier mais là il n'y a pas d'autorité centrale que tout le monde reconnait donc ça demande une volonté des deux cotés). Si tu as fait une première connexion correcte tu repèreras tout changement ou toute interception par la suite.