Journal Fin du support du forum SMF pour Joomla

Posté par  .
Étiquettes : aucune
0
31
juil.
2007
Joomla [1] est un système de gestion de contenu (CMS), puissant et reconnu, sous licence GPL.

Son seul manque est l'absence d'un forum, mais sa modularité permet de développer des interactions avec d'autres programmes.

SMF [2] (simplemachines) est un bon forum sous sa propre licence [3] pas tout à fait open-source. En gros la licence permet d'avoir accès au code source, de modifier le code, mais pas de redistribuer le code. Les modifications doivent être diffusées à part.

L'équipe de SMF a développé un bridge permettant à SMF de s'intégrer à Joomla. Le 24 juillet, SMF annonce [4] [5] ne plus maintenir ce bridge. En effet l'équipe Joomla a décidé de revoir la manière dont elle entend appliquer la licence GPL, et ne tolère plus que les extensions qui sont également sous GPL, et ce de manière rétroactive.

Le 21 juillet Joomla a publié une version mineure de sécurité (1.0.13). Malheureusement cette version ré-écrit en grande partie le système d'authentification et casse l'interopérabilité avec le bride SMF.

De nombreux utilisateurs (dont moi) sont donc coincés: soit garder une version de Joomla ayant des failles, soit mettre à jour et abandonner le forum.

Mon coup de gueule contre Joomla, est que tout d'abord ils utilisent pour leur propre site le forum SMF. Ce qui m'avait d'ailleurs influencé à l'époque lors de mon choix d'un forum à intégrer à Joomla.
De plus ils promeuvent sur leur propre site des extensions qui ne sont pas sous GPL ! [6]
Enfin la mise à jour mineure qui casse complètement la gestion des mots de passe laisse un goût amer.


