(J'ai tenté de résumer un maximum, tant c'était compliqué).
Objectif premier : "Ratisser large"
Multi-licencier un projet permet d'accepter plus de contributions, plus de code, je m'explique.
Côté développeur
Pour que son code soit accepté, un développeur doit se soumettre à la licence du logiciel auquel il fournit ce code. J'ai dû le faire également.
Si un développeur d'une entreprise n'est habilité qu'à coder pour du MPL et bien la licence lui permettra. De même pour la LGPL. Ca met tout le monde d'accord.
Côté utilisateur
Un utilisateur (entreprise) peut choisir à quel type de licence il désire se conformer. Utile pour ne pas éventuellement contaminer le parc avec l'intégration d'une licence GPL par exemple.
Réponse officielle
Réponse (traduite) de Michael Stahl, développeur :
"Tout le code de OpenOffice.org est UNIQUEMENT sous LGPLv3 et LibreOffice souhaite aller dans la direction de la MPLv2, donc nous devons nous assurer que le code spécifique à LibreOffice (c'est-à-dire non hérité de OpenOffice.org) est licencié sous dual-licence MPL-LGPL afin que:
a) LibreOffice puisse être distribué sous LGPL
b) et que le code relicencié de AOO puisse être fusionné dans LibreOffice (ce qui est nécessaire puisqu'Oracle n'a pas donné à la Document Foundation une license MPL) et que LibreOffice puisse être distribué en MPLv2"
C'est (削除) un peu (削除ここまで) compliqué.
Ce qu'il faut retenir, et je l'ai oublié dans mon explication de tout à l'heure, tout code inséré dans Apache OpenOffice est directement (avec un délai) réintégré à LibreOffice. (Dans pareil cas, Apache OpenOffice n'a plus aucune raison d'être.)
C'est principalement pour la compatibilité avec le code d'AOO que le code est dual-licensed donc.
(Notez que le projet OpenOffice.org tel qu'appelé initialement avec Sun n'existe plus et est bel et bien mort.)
[^] # Re: Et avec LibreOffice
Posté par vida18 . En réponse au journal Le code source de Symphony va fusionner avec OpenOffice. Évalué à 4.
Ma réponse après recherches sur Wikipedia.
(J'ai tenté de résumer un maximum, tant c'était compliqué).
Objectif premier : "Ratisser large"
Multi-licencier un projet permet d'accepter plus de contributions, plus de code, je m'explique.
Côté développeur
Pour que son code soit accepté, un développeur doit se soumettre à la licence du logiciel auquel il fournit ce code. J'ai dû le faire également.
Si un développeur d'une entreprise n'est habilité qu'à coder pour du MPL et bien la licence lui permettra. De même pour la LGPL. Ca met tout le monde d'accord.
Côté utilisateur
Un utilisateur (entreprise) peut choisir à quel type de licence il désire se conformer. Utile pour ne pas éventuellement contaminer le parc avec l'intégration d'une licence GPL par exemple.
Réponse officielle
Réponse (traduite) de Michael Stahl, développeur :
"Tout le code de OpenOffice.org est UNIQUEMENT sous LGPLv3 et LibreOffice souhaite aller dans la direction de la MPLv2, donc nous devons nous assurer que le code spécifique à LibreOffice (c'est-à-dire non hérité de OpenOffice.org) est licencié sous dual-licence MPL-LGPL afin que:
a) LibreOffice puisse être distribué sous LGPL
b) et que le code relicencié de AOO puisse être fusionné dans LibreOffice (ce qui est nécessaire puisqu'Oracle n'a pas donné à la Document Foundation une license MPL) et que LibreOffice puisse être distribué en MPLv2"
C'est
(削除) un peu (削除ここまで)compliqué.Ce qu'il faut retenir, et je l'ai oublié dans mon explication de tout à l'heure, tout code inséré dans Apache OpenOffice est directement (avec un délai) réintégré à LibreOffice. (Dans pareil cas, Apache OpenOffice n'a plus aucune raison d'être.)
C'est principalement pour la compatibilité avec le code d'AOO que le code est dual-licensed donc.
(Notez que le projet OpenOffice.org tel qu'appelé initialement avec Sun n'existe plus et est bel et bien mort.)