Journal Atheros veut être compatible avec Linux

Posté par  (site web personnel) .
Étiquettes : aucune
0
28
avr.
2008
Bonsoir,

Athreos fabrique des cartes wifi, et était jusqu'a présent supporté par le projet Madwifi¹. Ce projet comportant de nombreuses parties libres, mais il restait un point noir : le HAL, un code objet fermé (bien qu'indépendant du kernel, c'était le même code pour BSD et Linux).

Un HAL libre avait été en projet, mais d'après ce que je sais, il n'était pas très développé. Dernièrement, le projet madwifi a complètement été abandonné pour donner (pour Linux au moins) le driver ath5k². On en avait d'ailleurs parlé ici même³ en septembre dernier lorsque le projet OpenBSD avait repris le code du driver, et changer la licence trop vite.

Le 16 avil dernier, Luis R. Rodriguez a posté sur la liste ath5k-devel un message⁴ que je cite:

Good news. I write to you to inform you that I have decided to join Atheros as a full time employee, as a Software Engineer, to help them with their goals and mission to get every device of Atheros supported upstream in the Linux kernel. I realize there are a lot of challenges ahead but I am well aware of the how the community works and the benefits of working with it and am confident we will find ways to strengthen the relationship between Atheros and the community. I also realize there are a lot of pending questions and perhaps even more now. Please rest assured we are doing what we can to work together as soon as possible.

Si on traduit, cela donne:

Bonne nouvelles. Je vous écrit pour vous informer que j'ai décidé de me faire employer chez Atheros à plein temps comme ingénieur logiciel pour les aider dans leur mission consistant a ce que tous leurs produits soient supportés dans le kernel linux vanilla. Je me rends compte qu'il y a beaucoup de défis qui m'attendent, mais je suis bien au courant de comment la communauté fonctionne et des bienfaits à travailler ensemble, et j'ai confiance que nous trouverons un moyen de consolider la relation entre Atheros at la communauté. je me rend aussi compte qu'il y a beaucoup de questions attendant une réponse, et peut être encore plus à présent. Et restez assuré que nous faisons tout ce qui est possible pour pouvoir travailler ensemble aussi tôt que possible.

Ce qui est intéressant de noter, c'est que Atheros s'inquiète a ce que son métériel soit supporté dans le kernel vanilla. Donc cela eut dire que bientôt, on aura peut être plein de chipset atheros bien supportés dans le kernel sans avoir a rien faire.

On peut penser que cela est du entre autre a l'émergence de périphériques ultraportables comme le eeePc qui sont livrés avec Linux par défaut.

Il reste a espérer que les développeurs OpenBSD auront l'opportunité d'utiliser le code sans trop de problèmes. Soit parce qu'il sera bien documenté, soit parce que la licence leur permettra de le reprendre intégralement.

Sinon, je suis cela d'assez loin, donc je ne peux pas trop vous en dire plus. je ne peux pas non plus vous dire qui est Luis R. Rodriguez, si ce n'est u'il travaille depuis le début sur ath5k

Et merci d'excuser les éventuelles erreurs, il se fait tard :)

Mildred

