Kozea / Pyphen

Hy-phen-ation made easy
https://courtbouillon.org/pyphen
Other
198 stars 24 forks source link

Licensing #52

Closed stefan6419846 closed 1 year ago

stefan6419846 commented 1 year ago

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 commented 1 year ago

Hi!

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

Short summary:

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

stefan6419846 commented 1 year ago

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 https://github.com/Kozea/WeasyPrint/issues/944#issuecomment-533312532 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 https://github.com/Kozea/Pyphen/commit/a15ec969f6e89b70f0de7bb125ee402224d2aa4a: While the initial license has been LGPL-2.1-or-later, incorporating this into GPL software might require a license "upgrade" as well.

liZe commented 1 year ago

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 commented 1 year ago

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:

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 commented 1 year ago

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.