La nouvelle licence de Mozilla (v2.0) vient d’être publiée.
Texte : www.mozilla.org…
FAQ : www.mozilla.org…

La licence MPL 1.1 est incompatible avec les licences LGPL/GPL (www.gnu.org…), et c’est pourquoi le dictionnaire est distribué sous ces trois licences, afin de forcer la compatibilité. C’est la condition requise pour que le dictionnaire soit inclus dans les produits Mozilla.

Comme j’imagine que cet imbroglio juridique va disparaître bientôt, j’espère qu’il sera possible de distribuer le futur dictionnaire uniquement sous la licence MPL 2.0, ce qui clarifiera les droits et devoirs de ceux qui veulent utiliser le dictionnaire dans leurs logiciels.

Le thésaurus et le fichier des règles de coupures des mots ne sont pas concernés, car distribués uniquement sous la licence LGPL.

Je vous tiens au courant dès que la transition est effective dans le code source de Mozilla (ça peut prendre plusieurs mois à mon avis, il faut changer toutes les notices et les habitudes des développeurs).

Attention, du coup, l'intégration à un logiciel (L)GPL ne se déroulerait plus exactement de la même façon
www.mozilla.org…

(En pratique j'ai l'impression que ce serait plus simple, mais j'attendrais de voir comment se débrouille quelqu'un qui le ferait réellement).

Si Mozilla passe ses logiciels sous MPL 2, je pense qu’il n’y aura aucun problème pour inclure un dictionnaire sous MPL 2. Les complications pour intégrer du code tiers sous LGPL, ce n’est pas notre affaire, me semble-t-il.

Je pensais éventuellement au projet LibreOffice qui est sous LGPL.

Mais au pire il s'agirait d'ajouter des notices dans la documentation je crois, ce que la plupart des logiciels font déjà.

LibreOffice est sous deux licences : MPL et LGPL.

Mais, même si LibO n’était que sous LGPL, je présume que ça ne poserait pas de problème pour inclure un élément uniquement sous MPL 2, attendu que la MPL est compatible avec la LGPL et moins restrictive que celle-ci.

MPL < LGPL < GPL

C’est du moins ainsi que je comprends l’affaire.

Dans la dernière partie de ce billet (people.gnome.org…), il est dit que LibreOffice va passer à la MPL 2.0.

LibreOffice plans to move wholesale to the category-b Mozilla Public License (MPLv2).

Quand Mozilla fera de même, nous suivrons.

Firefox et Thunderbird sont dorénavant distribués sous la licence MPL 2.0. Le code de LibreOffice passe peu à peu aussi sous cette licence.

Les prochaines versions du dictionnaire orthographique ne seront donc plus distribuées que sous cette licence, au lieu des trois licences MPL 1.1, LGPL, GPL.

Les prochaines versions du dictionnaire orthographique ne seront donc plus distribuées que sous cette licence, au lieu des trois licences MPL 1.1, LGPL, GPL.

Concrètement, y a-t-il des conséquences pour l’intégration du dictionnaire Dicollecte dans LanguageTool (LGPL) ?

Ceci devrait répondre à ta question :
www.gnu.org…