[1] http://www.joomla.fr (fr)
http://www.joomla.org/ (us)
[2] http://www.simplemachines.org (us)
[3] http://www.simplemachines.org/about/license.php
[4] http://www.simplemachines.org/community/index.php?topic=1845(...) (annonce)
[5] http://www.simplemachines.org/community/index.php?topic=1845(...) (blog de discussion de l'annonce)
[6] http://extensions.joomla.org/component/option,com_mtree/task(...)
  • # faut pas s'étonner

    Posté par  . Évalué à -2.

    Quan on voit ça :
    Copyright © 2005-2006 - All Rights Reserved


    en bas du site, faut pas s'étonner de voir quelques anachronismes...
    • [^] # Re: faut pas s'étonner

      Posté par  . Évalué à 0.

      pourquoi ce moinssage ? il n'y a pas vraiment de logique à placer un tel copyright sur un site présentant des informations concernant un produit sous GPL, et d'autres infos concernant d'autres produits sous GPL... non tous les droits ne peuvent être réservés puisque les produits sont sous GPL... et il n'est pas logique non plus de dire "SMF sapucépalibre faut plus l'utiliser" et l'utiliser soi même...
  • # Heu... Y'a un attention en rouge à lire aussi

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

    Y'a ça sur leur page d'accueil aussi :

    ATTENTION: si vous utilisez des composants de type bridge (SMF), Community Builder, ou autres composants modifiant le noyau Joomla! (GMAccess, JACL...), attendez avant d'effectuer la mise à jour; des dysfonctionnements ont déjà été constatés avec la version 1.0.13.


    Donc il faut attendre... Enfin d'après ce qui est écrit sur leur page d'accueil.
  • # Excellent exemple !

    Posté par  . Évalué à 8.

    Voici une parfaite illustration de l'adage: quand c'est pas libre... c'est pas libre... SMF n'est pas libre, quand on l'utilise on s'expose à ce genre de problème. Ce n'est pas contre Joomla qu'il faudrait se révolter...
    • [^] # Re: Excellent exemple !

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

      Mouais, pas convaincant ton argument : si SMF avait été sous une autre licence validée par l'OSI autre que GPL, le problème aurait été le même. d'après le journal, Ils ont l'air d'accepter que ce qui est GPL, donc si ta licence libre n'est pas compatible GPL, t'es aussi mort.

      Bon, après, il est clair que SMF n'est pas libre (pas de redistribution), je le note aussi car je n'avais pas fais gaffe et pensais l'utiliser un jour, maintenant en ayant lu la licence ça me calme pas mal. le "Free" sur leur page d'accueil est au sens gratuit, pas libre.
      • [^] # Re: Excellent exemple !

        Posté par  . Évalué à 3.

        J'aurai peut-être dû développer car je me suis mal fait comprendre: le problème semble bien venir de SMF qui n'est pas libre: si des dév (comme ceux de Joomla l'ont visiblement fait pour leur site) adaptent SMF pour la nouvelle interface avec Joomla, les modifs de SMF ne sont pas distribuables car SMF n'est pas libre.
        Le voilà le problème.
        • [^] # Re: Excellent exemple !

          Posté par  . Évalué à 1.

          Ils peuvent distribuer les modifications de SMF, la seule obligation est de les distribuer à part.
          • [^] # Re: Excellent exemple !

            Posté par  . Évalué à 1.

            Du coup, pour redistribuer le patch qui permettra à SMF de tenir compte du nouveau système d'authentification, ça va être coton...
            Donc, il faudra attendre le bon vouloir de l'éditeur de SMF ou que chacun patche son SMF :-/
            • [^] # Re: Excellent exemple !

              Posté par  . Évalué à 1.

              L'editeur a fait son choix, tant que la position de Joomla sur l'interprétation de la GPL n'est pas modifiée, il ne supporte plus le bridge SMF <-> Joomla.


              Du coup, pour redistribuer le patch qui permettra à SMF de tenir compte du nouveau système d'authentification, ça va être coton

              À coup de «diff -u» et de «patch», je vois pas où est le problème.
            • [^] # Re: Excellent exemple !

              Posté par  . Évalué à 2.

              Du coup, pour redistribuer le patch qui permettra à SMF de tenir compte du nouveau système d'authentification, ça va être coton...

              Pourquoi ?

              Rien n'empèche l'installeur d'appliquer le patch de manière automatique. C'est ce qui est fait dans un grand nombre de ports sous FreeBSD et cela ne pose aucun problème !

              Pour ce que j'ai compris de la license n'est pas interdit de distribuer SMF et patch ensemble, à condition que le patch ne soit appliqué qu'une fois sur le poste client.
              • [^] # Re: Excellent exemple !

                Posté par  . Évalué à 1.

                Rien n'empèche l'installeur d'appliquer le patch de manière automatique.


                Pour ce que j'ai compris de la license n'est pas interdit de distribuer SMF et patch ensemble, à condition que le patch ne soit appliqué qu'une fois sur le poste client.


                Non, non, ceci n'est pas aberrant...
                • [^] # Re: Excellent exemple !

                  Posté par  . Évalué à 2.

                  Non, non, ceci n'est pas aberrant...

                  Pas plus que ce qui est demandé par certaines licences pourtant dites libres, à commencer par celle de la MoFo.

                  Ils veulent que l'on puisse parfaitement faire la différence entre le travail de SMF et les diverses contributions non intégrées dans la version officielle en interdisant un fork de cette dernière. C'est en désaccord avec l'esprit de la GPL, mais c'est leur choix et ce n'est pas pire que ce que l'on voit dans d'autres licences. Là, on a au moins accès aux sources, certaines modifications sont commitées... symplement, ce qui nést pas commité doit ressté a l'état de patch.

                  Ensuite, je suis d'accord, tant qu'à choisir moi aussi j'aurai préféré que la license soit de type BSD...
                  • [^] # Re: Excellent exemple !

                    Posté par  . Évalué à 2.

                    Ils veulent que l'on puisse parfaitement faire la différence entre le travail de SMF et les diverses contributions non intégrées dans la version officielle en interdisant un fork de cette dernière.


                    Ben non, justemment si la procédure d'installation avec patch est complètement automatique (comme tu le fais remarquer dans ton post précédent) on ne fait pas la différence entre l'original et le fork. Il n'y a que des inconvénients:

                    - pour le contributeur qui ne peut pas fournir directement son travail

                    - pour le packageur qui a du boulot d'automatisation en plus

                    - pour le dev original dont l'esprit de sa licence n'est pas respecter (même si la lettre l'est)

                    - pour l'utilisateur qui n'a pas un packaqge directement (par exemple pour il devrat éventuellement y avoir une étape de compilation et donc nécessite tout un environnement spécifique)

                    Bref, une aberration.
  • # Pour info

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

    leur position sur le libre et la GPL :
    http://www.simplemachines.org/about/opensource.php

    Avec une argumentation un peu foireuse (en gros, ils ont pas envie qu'on les forke si ils ne foutent plus rien), mais c'est leur choix :
    the reason is that although we believe in giving back to the Open Source community, we also believe that the volunteers that make up this project deserve the credit. On top of that, allowing unlimited redistribution encourages project forking and could lead to confusion about what versions are supported. By maintaining and allowing only a single version of each of our products, we can ensure the integrity of the code base while making sure that the quality of each product is maintained. So, you could say that everyone wins from it.
  • # GPL ou pas GPL...

    Posté par  . Évalué à 1.

    Joomla [1] est un système de gestion de contenu (CMS), puissant et reconnu, sous licence GPL.
    GPL ! bien !

    Son seul manque est l'absence d'un forum, mais sa modularité permet de développer des interactions avec d'autres programmes.
    Donc, comme la plupart des CMs, il y a une base et des plugins... jusque là, tout est normal...

    SMF [2] (simplemachines) est un bon forum
    Je n'en doute pas l'ayant moi même essayé par la passé... Mais il y en a d'autres...

    sous sa propre licence [3] pas tout à fait open-source.
    En gros la licence permet d'avoir accès au code source, de modifier
    le code, mais pas de redistribuer le code. Les modifications doivent être diffusées à part.

    C'est la raison pour laquelle j'ai laissé tombé le forum...

    L'équipe de SMF a développé un bridge permettant à SMF de s'intégrer à Joomla.
    Ça me fait penser aux connecteurs Outlook :-)

    Le 24 juillet, SMF annonce [4] [5] ne plus maintenir ce bridge.
    En effet l'équipe Joomla a décidé de revoir la manière dont elle entend appliquer la licence GPL, et ne tolère plus que les extensions qui sont également sous GPL, et ce de manière rétroactive.

    Clap Clap Joomla !

    Le 21 juillet Joomla a publié une version mineure de sécurité (1.0.13).
    Malheureusement cette version ré-écrit en grande partie le système
    d'authentification et casse l'interopérabilité avec le bride SMF.

    Si seulement SMF avait été GPL... aaaaahhh...

    De nombreux utilisateurs (dont moi) sont donc coincés:
    Ce qui n'eut pas été le cas avec un autre forum

    soit garder une version de Joomla ayant des failles, soit
    mettre à jour et abandonner le forum.

    Comme quoi, être GPL dès le début évite bien des ennuis...

    Mon coup de gueule contre Joomla,
    Conter Joomla ?
    ah bah merde, je pensais que tu gueulais contre la licence à la con de SMF...

    est que tout d'abord ils utilisent pour leur propre site le forum
    SMF.

    Ah les salauds !

    Ce qui m'avait d'ailleurs influencé à l'époque lors de mon choix
    d'un forum à intégrer à Joomla.

    Tu aurais en tester plusieurs et tu aurais vu que les forums sont
    souvent kif-kif, et tu en aurais peut-être pris un en GPL...

    De plus ils promeuvent sur leur propre site des extensions qui ne sont pas sous GPL !
    Ah les re-salauds !

    Enfin la mise à jour mineure qui casse complètement la gestion des mots de passe laisse un goût amer.
    C'est normal, c'est un goût non-libre ;-)
    • [^] # Re: GPL ou pas GPL...

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

      A t'entendre, il n'a a que la GPL qui est libre. Et si SMF avait été sous une autre licence libre non compatible avec la GPL, tu aurais eu le même discours ? Le résultat aurait pourtant été le même.
      • [^] # Re: GPL ou pas GPL...

        Posté par  . Évalué à 2.

        A t'entendre, il n'a a que la GPL qui est libre.
        Tu as mal compris.
        Je ne parle que de la GPL car c'est ce qui est évoqué dans le journal.

        Et si SMF avait été sous une autre licence libre non compatible avec la GPL, tu aurais eu le même discours ?
        Je n'aurais pas eut besoin d'avoir ce discours puisqu'il n'y aurais pas eut ce problème.

        Le résultat aurait pourtant été le même.
        Avec une autre licence libre que la GPL ? Je ne pense pas, au contraire...
        • [^] # Re: GPL ou pas GPL...

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

          - Soit ils refusent le plugins SMF parce qu'ils considèrent qu'un plugin lie son code avec le code sous GPL et le problème aurait été le même pour n'importe quelle licence non compatible avec la GPL (libre ou non).

          - Soit ils refusent le plugin SMF parce qu'ils n'aiment pas la licence, donc c'est un ajout à la GPL (le programme ne peut pas utiliser des plugins sous telle licence), donc leur licence n'est plus GPL, donc leur logiciel est non libre.

          Pour moi, ça se limite à ça, et je pense qu'ici on est plutôt dans le cas 1.
          • [^] # Re: GPL ou pas GPL...

            Posté par  . Évalué à 0.

            On est, je pense aussi, dans le cas 1.

            En fait, le débat va au-delà de ça.
            la question de savoir si, au fond, les licences LGPL, BSD,... peuvent être considérés comme libre...
            J'ai un avis que je garde car je n'attend pas de réponse ni de troll... :-)
            • [^] # Re: GPL ou pas GPL...

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

              Puisque tu lances le sujet, ces licences ont des buts différents.
              Je vois les licences telles que BSD plus orientées techniques : "J'ai fait du code qui pourrait être utile à d'autres, peu importe ce que vous en faites, le voilà".
              La licence GPL est plus philosophique : "Le code devrait être librement modifiable/redistribuable, faisons en sorte qu'il le reste".

              Je ne pense donc pas qu'on puisse dire que des licences libres soient plus libres que d'autres, c'est juste une question de choix personnel.

              Si je devais coder par exemple une bibliothèque pour gérer HTTP, je la mettrai certainement sous BSD (si ça peut être utile à quelqu'un, tant mieux). Par contre, si je devais coder un logiciel plus complet disons par exemple un gestionnaire de bibliothèque musicale à la iTunes, je le ferai plutôt sous GPL pour m'assurer que le programme reste libre.
              • [^] # Re: GPL ou pas GPL...

                Posté par  . Évalué à 4.

                je suis complètement d'accord avec toi.
                Et pour le sujet du journal, c'est pour ça que je trouve dommage d'utiliser un forum non GPL.
            • [^] # Re: GPL ou pas GPL...

              Posté par  . Évalué à 5.

              J'attends de voir quelqu'un essayant de démontrer que la license BSD n'est pas libre, tient.

              En comparaison c'est plutôt la GPL qui impose des contraintes supplémentaires du point de vu des libertés du programmeur sans rien apporter de plus quant aux libertés de l'utilisateur... (ensuite, le fait de penser que ces contraintes supplémentaires sont nécessaires et bienfaitrices ou pas est un autre problème)
              • [^] # Re: GPL ou pas GPL...

                Posté par  . Évalué à 3.

                Hmmm, la GPL permet de garantir à l'utilisateur que les améliorations effectuées et distribuées lui seront disponibles. Donc, oui, elle apporte un plus à l'utilisateur.
  • # Que vont devenir les extensions commercial ?

    Posté par  . Évalué à 1.

    Je comprends pas si tout doit être GPL comment ils font pour toutes extensions commercial ? (voir dans extensions du site officiel) Y en a plein qui n'ont pas l'air GPL du tout ! Ou alors je comprends plus rien au licences GPL :( !

    Et il se tirent pas une balle dans le pied ? Tous les devs payant qui participait à la communauté vont se barrer sur un autre CMS non?
  • # détail et alternative

    Posté par  . Évalué à 2.

    D'abord le détail : La mise à jour mineure, c'est pour rajouter du sel dans les mots de passes avant le hash, car les rainbown table actuelle permettent de retrouver trop facilment les mots de passe... C'est peut être pas si mineur que ça pour les sites marchands.

    Une bonne alternative: http://www.bestofjoomla.com/ Fireboard qui est la suite/fork de joomlaboard: http://www.tsmf.net/

    et qui devait exister avant en tant que mamboboard

    Pour vos prochaines sélection de logiciel, histoire d'enfoncer des portes:


    - ce qui est bon pour quelq'un (l'équipe joomla), ne l'est pas forcément pour vous



    -à moins que le logiciel en question ne soit le premier avec la plus grosse communauté (et encore, ça ne corrige pas toujours assé vite les failles de sécu : phpBB), il faut mieux s'en tenir à un logiciel qui ne fait pas le café, mais qui couvre le gros des besoins avec une qualité du produit forte:

    --clarté et propreté du code (mais ce critère reste réservé à une élite qui a du temps libre pour le lire)

    --documentation cohérente, large et à jour (pas un wiki comme Alfresco pour la version 1.4)

    --une bonne communauté (pas forcément beaucoup de monde, mais un temps de réponse rapide, et des réponses à toutes les questions, cf les forums sourceforge puis pentahoo de mondrian)

    --licence clair (pas de flou juridique cf licence Alfresco 1.4 sugarCRM 2 -> vtiger, mélange GPLv2+Licence Apache de Alfresco 2 génant pour les américains sur les aspects des licences traitant des brevets, logiciel GPL a utilisation non commerciale, domaine publique avec restriction d'usage et autre joyeuseté du genre).

    --honnète sur les fonctionalités: vérifier si les fonctionalités annoncées fonctionnent, même si on ne les utilises pas (c'est en quelque sorte le "code review" du pauvre). ça évite de croire qu'un logiciel est pérenne avec des raisonement du type: "on n'en a pas encore besoin, mais p'tet plus tard ça nous servira" alors que ces fonctionnalités sont peut être difficile à maintenir dans l'usine à gaz, et facile à développer/commander en spécifique sur une base solide



    L'ensemble de ces petits points devraient permettre de choisir un logiciel pérenne

    (désolé pour les fautes d'orthographes, je n'ai pas encore installé le dictionnaire français dans iceweasel :-/ et là il est un peu tard pour le faire :p)
    • [^] # Re: détail et alternative

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

      Est-ce que tu fais partie de l'équipe de Joomla ? Si oui, peut-être peux-tu nous éclairer sur la manière dont la GPL est appliquée maintenant.

      Est-ce que les plugins non-GPL sont effectivement interdit dorénavant ?
      • [^] # Re: détail et alternative

        Posté par  . Évalué à 2.

        Je ne fais pas du tout partie de l'équipe joomla!

        J'ai juste été sensibilisé à la dure à la sécurité et à la sélection des logiciels: après qu'un serveur d'hébergement mutualisé ait été mis à genoux à cause d'une faille de sécu dans une install de manbo que j'avais fait. (Bon, je ne suis pas si sensibilisé que ça, juste quand ça affecte d'autres personnes que moi :p).

        Sinon, pour la GPL, il y avait déjà eu des discussions à l'époque de mambo: une interprétation stricte de la GPL implique que les plugins soit en GPL. Depuis le fork, la propriété du code n'est plus à l'équipe de joomla, donc la tolérance (j'autorise ça avec mon code) ne peut plus être accordé les yeux fermés. Ce qu'a dû leur signaler leur conseiller juridique. (La propriété du code est répartie entre les dev joomla, les devs mambo, et miro... pour mambo, les droits de miro ont été transféré à la fondation mambo, et l'ensemble des droits lui appartiennent). D'ou personnellement une utilisation de joomla pour ses qualités intrasèque, et de plugins exclusivement en GPL pour son environement juridique (ce qui ne me pose pas vraiment de problèmes, loin de là ^_^)

        A coté de ça, SMF fait la connerie de prendre l'avis de la FSF comme un conseil juridique.

        En gros, la GPL n'est censé toucher que les bouts de code qui ne pourrait fonctionner sans Joomla (ou le kernel). Si le reste peut fonctionner autrement (pilote, forum fonctionnant avec d'autres kernel, cms). Il n'y a pas de raison que ça influe. Mais il faut que le pont soit fait avec l'accord du propriétaire du code vers lequel on veut faire un pont (ils doivent autorisé qu'une partie de leur code soit dérivé en GPL pour faire le pont). Le pont devant être en GPL.

        La FSF considère que le pont ET le logiciel devrait être en GPL... Ils se font gentillement envoyer chier par NVidia (et sur d'autre points du genre par les utilisateurs de la licence Apache: fondation, Alfresco, etc...). La FSF a une position politique plus que juridique (mais il faut voir qu'il non pas une armée de juriste, et que le conseil a été donné par un gentil membre voulant aider, probablement pas un juriste).

        Ce n'est pas la première fois que la FSF déconne, ou que certains prennent leur avis comme conseil juridique valable: cf. patch gcc par Apple, et probablement d'autres cas à venir et passé.

        Pour en revenir au coeur du sujet, les plugins commerciaux ont toujours été interdits, mais avant une tolérance pouvait être facilement accordé (des dev de joomla/mambo font eu même des plugins commerciaux! comme la réécriture d'URL faite par un dev joomla). Ils sont maintenant obligé de souligner le risque juridique, un peu plus grand (maintenant c'est à chacun de résoudre l'inéquation (gain - coût_du_risque*probabilité++)>>0 ^_^)

        Pour résumer, tout le monde il est beau, tout le monde il est gentil, mais tout le monde il n'a pas les mêmes intérêts: argent ou pouvoir.

Suivre le flux des commentaires

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