Licensing

[stefan6419846]

For now, this package is triple-licensed under GPL-2.0-or-later AND LGPL-2.1-or-later AND MPL-1.1. Especially the GPL part makes it hard to use this package in commercial solutions.

I therefore wanted to evaluate whether a separate package for each license type is feasible in some way, but this would require a compatible license for https://github.com/Kozea/Pyphen/blob/master/pyphen/__init__.py as well. For now, I would have to assume that it is GPL-2.0-or-later AND LGPL-2.1-or-later AND MPL-1.1 as well, which would not really allow for such a split?

Example: If I just need the DE and EN locale, I could use a stripped package under the terms of LGPL-2.1-or-later for DE and under the terms of a BSD-style license for EN, if the accompanying Python code uses a compatible license.

[liZe]

Hi!

There’s already been a long discussion about this topic in Kozea/WeasyPrint#944.

Short summary:

• as far as I know, tri-licensed means that it’s distributed under the 3 licenses, and that you can choose the one you want.
• other famous libraries (namely hunspell) understand the situation the same way and are used in non-GPL and proprietary projects.
• GPL dictionaries can be used (and sometimes even bundled) in proprietary projects (for example Google Chrome) and non-GPL open-source projects (for example LibreOffice).

So… In my opinion, you can use Pyphen even in close-source projects. If you want to be 100% sure, you can:

• contact the devs for the code (it’s OK for me to use in proprietary software, some code is written by @BLKSerene in 8552909, the original code from a15ec96 is distributed under LGPL and can be included in proprietary software, and I think that’s all)
• contact the creators of the different dictionaries you want to embed.

[stefan6419846]

as far as I know, tri-licensed means that it’s distributed under the 3 licenses, and that you can choose the one you want.

AFAIK this only holds true if the hyphenation file licenses are compatible (I have only checked DE and EN, which indeed are), but IANAL. Nevertheless, the README indicates:

Many dictionaries are included in pyphen, they come from the LibreOffice git repository and are distributed under GPL, LGPL and/or MPL.

Referencing Kozea/WeasyPrint#944 (comment) as well, this still means GPL might be problematic here and cause pyphen to be subject to the GPL.

Similar things might hold true for a15ec96: While the initial license has been LGPL-2.1-or-later, incorporating this into GPL software might require a license "upgrade" as well.

[liZe]

Referencing Kozea/WeasyPrint#944 (comment) as well, this still means GPL might be problematic here and cause pyphen to be subject to the GPL.

Maybe. Maybe licenses can be applied to dictionaries, maybe not. If they are, maybe these dictionaries can be considered to be statically bounded to the hyphenation library, maybe not. But, well, Pyphen works without these dictionaries, so the hard link is not obvious.

As I said before, if some GPL-licensed dictionary creators think they are, I’ll remove them from Pyphen with no discussion. They’ll the ones who can decide, that’s why you should contact them if you want to be 100% sure. And they may have different points of view about including them in proprietary software too.

LibreOffice, that’s not released under GPL, does include GPL dictionaries, just as Pyphen does. These dictionaries are actually even hosted by LibreOffice servers. Mozilla decided to not ship dictionaries, but includes a button in Firefox to install it, that’s another way to interpret this situation.

So — maybe 😄.

Similar things might hold true for a15ec96: While the initial license has been LGPL-2.1-or-later, incorporating this into GPL software might require a license "upgrade" as well.

The lines of code that were in the original project (and that are still in Pyphen) have been originally released on LGPL, you can take them from the original repository and use them under LPGL forever. Of course, you can also distribute them under GPL if you want, or MPL, because LPGL allows this. That’s why the original LPGL code can be distributed in Pyphen under LPGL, MPL and GPL.

The lines of code I wrote are tri-licensed, but I can decide to diffuse them using another licence whenever I want. Of course, anyone who has a repository with these lines can forever distribute them with one of the original 3 licenses. I can even give you the explicit right to use them under the LPGL licence if I want (even if it’s not required, in my opinion). The same apply to other contributors.

[stefan6419846]

Thanks for another heads-up.

as far as I know, tri-licensed means that it’s distributed under the 3 licenses, and that you can choose the one you want.

This is only partially correct. "Tri-licensed" generally is an ambiguous term, it just means that we have three licenses. It does not explicitly state their relation and could (in theory) be any combination of them. This is why there are unambiguous expressions like the SPDX ones, which would mean GPL-2.0-or-later OR LGPL-2.1-or-later OR MPL-1.1 for Pyphen according to you.

Maybe. Maybe licenses can be applied to dictionaries, maybe not. If they are, maybe these dictionaries can be considered to be statically bounded to the hyphenation library, maybe not. But, well, Pyphen works without these dictionaries, so the hard link is not obvious.

Out of curiosity, I dug through the licensing/copying statements of the hyphenation files currently shipped by Pyphen and found some exact license expressions, but some ambiguous statements as well:

• Missing versions like GNU LGPL license.
• Combinations without details like MPL/GPL/LGPL.
• No clear copyright statements at all (seen for hyph_id_ID.dic, hyph_lv_LV.dic and hyph_sk_SK.dic).

Considering that Pyphen ships/distributes the corresponding files, it might make sense to explicitly include the (claimed) copyrights and licenses for the hyphenation patterns as well to correctly credit the the authors/maintainers. This might avoid the confusion, make some licenses more clear and simplifies redistributing Pyphen while ensuring correct attribution.

[liZe]

This is why there are unambiguous expressions like the SPDX ones, which would mean GPL-2.0-or-later OR LGPL-2.1-or-later OR MPL-1.1 for Pyphen according to you.

Changed in README.

Considering that Pyphen ships/distributes the corresponding files, it might make sense to explicitly include the (claimed) copyrights and licenses for the hyphenation patterns as well to correctly credit the the authors/maintainers.

As you said, many don’t even include a serious copyright statement. But well, you’re right, when they exist, we’ll include them in the dictionary files.