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(...)
Journal Fin du support du forum SMF pour Joomla
31
juil.
2007
# faut pas s'étonner
Posté par jeffcom . Évalué à -2.
en bas du site, faut pas s'étonner de voir quelques anachronismes...
[^] # Re: faut pas s'étonner
Posté par jeffcom . Évalué à 0.
# Heu... Y'a un attention en rouge à lire aussi
Posté par J. de N. (site web personnel) . Évalué à 4.
Donc il faut attendre... Enfin d'après ce qui est écrit sur leur page d'accueil.
# Excellent exemple !
Posté par Beurt . Évalué à 8.
[^] # Re: Excellent exemple !
Posté par Zenitram (site web personnel) . Évalué à 2.
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 Beurt . Évalué à 3.
Le voilà le problème.
[^] # Re: Excellent exemple !
Posté par mxt . Évalué à 1.
[^] # Re: Excellent exemple !
Posté par windu.2b . Évalué à 1.
Donc, il faudra attendre le bon vouloir de l'éditeur de SMF ou que chacun patche son SMF :-/
[^] # Re: Excellent exemple !
Posté par mxt . Évalué à 1.
Du coup, pour redistribuer le patch qui permettra à SMF de tenir compte du nouveau système d'authentification, ça va être coton
[^] # Re: Excellent exemple !
Posté par sobek . Évalué à 2.
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 HSimpson . Évalué à 1.
Non, non, ceci n'est pas aberrant...
[^] # Re: Excellent exemple !
Posté par sobek . Évalué à 2.
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 HSimpson . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 2.
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 :
# GPL ou pas GPL...
Posté par moudj . Évalué à 1.
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 Nelis (site web personnel) . Évalué à 4.
[^] # Re: GPL ou pas GPL...
Posté par moudj . Évalué à 2.
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 Nelis (site web personnel) . Évalué à 5.
- 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 moudj . Évalué à 0.
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 Nelis (site web personnel) . Évalué à 5.
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 moudj . Évalué à 4.
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 sobek . Évalué à 5.
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 lezardbreton . Évalué à 3.
# Que vont devenir les extensions commercial ?
Posté par goofy . Évalué à 1.
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 Earered . Évalué à 2.
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 Nelis (site web personnel) . Évalué à 2.
Est-ce que les plugins non-GPL sont effectivement interdit dorénavant ?
[^] # Re: détail et alternative
Posté par Earered . Évalué à 2.
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.