¹ http://madwifi.org
² http://madwifi.org/wiki/About/ath5k
³ http://linuxfr.org/~IsNotGood/25195.html et http://linuxfr.org/~nicOnicO/25285.html
https://lists.ath5k.org/pipermail/ath5k-devel/2008-April/000(...)
  • # Pas que OpenBSD :)

    Posté par  . Évalué à 9.


    Il reste a espérer que les développeurs OpenBSD auront l'opportunité d'utiliser le code sans trop de problèmes.


    Super article, avec une belle traduction et tout, mais juste un truc:
    Il y a d'autre BSD :)

    Et même certain sont BEAUCOUP plus utilisé qu'OpenBSD !
    • [^] # Re: Pas que OpenBSD :)

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

      Le code sera sous GPL (99% de chance, je suis un peu prophète sur les bords). Il ne pourra pas être réutilisé dans un BSD (à par en le réécrivant).

      Quand à la possibilité de fournir une documentation, on peut rêver je pense (prophète mode 2). De plus en plus de constructeurs fournissent des drivers linux libres, mais sans aucune documentation (on peut penser aux drivers Intel par exemple). Il nous faut donc rétro engineerer le code source Linux en faisant fort attention à ne pas reprendre une seule demi ligne de GPL sinon attention. C'est un peu plus simple que de partir du binaire bien-sûr mais ça reste globalement pas la joie, surtout qu'on a évidemment aucun moyen de maintenir sérieusement le code (le code GPL est maintenu par la société éditrice, quid happen si ils ne veulent plus le maintenir pour leur vieille carte ?), aucun moyen de voir les possibles bugs introduits dans le driver linux, etc ... Je ne sais donc pas si il faut trop se réjouir de ce "nouveau driver libre".

      Le plus simple serait probablement de juste releaser le code source du HAL sous une licence permissive, afin de pouvoir réutiliser le travail de madwifi, travail admirable fait depuis des années par des développeurs BSD et Linux.
      • [^] # Re: Pas que OpenBSD :)

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

        En même temps, la GPL définit le code source comme le format qui est utilisé de préférence pour modifier le logiciel. Donc des codes un peu tordus (précompilés) comme le driver nv sont un peu limite de ce point de vue
      • [^] # Re: Pas que OpenBSD :)

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

        Parce qu'il existe d'autres système libre en dehors de Linux ?

        Le jour où tout les développeurs de logiciels, drivers, librairie ou autres comprendront qu'il existe un monde en dehors de la GPL et que donner l'autorisation de reprendre une parti d'un code source sous BSD n'est pas mortel pour leur travail, on aura bien avancé dans le libre en général (je ne dis pas que c'est le cas de tous et heureusement).

        ps : Pourquoi parler des autres BSD quand OpenBSD est si bien :) (attention troll poilu)
        • [^] # Re: Pas que OpenBSD :)

          Posté par  . Évalué à 1.


          ps : Pourquoi parler des autres BSD quand OpenBSD est si bien :) (attention troll poilu)


          Ba c'est simple, OpenBSD ne fournit pas de beau iso qui vont
          bien ( maintenant si, mais bon, faut bien critiquer ).

          Alors il faut télécharger des iso avec plein de backdoors dedans
          sur des sites russes. Si si, c'est vrai.

          Alors que chez NetBSD, il y a des iso partout, avec même
          plein de packages pour certaines architectures :)

          En plus, NetBSD, c'est mieux.
          • [^] # Re: Pas que OpenBSD :)

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

            Ba c'est simple, OpenBSD ne fournit pas de beau iso qui vont
            bien ( maintenant si, mais bon, faut bien critiquer ).

            Alors il faut télécharger des iso avec plein de backdoors dedans
            sur des sites russes. Si si, c'est vrai.

            quelle mauvaise fois. Quand les isos n'étaient pas distribués, on les créeait soit même, c'est simple, bête et méchant et plus rapide que de trouver le lien vers une image. D'ailleurs je n'ai jamais entendu parler d'un quelconque utilisateur openbsd ayant téléchargé un .iso sur un site de ce genre.
            • [^] # Re: Pas que OpenBSD :)

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

              Cette réponse prouve bien que
              1/ tu as marché dedans bien profond
              2/ que les utilisateurs d'OpenBSD sont des psychorigides incapables de comprendre l'humour (pour bien continuer :D)
              3/ c'est malheuresement vrai. Sans parler d'un site russe avec des cds plein de backdoor, j'ai vu à plusieurs reprises de gens téléchargés sur des isos non officiels faites par des personnes quelconques (comprendre n'ayant rien pour assurer une confiance).
              • [^] # Re: Pas que OpenBSD :)

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

                3/ c'est malheuresement vrai. Sans parler d'un site russe avec des cds plein de backdoor, j'ai vu à plusieurs reprises de gens téléchargés sur des isos non officiels faites par des personnes quelconques (comprendre n'ayant rien pour assurer une confiance).

                Alors que dois je faire quand une personne quelconque installe netbsd sur mon laptop (comprendre que la personne qui le fait n'a rien pour assurer la confiance) ?

                ps : pour tout ceux qui ne sont pas zul (ça en fait du monde), je tiens a préciser que c'est donc zul qui m'a installer netbsd sur mon laptop (vous savez le mec qui troll juste au dessus de moi).

                Sur ce je m'en vais recruter une armée de chats pour coder openbsd ! (la y a rien à comprendre)
              • [^] # Re: Pas que OpenBSD :)

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

                c'est bien gentil de me traiter de psychorigide, mais ce n'est pas de l'humour s'il n'y a rien de drôle. ;-)

                Enfin je sais pas, quand je suis en soirée avec des amis, je n'ai jamais vu quelqu'un évolquer l'absence d'iso chez openbsd pour détendre l'atmosphère. Mais bon je ne suis pas non plus un rat de laboratoire installant des netbsd sur des rasoirs électriques donc mon humour d'être humain normal n'est probablement pas adapté. ^_^
        • [^] # Re: Pas que OpenBSD :)

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

          GNU/Linux sous BSD, c'est pas apple qui s'en plaindrais! :)
  • # Une précision pour un mal comprenant

    Posté par  . Évalué à 4.

    Excuse moi, mais ces histoires de wifi ne sont pas toujours simples à comprendre pour nous autres, personnes à compréhension réduite.
    Est ce que ça veut dire 100% libre? Comme dans "pas de firmware"? Ou ça ne concerne que le pilote, qui deviendrait libre mais il resterait une partie firmware opaque?
    • [^] # Re: Une précision pour un mal comprenant

      Posté par  . Évalué à 9.

      D'après http://linuxwireless.org/en/users/Drivers/ath5k#features :

      "This driver requires no firmware or binary-only HAL!"

      ie " Ce pilote ne requiert aucun micrologiciel, ou couche d'abstraction matérielle uniquement binaire ! " ...



      ... bon, après, je dois avouer que, bien que Debianeux, je ne comprends pas trop le fouin autour des firmwares non libres, du moment qu'ils sont librement redistribuables (ce qu'ils sont déjà loin de toujours être, certes)...

      Je vois un peu ça du même oeil que du matériel non libre, qu'on utilise avec du logiciel libre, et qui ne dérange pas tant de monde que ça... certes, je préfèrerais avoir des firmwares libres, qui tourneraient sur du matériel libre... mais mettre ça au même rang que les blobs en plein kernel ou userland, je trouve qu'il y a de l'abus, et que ça sème plus la confusion qu'autre chose...
      • [^] # Re: Une précision pour un mal comprenant

        Posté par  . Évalué à 4.

        Merci pour la précision.
        ... bon, après, je dois avouer que, bien que Debianeux, je ne comprends pas trop le fouin autour des firmwares non libres, du moment qu'ils sont librement redistribuables (ce qu'ils sont déjà loin de toujours être, certes)...
        Ce n'est pas pour relancer le débat que j'ai demandé, mais pour être certain.
        Au sujet des raisons qui motivent de demander des firmware libres, j'en vois plusieurs. Moins de confusion possible en est une, donc je ne mettrai de toutes façons pas "ça au même rang que les blobs en plein kernel ou userland".
        Mais là on était bien dans le cas blob en userland avec le HAL binaire, non?
        • [^] # Re: Une précision pour un mal comprenant

          Posté par  . Évalué à 5.

          Mais là on était bien dans le cas blob en userland avec le HAL binaire, non?

          Pour ce qui est du HAL binaire qui tourne avec madwifi, oui, complètement.

          Et c'est une très bonne chose qu'on se dirige vers un futur où on en sera débarrassés... d'autant plus s'ils prévoient d'implémenter les "Virtual Access Points" (gérer plusieurs points d'accès complètement distincts, notamment sur le mode de chiffrement) de l'ancien driver, que je trouve, je le confesse, bougrement sexy... chose sur laquelle je peine, à mon grand dam, à trouver des précisions...

          ... et d'autant plus si on n'aura même pas à se soucier d'un firmware...



          Par contre, la confusion que je vois surtout avec la chasse aux firmwares non libres, elle me semble issue de cette chasse même... à la base, on en vient essentiellement à utiliser des firmwares pour ne pas avoir à implémenter du matériel trop spécialisé, qu'il serait plus difficile de débuguer et de concevoir...

          ... mais le firmware reste pour moi du domaine du matériel... avoir un mauvais firmware revient à avoir un mauvais matériel, en ce qui me concerne.... et avoir un firmware non libre, à avoir du matériel non libre.
          • [^] # Re: Une précision pour un mal comprenant

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

            FYI, le support des VAP ont été commité dans FreeBSD le 20 Avril. Ça faisait bien 3 ans qu'ils nous en parlaient, ils l'ont fait (et pas que pour ath, le support est bien évidemment à 90% dans net80211).
          • [^] # Re: Une précision pour un mal comprenant

            Posté par  . Évalué à 1.

            ... mais le firmware reste pour moi du domaine du matériel... et avoir un firmware non libre, à avoir du matériel non libre.
            Entièrement d'accord.

            Par contre, la confusion que je vois surtout avec la chasse aux firmwares non libres, elle me semble issue de cette chasse même...
            Oui, elle vient du fait que ce qui précède n'est pas dit clairement, d'une part. Donc on fait comme si le problème des firmware était un problème de logiciels libres, alors que c'est un problème de matériel libre.

            Mais de l'autre coté, à accepter et à s'habituer à avoir des firmware pas libre, on laisse le champ libre aux fabricants pour mettre dans celui ci des fonctions qui devraient être dans le pilote. (La situation du wifi est assez particulière pour montrer qu'il y a un problème particulier, et du coup, cette news est assez importante, je trouve.) D'où un autre type de confusion.
            Ca dérive même ensuite jusqu'à des appareils comme la freebox et sa notion de "firmware". Et là on est bien dans le domaine des logiciels pas du matériel mais la confusion est possible parce que le terme est le même.

            ... et d'autant plus si on n'aura même pas à se soucier d'un firmware...
            Tout à fait, et un autre avantage que je vois est au niveau de l'intégration dans les distributions. C'est juste pratique, moins stratégique, mais c'est important.
      • [^] # Re: Une précision pour un mal comprenant

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

        Pour moi avoir un firmaware non libre est équivalent à avoir un OS non libre. Après tout l'OS est au PC ce que le frimware est aux autres appareils électroniques programmable. Donc l'intérêt d'une généralisation des firmware libre me paraît évident : on ne pourrait plus avoir de compagnies qui construise des gammes virtuelles de produits par simple bradage logiciel par exemple. On pourrait (théoriquement) avoir un meilleur contrôle de ce que fait son materiel.

        Pour être un peu plus concret on peut prendre des exemples issues du domaine de la photographie numérique : les appareils photos modernes sont de petits ordinateurs. Ils font par défaut tout un tas de traitement sur leurs entrées pour produire in fine des fichiers standards comme des jpegs. Mais certains utilisateurs préfèreaient pouvoir faire d'autres traitements sur les données que ceux proposés par le constructeur : avec un firmware libre des projets de firmware alternatifs seraient beaucoup moins difficile à développer et les résultats seraient bien plus probant que ce qui se fait actuellement. Autre exemple : les appareils photos numériques à objectifs échangeables olympus et panasonic sont sensés utiliser un standard de monture et de communication ouvert appelé four-thirds. Pourtant les communications se font très mal entre les appareils des deux marques. C'est assurément liés au fait que les deux tiennent à garder fermer et secrets leurs algorithmes et firmwares. Enfin, il arrive que les firmware propriétaire soit buggés. C'est le cas par exemple de ceux des appareils olympus et certains utilisateurs en essayant de faire des mises à jour de ces programmes se sont retrouvés avec du materiel inutilisable (reset impossible) à cause des logiciels alors qu'il n'y avait aucun dommage materiel. Je ne doute pas qu'avec des codes ouverts les programmeurs auraient pu réagir bien plus promptement à ce genre de problèmes !

        Conclusion : il me semble que ce serait vraiment super d'avoir des firmware ouverts. Cela améliorerait surement les performances de nombreux produits et leurs capacités à satisfaire leurs utilisateurs. Mais surtout, à une époque ou les appareils électroniques assurent de plus en plus de fonctions et pourraient facilement se transformer en serviteurs de quelques bigbrothers privés, cela permetrait de redonner un peu de confiance à des consommateurs qui retrouveraient alors leur statut de citoyens à part entière...

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: Une précision pour un mal comprenant

          Posté par  . Évalué à 4.

          > Pour moi avoir un firmaware non libre est équivalent à avoir un OS non libre
          Je ne suis pas d'accord. Premièrement, un firmware tourne sur le périphérique directement et non pas sur la CPU, deuxièment, le firmware est censé remplacer la logique câblée pour des raisons de coûts. Le firmware peut-être considérée comme faisant partie du matériel. Normalement, le firmware ne doit pas sortir du périphérique mais pour des raisons de "flexibilité", on utilise de la mémoire volatile pour stocker celui-ci ce qui implique le pilote doit le recharger à chaque redémarrage. Demander le firmware pourrait être assimilé à demander les schémas électronique ou le source HDL de ton matos.

          Le pilote ou la HAL, elle tourne sur le même CPU que le noyau, tourne dans le même processus. La problématique n'est donc pas la même.

          Là, où je te rejoins est que la prochaine étape du logiciel libre sera de libérer les firmwares notamment le BIOS/EFI etc ...
          • [^] # Re: Une précision pour un mal comprenant

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

            Pour le Basic_Input_Output_System cela a l'air de bien avancer avec le projet linuxbios renommé en http://www.coreboot.org : il y a quelques cartes mères qui fonctionnent tout de même http://www.coreboot.org/Supported_Motherboards

            À la base, le firmware - traduit par Micrologiciel - cela reste du logiciel, exécuté sur un CPU ou assimilé, même si c'est celui du périphérique et non de l'unité centrale. La question de sa licence se pose dès lors qu'il est distribué.
            Les constructeurs nous ont habitués jusqu'à maintenant à des licences plus folkloriques les unes que les autres (propriétaire bien sûr... voire non distribuable dans la plupart des cas) ; quitte à demander une licence distribuable (comme une Licence_BSD 2-clauses), autant pousser jusqu'à avoir le code source ET les spécifications : cela permettra la correction de bugs effectivement, améliorera ipso-facto l'interopérabilité particulièrement importante dans le domaine des périphériques et permettra de progresser vers du tout libre.
            Cela bénéficie à l'utilisateur final mais aussi aux intermédiaires : bien souvent le constructeur ne fait qu'assembler des composants d'autres constructeurs, mais au final c'est bien lui qui doit s'assurer qu'il y a une intégration et une interopérabilité correcte, dans ces cas-là disposer du firmware en libre peut simplifier la situation (pourquoi embarquer un correctif dans le pilote lorsqu'il pourrait corriger le firmware ? et inversement).

            À ce titre, les personnes de OpenBSD font un travail efficace pour les pilotes, à coup de rétro-ingénierie coûteuse en temps, ce qui bénéficie tant au kernel *BSD qu'à Linux. Il y a aussi le projet de Greg Kroah Hartman dont le projet [http://www.linuxdriverproject.org/twiki/bin/view] a recensé 300 développeurs prêts à travailler sur des pilotes libres si les spécifications leur sont fournies
            http://www.kroah.com/log/linux/linux_driver_project_status-2(...)
          • [^] # Re: Une précision pour un mal comprenant

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

            > un firmware tourne sur le périphérique directement

            Exactement, le firmware est l'OS du périphérique en quelque sorte.

            > Le firmware peut-être considérée comme faisant partie du matériel.

            Il y en a qui ralent quand un fabriquant de PC dit que l'OS fais partie du matériel.
            • [^] # Re: Une précision pour un mal comprenant

              Posté par  . Évalué à 2.

              > Exactement, le firmware est l'OS du périphérique en quelque sorte.
              Tout dépends ce que tu appelles un firmware, si tu me parles du firmware de ton baladeur numérique, c'est effectivement un OS complet mais ce n'est pas le cas du firmware de ton graveur DVD.
              Un point distinctif est que contrairement au second, le premier ne peut pas être remplacé par de la logique câblée.

              > il y en a qui ralent quand un fabriquant de PC dit que l'OS fais partie du matériel.
              Je doute qu'on puisse remplace un OS par de la logique câblée.
              • [^] # Re: Une précision pour un mal comprenant

                Posté par  (site web personnel, Mastodon) . Évalué à 5.

                bien sûr que si on peut. La logique câblée étant Turing complet, rien ne s'y oppose si ce n'est peut-être le coût.

                Mes livres CC By-SA : https://ploum.net/livres.html

                • [^] # Re: Une précision pour un mal comprenant

                  Posté par  . Évalué à 3.

                  J'aimerais bien voir un OS complet en logique câblé.
                  Sur un plan théorique, c'est possible mais en pratique c'est autre chose, le coût financier n'est pas le seul obstacle.
                  à côté, réécrire Linux en brainfuck c'est du pipi de chat.
                  • [^] # Re: Une précision pour un mal comprenant

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

                    l'ENIAC ? :D (en plus ça fait longtemps qu'il existe)
                  • [^] # Re: Une précision pour un mal comprenant

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

                    Et est-ce possible en pratique de refaire le firmware d'une carte wifi, voir d'un lecteur optique (avec tout les drm) en logique cablée ?
                    • [^] # Re: Une précision pour un mal comprenant

                      Posté par  . Évalué à 3.

                      Tout ce qui est programmable est faisable en logique cablée.
                      Après tout n'est que rapport prix / complexité / performance / ce que tu veux.

                      En général on voit des graphiques qui montre que plus la complexité augmente plus la logique cablée est chère.
                      • [^] # Re: Une précision pour un mal comprenant

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

                        Oui, donc la supposée distinction entre OS et firmware « qui fait partie du matériel » donnée par GeneralZod ne tient pas la route :-)
                        Probablement car il n'y a justement pas de distinction.
                        • [^] # Re: Une précision pour un mal comprenant

                          Posté par  . Évalué à 2.

                          Essentiellement, non...

                          ... mais j'achète un ordinateur pour y mettre ce que je veux, comme par exemple un OS libre (ou pas... enfin, ça fait longtemps, que "ou pas", sur mes PC et assimilés, modulo ce que les gens peuvent trimballer dans leurs sacs quand ils viennent à me rendre visite)... j'achète une carte wifi pour établir une connexion sans-fil (voire en surveiller, tout au plus)...

                          Les versatilités respectives des deux catégories d'artefact ne sont quand même pas identiques, pour le commun des mortels...



                          ... en outre, on trouve beaucoup de choses qui demandent d'y injecter un firmware, pour éviter la lourdeur de la logique câblée... mais si les firmwares libres devaient s'imposer, il ne faut pas rêver : les constructeurs reviendraient à des limitations en hard pour ce qui est de différencier les capacités de gammes de matériels qui ne diffèrent aujourd'hui que par le firmware, et pas physiquement... pour ce qui est du matériel destiné à des marchés de niches, vendu à une différence de prix pouvant aisément flirter ou cumuler l'ordre de grandeur, c'est d'ailleurs le cas, alors que le matériel, à une ou deux résistances prêt, est identique aux gammes pour les grouillots dont la plupart, moi le premier, sont (je pense notamment aux GPU "pro")...

                          Pour ce qui est du wifi d'ailleurs, régulations de ce qu'on peut faire sur les ondes radios obligent, il y a fort à parier qu'on doive se coltiner soit des limitations physiques du hard, soit des limitations codées dans le firmware... si l'on se débarasse des deuxièmes, il y a légalement peu de doutes quant à ce qu'on doive subir les premières... et face à un noyau qui implémente ces régulations légales dans un blob (comme les cartes Intel post IPW2xxx, avant la migration des régulations dans le firmware), personnellement, ça me semble être un moindre mal.



                          Maintenant, loin de moi l'idée de ne pas souhaiter la venue de matériel libre... pour utiliser avec mes OS libres... mais ce sont pour moi deux luttes distinctes, et il ne me paraît pas absurde que la première ne soit qu'une suite, sans corrélation absolue, à la deuxième... par contre, les confondre me paraît un peu trop intégriste (sans connotation fondamentalement négative, pour l'intégrisme, sinon, je n'aurais pas ajouté le "trop" : je ne vois conceptuellement rien de mal à être intègre... juste qu'à l'être trop, on en vient à être, probablement trop également, idéaliste... voire rêveur ; et on peut s'y perdre).
  • # Non, ce sont des devs. Linux qui ont tenté de changer la licence

    Posté par  . Évalué à 10.

    On en avait d'ailleurs parlé ici même³ en septembre dernier lorsque le projet OpenBSD avait repris le code du driver, et changer la licence trop vite.

    Sauf que c'est exactement l'inverse.

    Les développeurs OpenBSD (en particulier Reyk Floeter) ont développé le driver (basé sur un travail initial de Sam Leffler pour FreeBSD), et surtout ce HAL libre par rétro-engenérie.

    Certains développeurs linux ont assez longuement fudé sur la légalité de ce HAL libre (arguant qu'il n'aurait pas été rétro-engéniré dans les règles de l'art), jusqu'à ce que le Freedom Law Center se penche sur le cas et publie un communiqué lavant le code de tout soupçon.

    Peut de temps après, un développeur du projet ath5k (vaguement soutenu par quelques camarades) a décidé de récupérer tout ce bon code d'OpenBSD, sous licence ISC, de trasher la licence et de coller une GPL à la place. Sûrement histoire de favoriser les échanges cordiales entre projets.
    • [^] # Re: Non, ce sont des devs. Linux qui ont tenté de changer la licence

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

      En effet, il y a eue une confusion avec le code du drivers RE pour les puces Broadcom.
      Et là, effectivement, openBSD c'est servi en changeant la licence.
      Voire http://thread.gmane.org/gmane.linux.kernel.wireless.general/(...) et la réponse de Théo qui nie le probléme !

      1 faute partout, balle au centre.
      • [^] # Re: Non, ce sont des devs. Linux qui ont tenté de changer la licence

        Posté par  . Évalué à 2.

        Et là, effectivement, openBSD c'est servi en changeant la licence.
        Voire http://thread.gmane.org/gmane.linux.kernel.wireless.general/(...) et la réponse de Théo qui nie le probléme !


        Mais combien de fois faudra-t-il le répéter avant que les gens arrêtent de propager ces mensonges...
        Theo n'a jamais nié le problème. D'ailleurs, dès que Theo et le développeur en question a eu vent du problème, ils ont immédiatement supprimés le code.
        • [^] # Re: Non, ce sont des devs. Linux qui ont tenté de changer la licence

          Posté par  . Évalué à 4.

          Mais combien de fois faudra-t-il le répéter avant que les gens arrêtent de propager ces mensonges...
          Euh c'est pas un mensonge.

          Theo n'a jamais nié le problème.
          Théo a lancer un énorme troll en disant que c'est anormal d'avoir osé dire ça sur une mailing list , et il l'a insulter copieusement.
          Il a toujours évité le problème et a toujours dis que c'était "une simple erreur". Niveau reconnaissance du problème on a déja vu mieux.
          Donc applique tes propres considérations :
          Mais combien de fois faudra-t-il le répéter avant que les gens arrêtent de propager ces mensonges...

          le développeur en question a eu vent du problème, ils ont immédiatement supprimés le code.
          Oh la version "a l'eau de rose".
          Les dvp ont dis sur la mailing list y'a peut etre un probleme ET ILS ONT PROPOSE DE RELICENCER AU CAS PAR CAS.
          théo est partis sur ses grand chevaux.
          et l'autre dvp a dis "Vu que vous êtes méchant avec moi, j'enleve tout et je vais bouder dans ma chambre".
          • [^] # Re: Non, ce sont des devs. Linux qui ont tenté de changer la licence

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

            Ben le truc c'est que c'est parti d'un malentendu et d'une erreur personnelle du dev en question.

            Il voulait tester des choses avec le code gpl avant de réécrire certaines parties et au lieu de garder tout ça dans un cvs privé il l'a mis dans le cvs openbsd. Donc il n'était pas publiquement distribué à proprement dit (le code était sur le cvs, mais pas utilisé dans l'OS et à usage unique de ce dev sans qu'il n'en soit fait publicité), mais téléchargeable par tout un chacun quand même. Il l'aurait posé sur un serveur ftp ouvert au net mais sans que ça se sache ça aurait été la même chose mais personne ne l'aurait su/vu et ça n'aurait pas été grave du tout.
            • [^] # Re: Non, ce sont des devs. Linux qui ont tenté de changer la licence

              Posté par  . Évalué à 2.

              ça n'aurait pas été grave du tout.
              Le mail de départ n'était pas grave du tout non plus. (il y a toutefois quand même :
              - plusieurs commits
              - virage du fichier de licence itou et relicencing derrière. Pourquoi faire ça "juste pour travailler" ? Pourquoi faire des commits si il faut pas les faire ?
              - Certains stipulaient que la branche était utilisé par bien plus que seulement ce dvp)
              Il disait juste qu'il pensait qu'il y avait des problèmes, et qu'ils étaient tout a fait prêt à relicencier au cas par cas.

              Ensuite théo est venu les traiter d'inhumain et (celle la elle est génial) incapable de comprendre la moindre psychologie humaine. (Voui j'aime bien le gars qui insulte tout le monde a tour de bras qui fait une leçon de psychologie c'est assez poilant).
              [bien entendu je laisse tomber les autres insultes, nombreuses, et le manque d'argument de théo].

              bref c'est bien le chef de projet d'openbsd qui est venu foutre la merde (comme d'hab diront certains).
              • [^] # Re: Non, ce sont des devs. Linux qui ont tenté de changer la licence

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

                Le mail de départ n'était pas grave du tout non plus. (il y a toutefois quand même :
                - plusieurs commits
                - virage du fichier de licence itou et relicencing derrière. Pourquoi faire ça "juste pour travailler" ? Pourquoi faire des commits si il faut pas les faire ?


                Il me semble que s'ils bossaient dessus et comptaient supprimer au fur et à mesure le code gpl, il fallait bien y faire des commits ;)

                Même chose pour le virage du fichier de licence, s'il commençait à supprimer la partie GPL, et qu'il comptait à terme inclure dans openbsd uniquement en BSD, il n'avait aucune raison d'uploader le fichier de licence dans le cvs ni d'y garder ces mentions. Faut vraiment se mettre du point de vue du gars qui a mis un truc online non pas pour le distribuer explicitement mais uniquement dans une question pratique (cvs backupé, utilisable par d'autres devs qui pourraient l'aider).

                C'est sur qu'il a merdé et qu'il y aurait eu meilleure manière de faire. Mais à la base ça reste un malentendu.

                Pour la suite de ce qu'il s'est passé, je conviens que Théo s'est enflammé à son habitude. Je pense d'ailleurs que son splendide partage en vrille a été démultiplié (en plus de son caractère bien connu) par le fait qu'il ait été blessé dans son orgueil de libriste hardcore. ça doit faire mal quand tu prêches le libre de voir qu'un de tes ouailles à mis du code sale sur le cvs de ton projet.

                Ce que je veut dire par la, c'est qu'il n'y a eu à mon avis aucune intention de nuire.

                Dans le cas de Atheros/madwifi, j'ai le sentiment qu'il y'a eu du changement de licence à l'arrache dans une volonté politique de supprimer la BSD de ceux-ci.

                Après c'est mon interprétation.

                Dans la réalité il y'a eu faute (intentionnelle ou pas) dans les 2 affaires. Ce qui compte c'est que ce soit réglé même si l'est regrettable que la communication (voire même non communication) qui a été faite à ces 2 occasions ait été préjudiciable pour les projets concernés.

                L'épisode OpenBSD/Atheros/madwifi a d'ailleurs montré à quel point les licences et les lois sont facilement mal interprêtées (y compris par des gens qui y sont confrontés quotidiennement) et que c'est un domaine non trivial pour l'utilisateur lambda. Dans ce sens je préfère les licences plus simples et courtes comme les MIT/BSD/ISC aux licences de la FSF que je trouves trop longues, obscures et laissant trop de points sujets à interprétation (comme le montre les débats concernant la freebox). Quite à ce que ça arrange certains crevards qui font du proprio avec. Mais bon tant que ça n'annule pas ma propre liberté.
          • [^] # Re: Non, ce sont des devs. Linux qui ont tenté de changer la licence

            Posté par  . Évalué à 1.

            Il a toujours évité le problème et a toujours dis que c'était "une simple erreur".
            Non, il n'a jamais évité le problème. Il a reconnu qu'un dev avait fait une erreur, et le code a été retiré immédiatement. Je ne vois pas ce que tu veux de plus...

            théo est partis sur ses grand chevaux.
            Les développeurs d'openbsd ont une vision du logiciel libre qu'ils ne partagent avec peu de gens, c'est vrai. Le fait d'hurler sur tous les toits "vous nous avez volés volontairement du code blahblahblah" ce n'est pas règlo. Joindre les développeurs en privé aurait été aussi efficace.
            • [^] # Re: Non, ce sont des devs. Linux qui ont tenté de changer la licence

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

              Joindre les développeurs en privé aurait été aussi efficace.

              Mais ça n'aurais pas permit de contrebalancer la légende urbaine que les devs d'openBSD respectent toutes les licences.
              Et en plus, un vendeur proprio recuperant le CVS aurait pu dire de bonne fois que le code était BSD ...
              C'est pour cela qu'il fallait faire du full disclosure.
            • [^] # Re: Non, ce sont des devs. Linux qui ont tenté de changer la licence

              Posté par  . Évalué à 0.

              Il a reconnu qu'un dev avait fait une erreur
              Tu veux dire qu'il a reconnu que le dev avait fait une erreur en traitant la personne disant qu'il y avait pe un problème de licence "d'inhumain" ?
              Pour moi c'est pas "reconnaitre qu'un dev a fait une erreur".
              Quand on reconnait une erreur, on s'excuse, on insulte pas.


              Les développeurs d'openbsd ont une vision du logiciel libre qu'ils ne partagent avec peu de gens, c'est vrai.
              Ca doit etre la vision "je peux vous insulter tout mon soul car vous osez nous avertir qu'on a fait une erreur" .
              C'est sur qu'assez peu de gens sont comme ça, et d'ailleurs heureusement pour tout les autres dvp un tant soit peut respectueux des autres.

              Ps : non balancer sur une mailing list public une erreur n'est pas une demande de pendaison publique.
              Ca peut avoir des TAS de très bonne raison :
              - Montrer (comme dis dans un autre commentaire) qu'openbsd fait aussi des erreurs, donc que théo arrête un peu d'insulter tout le monde et de les traiter comme de la merde. (on l'a d'ailleur vu lorsqu'il a essayé de se faire mousser sur openssh dans le thread)
              - Permet de toucher le maximum de personne concerné (vu que le cvs était publique, le publique était concerné, ne t'en déplaise : certains utilisateurs du cvs ont très bien pu l'utiliser).
              - Le ton utilisait ne jettait l'opprobe sur PERSONNE. Il énoncait que des faits et proposait des solutions.
              Franchement ca aurait couter quoi de dire
              "Ah oui effectivement vous avez raison.
              Je pensais pas le commiter sur un cvs publique. J'ai utilisé ce code comme base pour mon driver. Je vous re contacte directement par mail afin de discuter plus en avant des possibilité proposée".
              Rien que dalle nada niet.
              Ah si, ca montrerait que les dev d'openssh sont conscient des problèmes de licence, et cherche a résoudre proprement et efficacement tous les problèmes qu'ils rencontrent, tout en étant modeste (acceptant la critique).
              Errare humanum est. Persevare diabolicum est. (ou un truc comme ça).
              - ET SURTOUT : ca permet d'éviter de se faire insulter en "one way" par théo! Et rien que pour ça, je l'aurais foutu en publique, pour éviter toute désinformation du champion de la mauvaise foi (meilleure que moi, c'est dire) et de l'insulte qu'est théo!
    • [^] # Re: Non, ce sont des devs. Linux qui ont tenté de changer la licence

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

      Merci de la correction, en effet j'ai du confondre :)

Suivre le flux des commentaires

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