D'abord merci pour le commentaire sur JyConsole. Ça fait plaisir.
Concernant la QPL... Ha la la! ... Qu'est-ce qu'on nous aura posé comme questions à son sujet ! ... Il est nécessaire de préciser plusieurs choses.
1) Vous avez tous utilisé Qt (via KDE) pendant des années sans que cela ne gène personne, alors qu'il était diffusé en QPL jusqu'à il y a très peu de temps. Donc finalement, on peut se demander si la QPL est vraiment un problème en soit.
2) Pourquoi diffusons nous en QPL ? Pourquoi ce mécanisme de reversion, qui nous permet d'utiliser aussi les contributions de la communauté dans nos produits fermés?
Mais, c'est parce que nous sommes un petite entreprise et que nos projets sont tout jeunes.
Nous voulons être honnête avec la communauté open-source. Artenum est entreprise commerciale et nous devons aussi vivre... en vendant services et logiciels... même s'ils sont open-source.
Nos projets sont jeunes et, pour l'instant, très majoritairement développés par nous-même, ce qui constitue un investissement initial important pour des logiciels qui sont finalement aussi mis en libre accès à la communauté. Le mécanisme de reversement rétribue en partie cet effort initial, du moins dans un premier temps. Je dirais qu'avec la LGPL ce serait pareil pour la communauté, les auteurs initiaux du projet pourraient faire ce qu'ils veulent de vos contributions.
Lorsque la part des contributions de la communauté deviendra plus importante dans nos projets, nous reverrons probablement notre politique avec peut-être une migration vers des licences de type GPL ou en double licensing GPL/QPL. L'essentiel pour nous devenant à ce moment de définir naturellement des "open-standards" sur la base ouverte et commune de nos code.
Par ailleurs, je souligne que la QPL est de droit européen, ce qui est mieux pour les auteurs.
Enfin, la QPL est, comme la GPL, contaminante au sens où elle oblige à mettre les codes rediffusés en open-source, par contre elle n'oblige pas (au contraire de la GPL) à rediffusé sous les termes de la même licence. En fait, c'est de la GPL et de son côté extrêmement contaminant que vient le problème.
3) Doit-on mettre tout développement sous QPL ? Non. Et il y a deux cas de figures :
a. Vous souhaitez utiliser nos codes comme composants logiciels pour développer pour autre chose, distinct du projet initial, ce n'est donc pas une modification de nos codes,... vous faites ce que vous voulez, si cela reste de l'open-source au sens de l'OSI. C'est le cas de HermesJMS, qui a intégré JyConsole est qui a sa propre vie.
b. Vos modifiez nos codes, c'est une contribution et/ou une modification, elle doit être diffusée soit en QPL soit en GPL avec la « petite phrase magique » comme le préconise la FSF (voir http://www.gnu.org/licenses/license-list.fr.html).
En pratique, les contributions soumises restent accessibles à la communauté. Bref, tant que tout le monde joue le jeu de l'open-source, c'est pareil qu'avec la GPL.
Indépendamment de notre politique de release, c'est un mauvais procès que l'on fait à la licence QPL, qui est plutôt bien écrite et finalement assez « carrée » dans l'échange équitable qu'elle propose.
En ce qui concerne Jython, je ne suis pas d'accord.
Certes le projet lui-même semble marquer le pas en termes d'évolutions par rapport aux versions de CPython.
Mais d'une part, cela reste cependant une solution très intéressante comme langage de script pour Java et d'autre part, quand on sait s'en servir, le couple Jython+Java offrent de très bonnes performances et rend le prototypage extrêmement souple.
De nombreux projets Java utilisent Jython comme language de script, en particulier dans le domaine scientifique.
Je prends pour simple exemple JyConsole, la console Jython que nous avons développée (http://www.artenum.com/fr/products/jyconsole.php). Elle intègre une complétion orientée objet (comme dans Eclipse), s'appliquant de manière totalement transparente que l'objet manipulé soit en Jython (i.e Python) soit en Java, voir y compris... en C++ si on passe par une couche JNI.
Dans Cassandra, JyConsole nous permet par exemple de manipuler simplement et facilement, avec la complétion objet, toute la bibliothèque VTK...
JyConsole et Jython sont aussi intégrés dans le projet de l'ESA SPIS (voir http://www.spis.org et surtout http://linuxfr.org/2006/09/07/21295.html). Les scientifiques issus du Fortran apprécient beaucoup Jython pour gérer le passage du séquentiel à l'objet (Java et C++)...
Donc Jython n'est pas mort et est utilisé, je vous le confirme. Ce que cela montre surtout, c'est que le couple Jython+Java constitue vraiment un ensemble très efficace et pratique en particulier pour le prototypage et le contrôle en ligne de commande.
PyPy semble très prometteur, en particulier en termes de performances. C'est à suivre donc. Mais l'avantage de Jython (dont l'interpréteur est en pur Java) réside dans sa portabilité et le fait qu'il ne nécessite de ne déployer qu'une seule Virtual Machine. Il reste donc facile à intégrer/embarquer dans des applications Java.
Cela dit concernant les plate-formes collaboratives, l'ensemble Java/J2EE est aussi la solution technologique que nous avons retenu pour notre plate-forme collaborative LibreSource (http://www.libresource.org).
Même si certains critiquent la complexité de mise en oeuvre de J2EE, le plan performances et surtout inter-opérabilité avec les autres plate-formes, le gain est ici significatif par rapport aux solutions sur base Python de type Zope.
LibreSource étant diffusée et largement utilisée en production depuis près de deux ans avec de très bons retours de nos utilisateurs, cette solution est maintenant validée.
Nuxeo marche donc sur les traces de LibreSource. Cela fait plaisir de voir que la voie ouverte il y a deux ans est maintenant suivie.
En fait... et à simple titre d'exemple, le code en question (SPIS) inclut un solver de Poisson 3D par éléments finis, déjà capable de gérer jusqu'au million d'éléments de grille et un particle-pusher, pouvant lui calculer la trajectoire de plusieurs dizaines de million de particules, simplement sur une grosse Linux box. En 3D, cela commence à devenir interessant.
Sérieusement, aujourd'hui, avec un peu de technique et de doigté, Java est capable d'exploits dans le domaine du calcul scientifique.
En alternative à CATIA et autres SALOME, comme je l'ai dit plus bas, il y a plusieurs solutions de framework de CAO-calcul sur base Java qui emergent, dont SPIS-UI. Certaines incluent des solutions de CAO et de maillage assez avancées. Et puis, Gmsh rend finalement de très bons services en termes de maillage non-structuré.
Scilab est aussi devenu très performante dans son domaine.
S'il y a encore probalement du chemin à faire vers un Environnement Intégré de Modellisation (IME) libre parfait, on est dans la bonne direction.
Dans le domaine spatial, l'Agence Spatiale Européenne (ESA) et le CNES poussent aussi maintenant pas mal au logiciels scientifiques libres.
L'ESA a en particulier initié le projet SPIS (http://www.spis.org), qui est un logiciel de simulation d'interaction plasma-satellite, développé par l’ONERA et la société Artenum.
Pour la petite histoire, cela peu sembler un peu pointu, mais SPIS est devenu une référence mondiale en termes d’état de l’art dans son domaine en moins de 3 ans… La raison est que la majorité de ses composants sont libres et que l’on peut connaître les modèles qui y sont implémentés. C’est la grande force du libre dans le domaine scientifique. On minimise l’effet « boite noire » et l’on peut mutualiser l’effort de validation. Le coté ouvert facilite aussi l’interaction entre projets, ce qui nécessaire aujourd’hui dans de nombreux projets scientifiques.
En relation avec SPIS, ont été développés plusieurs projets d’applications plus large. Il y a en particulier la plate-forme générique de liaisons CAO-calcul SPIS-UI (http://www.artenum.com/fr/products/spisui.php), qui est l’équivalent en Jython/Java de Salomé et Cassandra, un framework de visualisation 3D sur base VTK/Java (http://dev.artenum.com:/projects/cassandra). Cassandra a aujourd’hui pas mal de succès et commence à être utilisée dans de nombreux labos.
De manière générale VTK (http://public.kitware.com/VTK/) est devenu aujourd'hui un standard de facto en termes de visualisation scientifique 3D.
Je confirme, libre et scientifique vont bien ensemble...
Un autre cas concret d'application est le site du projet SPIS/SPINE ( http://www.spis.org(...) ) de l'Agence Spatiale Européenne. Ce site donnera peut-être une vision plus claire et détaillée des possibilités de la plate-forme.
- Le projet LibreSource a été initiés sur fonds mixtes, publiques et privés, Artenum, comme les différents partenaires institutionnels du projet, ayant activement participé au projet. Derrière il y a aussi la valorisation de différents travaux de recherche, entre autres ceux du projet ECOO, d'étudiants (thèses, DEA...) et de jeunes ingénieurs.
- L'intérêt initial de LibreSource est d'intégrer toutes ces fonctionnalités de manière homogène et modulaire dans un seul outil et sur une base propre en Java/J2EE. Cela va de l'outil de gestion de configuration (So6), au bugtracker en passant par des download areas ou des pages Wiki, etc..., l'ensemble pouvant être assemblé et étendu facilement. Par ailleurs, So6 pourra être étendu dans l'avenir à d'autres type de données.
LibreSource gère aussi différents niveaux de droits d'accès pour chaque ressource.
Merci pour l'appréciation esthétique. Nous pensons que ce n'est pas parce qu'un logiciel est destiné à des applications techniques ou scientifiques qu'il doit être austère.
Nous cherchons surtout à en améliorer la convivialité, partant du principe que l'utilisateur doit d'abord se concentrer sur son métier et ses besoins plutôt que sur les contraintes techniques du logiciel utilisé.
En configuration de base, Cassandra est capable de lire tous les formats VTK classiques. Mais il est aussi possible, via des plug-ins dédiés, de développer tout type de modules d'import sur base Jython comme Java. A titre d'exemple, Cassandra a déjà été intégrée au projet SPIS (http://www.spis.org)(...) développé pour l'ESA, via des plug-ins spécifiques de conversion développés sur demande.
Le développement de modules d'import MED et netCDF est à l'étude.
Cassandra elle-même fonctionne sur toute JVM 1.4 et supérieure, y compris des JVM libres. La seule contrainte est liée au wrapping JNI de VTK, qui doit être effectué de préférence avec la même JVM que celle d'exécution.
[^] # Re: Former des développeurs Python/Zope compétents
Posté par artenum . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
Concernant la QPL... Ha la la! ... Qu'est-ce qu'on nous aura posé comme questions à son sujet ! ... Il est nécessaire de préciser plusieurs choses.
1) Vous avez tous utilisé Qt (via KDE) pendant des années sans que cela ne gène personne, alors qu'il était diffusé en QPL jusqu'à il y a très peu de temps. Donc finalement, on peut se demander si la QPL est vraiment un problème en soit.
2) Pourquoi diffusons nous en QPL ? Pourquoi ce mécanisme de reversion, qui nous permet d'utiliser aussi les contributions de la communauté dans nos produits fermés?
Mais, c'est parce que nous sommes un petite entreprise et que nos projets sont tout jeunes.
Nous voulons être honnête avec la communauté open-source. Artenum est entreprise commerciale et nous devons aussi vivre... en vendant services et logiciels... même s'ils sont open-source.
Nos projets sont jeunes et, pour l'instant, très majoritairement développés par nous-même, ce qui constitue un investissement initial important pour des logiciels qui sont finalement aussi mis en libre accès à la communauté. Le mécanisme de reversement rétribue en partie cet effort initial, du moins dans un premier temps. Je dirais qu'avec la LGPL ce serait pareil pour la communauté, les auteurs initiaux du projet pourraient faire ce qu'ils veulent de vos contributions.
Lorsque la part des contributions de la communauté deviendra plus importante dans nos projets, nous reverrons probablement notre politique avec peut-être une migration vers des licences de type GPL ou en double licensing GPL/QPL. L'essentiel pour nous devenant à ce moment de définir naturellement des "open-standards" sur la base ouverte et commune de nos code.
Par ailleurs, je souligne que la QPL est de droit européen, ce qui est mieux pour les auteurs.
Enfin, la QPL est, comme la GPL, contaminante au sens où elle oblige à mettre les codes rediffusés en open-source, par contre elle n'oblige pas (au contraire de la GPL) à rediffusé sous les termes de la même licence. En fait, c'est de la GPL et de son côté extrêmement contaminant que vient le problème.
3) Doit-on mettre tout développement sous QPL ? Non. Et il y a deux cas de figures :
a. Vous souhaitez utiliser nos codes comme composants logiciels pour développer pour autre chose, distinct du projet initial, ce n'est donc pas une modification de nos codes,... vous faites ce que vous voulez, si cela reste de l'open-source au sens de l'OSI. C'est le cas de HermesJMS, qui a intégré JyConsole est qui a sa propre vie.
b. Vos modifiez nos codes, c'est une contribution et/ou une modification, elle doit être diffusée soit en QPL soit en GPL avec la « petite phrase magique » comme le préconise la FSF (voir http://www.gnu.org/licenses/license-list.fr.html).
En pratique, les contributions soumises restent accessibles à la communauté. Bref, tant que tout le monde joue le jeu de l'open-source, c'est pareil qu'avec la GPL.
Indépendamment de notre politique de release, c'est un mauvais procès que l'on fait à la licence QPL, qui est plutôt bien écrite et finalement assez « carrée » dans l'échange équitable qu'elle propose.
Julien Forest
Gérant d'Artenum.
[^] # Re: Former des développeurs Python/Zope compétents
Posté par artenum . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 1.
En ce qui concerne Jython, je ne suis pas d'accord.
Certes le projet lui-même semble marquer le pas en termes d'évolutions par rapport aux versions de CPython.
Mais d'une part, cela reste cependant une solution très intéressante comme langage de script pour Java et d'autre part, quand on sait s'en servir, le couple Jython+Java offrent de très bonnes performances et rend le prototypage extrêmement souple.
De nombreux projets Java utilisent Jython comme language de script, en particulier dans le domaine scientifique.
Je prends pour simple exemple JyConsole, la console Jython que nous avons développée (http://www.artenum.com/fr/products/jyconsole.php). Elle intègre une complétion orientée objet (comme dans Eclipse), s'appliquant de manière totalement transparente que l'objet manipulé soit en Jython (i.e Python) soit en Java, voir y compris... en C++ si on passe par une couche JNI.
C'est franchement pratique pour prototyper.
JyConsole a été intégrée à Cassandra (http://www.artenum.com/fr/products/cassandra.php) notre visualiseur scientifique 3D ainsi qu'à plusieurs autres projets open-source comme HermesJMS (http://www.hermesjms.com/).
Dans Cassandra, JyConsole nous permet par exemple de manipuler simplement et facilement, avec la complétion objet, toute la bibliothèque VTK...
JyConsole et Jython sont aussi intégrés dans le projet de l'ESA SPIS (voir http://www.spis.org et surtout http://linuxfr.org/2006/09/07/21295.html). Les scientifiques issus du Fortran apprécient beaucoup Jython pour gérer le passage du séquentiel à l'objet (Java et C++)...
Donc Jython n'est pas mort et est utilisé, je vous le confirme. Ce que cela montre surtout, c'est que le couple Jython+Java constitue vraiment un ensemble très efficace et pratique en particulier pour le prototypage et le contrôle en ligne de commande.
PyPy semble très prometteur, en particulier en termes de performances. C'est à suivre donc. Mais l'avantage de Jython (dont l'interpréteur est en pur Java) réside dans sa portabilité et le fait qu'il ne nécessite de ne déployer qu'une seule Virtual Machine. Il reste donc facile à intégrer/embarquer dans des applications Java.
Cela dit concernant les plate-formes collaboratives, l'ensemble Java/J2EE est aussi la solution technologique que nous avons retenu pour notre plate-forme collaborative LibreSource (http://www.libresource.org).
Même si certains critiquent la complexité de mise en oeuvre de J2EE, le plan performances et surtout inter-opérabilité avec les autres plate-formes, le gain est ici significatif par rapport aux solutions sur base Python de type Zope.
LibreSource étant diffusée et largement utilisée en production depuis près de deux ans avec de très bons retours de nos utilisateurs, cette solution est maintenant validée.
Nuxeo marche donc sur les traces de LibreSource. Cela fait plaisir de voir que la voie ouverte il y a deux ans est maintenant suivie.
Julien Forest
Gérant d'Artenum
[^] # Re: Erreur d'une puissance de dix
Posté par artenum . En réponse à la dépêche SPIS, l'OpenSource scientifique au service de l'exploration spatiale. Évalué à 3.
Cordialement,
L'équipe d'Artenum.
[^] # Re: noyaux de calcul intensifs en Java ?
Posté par artenum . En réponse à la dépêche Logiciels libres vus par l'industrie aéronautique. Évalué à 2.
Sérieusement, aujourd'hui, avec un peu de technique et de doigté, Java est capable d'exploits dans le domaine du calcul scientifique.
[^] # Re: code aster
Posté par artenum . En réponse à la dépêche Logiciels libres vus par l'industrie aéronautique. Évalué à 2.
Scilab est aussi devenu très performante dans son domaine.
S'il y a encore probalement du chemin à faire vers un Environnement Intégré de Modellisation (IME) libre parfait, on est dans la bonne direction.
[^] # Re: Logiciels Scientifiques
Posté par artenum . En réponse à la dépêche Logiciels libres vus par l'industrie aéronautique. Évalué à 3.
Dans le domaine spatial, l'Agence Spatiale Européenne (ESA) et le CNES poussent aussi maintenant pas mal au logiciels scientifiques libres.
L'ESA a en particulier initié le projet SPIS (http://www.spis.org), qui est un logiciel de simulation d'interaction plasma-satellite, développé par l’ONERA et la société Artenum.
Pour la petite histoire, cela peu sembler un peu pointu, mais SPIS est devenu une référence mondiale en termes d’état de l’art dans son domaine en moins de 3 ans… La raison est que la majorité de ses composants sont libres et que l’on peut connaître les modèles qui y sont implémentés. C’est la grande force du libre dans le domaine scientifique. On minimise l’effet « boite noire » et l’on peut mutualiser l’effort de validation. Le coté ouvert facilite aussi l’interaction entre projets, ce qui nécessaire aujourd’hui dans de nombreux projets scientifiques.
En relation avec SPIS, ont été développés plusieurs projets d’applications plus large. Il y a en particulier la plate-forme générique de liaisons CAO-calcul SPIS-UI (http://www.artenum.com/fr/products/spisui.php), qui est l’équivalent en Jython/Java de Salomé et Cassandra, un framework de visualisation 3D sur base VTK/Java (http://dev.artenum.com:/projects/cassandra). Cassandra a aujourd’hui pas mal de succès et commence à être utilisée dans de nombreux labos.
De manière générale VTK (http://public.kitware.com/VTK/) est devenu aujourd'hui un standard de facto en termes de visualisation scientifique 3D.
Je confirme, libre et scientifique vont bien ensemble...
Ju.
[^] # Re: gâchis de l'argent public ?
Posté par artenum . En réponse à la dépêche Publication officielle de LibreSource Community Edition V1.0. Évalué à 3.
- Le site de démonstration n'est pas http://libresource.loria.fr(...) , mais le site de LibreSource lui-même ou du moins sa partie développement : http://dev.libresource.org/home/fr(...)
Un autre cas concret d'application est le site du projet SPIS/SPINE ( http://www.spis.org(...) ) de l'Agence Spatiale Européenne. Ce site donnera peut-être une vision plus claire et détaillée des possibilités de la plate-forme.
- Le projet LibreSource a été initiés sur fonds mixtes, publiques et privés, Artenum, comme les différents partenaires institutionnels du projet, ayant activement participé au projet. Derrière il y a aussi la valorisation de différents travaux de recherche, entre autres ceux du projet ECOO, d'étudiants (thèses, DEA...) et de jeunes ingénieurs.
- L'intérêt initial de LibreSource est d'intégrer toutes ces fonctionnalités de manière homogène et modulaire dans un seul outil et sur une base propre en Java/J2EE. Cela va de l'outil de gestion de configuration (So6), au bugtracker en passant par des download areas ou des pages Wiki, etc..., l'ensemble pouvant être assemblé et étendu facilement. Par ailleurs, So6 pourra être étendu dans l'avenir à d'autres type de données.
LibreSource gère aussi différents niveaux de droits d'accès pour chaque ressource.
L'équipe de LibreSource.
[^] # Re: Données/formats d'entrée ?
Posté par artenum . En réponse à la dépêche Cassandra, nouveau visualiseur libre de données scientifiques 3D. Évalué à 1.
Nous cherchons surtout à en améliorer la convivialité, partant du principe que l'utilisateur doit d'abord se concentrer sur son métier et ses besoins plutôt que sur les contraintes techniques du logiciel utilisé.
En configuration de base, Cassandra est capable de lire tous les formats VTK classiques. Mais il est aussi possible, via des plug-ins dédiés, de développer tout type de modules d'import sur base Jython comme Java. A titre d'exemple, Cassandra a déjà été intégrée au projet SPIS (http://www.spis.org)(...) développé pour l'ESA, via des plug-ins spécifiques de conversion développés sur demande.
Le développement de modules d'import MED et netCDF est à l'étude.
Cassandra elle-même fonctionne sur toute JVM 1.4 et supérieure, y compris des JVM libres. La seule contrainte est liée au wrapping JNI de VTK, qui doit être effectué de préférence avec la même JVM que celle d'exécution.
L'équipe d'Artenum