Mozilla Public License (MPL) version 2.0 (#MPL-2.0)

C'est une licence de logiciel libre. Le paragraphe 3.3 assure sa compatibilité indirecte avec la GNU GPL version 2.0, la GNU GPL version 2.1, la GNU AGPL version 3.0, ainsi que toutes les versions ultérieures de ces licences. Quand vous recevez un programme sous MPL version 2.0, vous pouvez faire une « création plus vaste » [Larger Work] qui combine ce programme avec du code régi par une des licences GNU précitées. Quand vous le faites, le paragraphe 3.3 vous donne la permission de distribuer le programme sous MPL sous les termes de la même licence GNU, à une condition : vous devez vous assurer que les fichiers initialement sous MPL restent disponibles sous les termes de la MPL. Autrement dit, quand vous faites une combinaison de cette sorte, les fichiers qui étaient initialement sous MPL auront deux licences : la MPL et la licence GNU. Au final, la création plus vaste, globalement, sera couverte par la licence GNU. Les gens à qui vous fournirez cette combinaison auront la possibilité d'utiliser n'importe quel fichier initialement régi par la MPL sous les termes de cette licence, ou bien de distribuer tout ou partie de la création plus vaste sous les termes des licences GNU sans restriction supplémentaire.

Il est important de comprendre que la condition de distribution des fichiers couverts par la MPL s'applique seulement à l'auteur et distributeur initial de la création plus vaste. Si elle s'appliquait aussi aux destinataires, ce serait une restriction supplémentaire incompatible avec la GPL et l'AGPL. Cela dit, quand vous contribuez à un projet existant, nous vous recommandons habituellement de garder la même licence pour les modifications, même quand vous n'y êtes pas obligé. Si vous recevez un programme régi par une licence GNU, où quelques fichiers sont également sous MPL, vous ne devriez enlever la MPL de ces fichiers que lorsqu'il y a pour cela une solide justification.

Vérifiez les avis de licence des logiciels sous MPL avant de faire une création plus vaste de cette manière. Ceux qui publient le programme original sous la MPL 2.0 peuvent choisir de ne pas faire usage de cette compatibilité en ajoutant une phrase dans les avis de licence, disant que « cette création est incompatible avec les licences secondaires » [the work is “Incompatible With Secondary Licenses”]. Tout logiciel qui inclut cet avis n'est pas compatible avec la GPL et l'AGPL.

Les logiciels couverts par les versions précédentes de la MPL peuvent être mis à jour vers la version 2.0, mais tout logiciel qui n'est pas déjà disponible sous l'une des licences GNU listées doit être signalé comme incompatible avec les licences secondaires. Cela signifie qu'un logiciel disponible uniquement sous les versions précédentes de la MPL reste incompatible avec la GPL et l'AGPL.

Je n’ajouterai aucune restriction de compatibilité. Donc tu peux récupérer le dictionnaire et le lexique pour un logiciel sous LGPL.

Pour information, je recopie ici ce qui est écrit sur cette page : www.mozilla.org…

About MPL 2.0: Revision Process and Changes FAQ

1. How was MPL 2.0 drafted?

MPL 2.0 was drafted over a period of 21 months in a public process that included extensive feedback from a variety of people, including MPL users, lawyers, and open source community groups like the Free Software Foundation and Open Source Initiative.

2. Is the revision process publicly documented?

Historical documents about the revision process are available from this website.

3. Section 6 of MPL 1.1 says Netscape can update the license, but Mozilla isn't Netscape. Can Mozilla still update the license?

As part of the creation of the Mozilla Foundation, Netscape assigned the ability to publish new licenses to Mozilla, making the Mozilla Foundation Netscape's successor for this purpose.

Upgrading a project from MPL 1.1 to MPL 2.0

4. I use MPL 1.1 for my project. Why should I upgrade to MPL 2.0?

If your project is licensed under MPL 1.1, there are several important reasons why you should move your project to MPL 2.0:

MPL 2.0 makes compliance simpler, both for you and for people who receive code from you.
MPL 2.0 provides patent protections for you and your contributors more in line with those of other open source licenses, and allows your entire community to protect any contributor if the contributor is sued.
Compatibility with Apache and GPL makes code reuse and redistribution easier for you and for the broader open source community.

For a more complete list of reasons why, see the question about "what has changed", below.

5. I am the author of code which I have placed under MPL version 1.1. How do I license my project under MPL 2.0 instead of MPL 1.1?

If you are the author, to change the license from MPL 1.1 to MPL 2.0, replace the old license header with the new header from MPL 2.0 Exhibit A.

6. I am distributing code written by someone else under the terms of MPL 1.1. Can I distribute that code under the terms of MPL 2.0 instead of MPL 1.1? If so, how?

Yes, you can, because MPL 1.1 allows anyone who received code under the terms of MPL 1.1 to distribute under the terms of a later version of the MPL.

To do this, replace the old license header with the new header from MPL 2.0 Exhibit A. If you received the code under only MPL 1.1, and not a combination of the MPL plus a member of the GNU family of licenses (such as the Mozilla Tri-License), then you must also add the text of Exhibit B to the license header.

Changes from MPL 1.1

7. What has not changed between MPL 1.1 and MPL 2.0?

The most important part of the license - the file-level copyleft - is essentially the same in MPL 2.0 and MPL 1.1.

8. What has changed between MPL 1.1 and MPL 2.0?

The primary change is simplification. For example, rather than exactly specifying the amount of time source code must be available, the source code must simply be made available when the executable is made available. License headers have been made shorter, and notification requirements have been simplified. Overall, the license is substantially shorter and should be easier to understand.

In addition, a handful of new features have been added to the license. For example, the license is now compatible with the Apache license - anyone who complies with the terms of the MPL should also be compliant with the Apache license's terms. Similarly, by default, the license allows the code to be distributed alongside code licensed under the GPL or LGPL. In addition, patent protections have been brought more in line with what other licenses (such as Apache) use, while also allowing any member of a community to defend a contributor who has been sued for infringement.

A word-by-word redline of all changes is also available for those seeking to analyze the changes in more detail. Note, however, that the changes are extensive, and you may find that simply reading the new license itself will provide a clearer understanding of its contents.

9. Why did the new license remove the government entities language?

Software licensed under the MPL is a commercial item as defined in 48 C.F.R. 2.101, unless it was originally written at the direction, and for the use, of the US government. As a result, removing the language from the license simplifies the license without changing the rights and responsibilities that US Government users have towards MPL-licensed code.

10. Why doesn't the new license require distributors to include a complete copy of the license with the distributed Source Code?

When MPL 1.1 was written, source code distribution occurred primarily through tarballs and zip files. In contrast, modern software distribution often occurs on a file-by-file basis over the web (e.g., hg.mozilla.org…). As a result, MPL 2.0 requires distributors to tell recipients how to get the license (for example, by linking to it in the header of a single source file), rather than requiring them to distribute the entire license itself. In most cases, distributing the license with the code - as was required in MPL 1.1 - is still the best and easiest way to meet this requirement. However, given the diversity of modern source code and executable distribution practices, it was sensible to give more flexibilty and place the burden on the distributor to pick an effective notification mechanism.

11. Why did the new license remove the reference to build scripts and documentation from the definition of Source Code?

If you choose to license software under the MPL, it is considered a best practice to release all of the software, including interface files and build scripts, under the MPL. However, since these terms only apply to specific types of software distributed in specific ways, and MPL is now applied to a wide variety of software distributed in a number of different ways, we removed these reference and will allow the broader definition of "preferred form" to be interpreted as appropriate to a given situation.

12. Section 3.2 now requires that I "inform" recipients how they can obtain the Source Code form. Could you give some examples of what it means to "inform"?

Historically, informing recipients of source availability was done by means of the "About" box of a piece of software. However, other mechanisms for informing users are also acceptable when appropriate for the type of software being distributed. As a specific example, when using MPL-licensed JavaScript on a website, recipients could be informed by having links to the source in the "Legal" or "Notices" section of the website. More generally, notices should be put in the place a reasonable person is likely to look for legal information about the software they have recieved.

13. Unlike MPL 1.1, MPL 2.0 contains explicit provisions for distribution alongside GPL- and LGPL-licensed code. Why?

Providing an explicit mechanism by which MPL and GPL code can be distributed together has several significant benefits:

– It allows elimination of the common dual and tri-license approach, which reduces license proliferation, since (for compatibility and proliferation purposes) each dual-license and tri-license is a separate license.

– Along with Apache compatibility, it creates a series of upwards-compatible free software licenses covering much of the world's free and open source software.

– It helps protect the original licensor's ability to reintegrate modifications made downstream, by requiring that the initial distribution of changes occurs under both licenses and not just the GPL.