Texto, ils disent « relaxed license handling (these GNU fanatics are really sucking), we want to have a LGPL'ed API which allows to import other tool-classes with free licenses without relicensing / editing them ».
L'intérêt de la LGPL est de permettre l'exploitation du logiciel par des éléments propriétaires.
Ceci dit, ils parlent de fork : je serais curieux de voir comment ils arrivent à changer la licence originelle d'un fork (concrêtement, ils doivent enlèver tout les éléments de code dont ils ne sont pas auteurs).
- Ils parlent aussi de « more open development (wiki access, cvs access, ...) ». A priori PhpGroupWare à un CVS à acces public (restreint en écriture, comme tout les projets que je connais). Quant au Wiki, que ce soit vital, cela reste à étudier.
- « we want to focus on a user friendly interface (java-script) and more on user demand ». Bonne idée. Mais étant donné que le javascript à pour principal défaut de ne jamais fonctionner de la même manière selon les navigateurs...
- « big steps like the XSLT-templates should be developed in a separate branch and merged back, and not stop the other development for ages » s'il s'agit, tel que cela le semble, de modification de fond sur l'ensemble de code, faire le travail sur une branche est cohérent (pour pouvoir toujours avoir une version fonctionnelle du code sur le tronc) mais il faut à tout prix éviter de faire autre chose que des correctifs de bogues sur le tronc, sinon le merge au final risque d'être plus long et complexe à réaliser que le développement en lui-même.
[^] # Re: Fork
Posté par Anonyme . En réponse à la dépêche phpGroupware 0.9.16 RC1 est sorti !. Évalué à 3.
Texto, ils disent « relaxed license handling (these GNU fanatics are really sucking), we want to have a LGPL'ed API which allows to import other tool-classes with free licenses without relicensing / editing them ».
L'intérêt de la LGPL est de permettre l'exploitation du logiciel par des éléments propriétaires.
Ceci dit, ils parlent de fork : je serais curieux de voir comment ils arrivent à changer la licence originelle d'un fork (concrêtement, ils doivent enlèver tout les éléments de code dont ils ne sont pas auteurs).
- Ils parlent aussi de « more open development (wiki access, cvs access, ...) ». A priori PhpGroupWare à un CVS à acces public (restreint en écriture, comme tout les projets que je connais). Quant au Wiki, que ce soit vital, cela reste à étudier.
- « we want to focus on a user friendly interface (java-script) and more on user demand ». Bonne idée. Mais étant donné que le javascript à pour principal défaut de ne jamais fonctionner de la même manière selon les navigateurs...
- « big steps like the XSLT-templates should be developed in a separate branch and merged back, and not stop the other development for ages » s'il s'agit, tel que cela le semble, de modification de fond sur l'ensemble de code, faire le travail sur une branche est cohérent (pour pouvoir toujours avoir une version fonctionnelle du code sur le tronc) mais il faut à tout prix éviter de faire autre chose que des correctifs de bogues sur le tronc, sinon le merge au final risque d'être plus long et complexe à réaliser que le développement en lui-même.
Bref...