License issues

[marcelbuesing]

This issue might be problematic:
tapeinosyne/hyphenation#17

Although the hyphenation crate is an optional dependency there are quite a number of files licensed as GPL. I am not a licensing expect but this seem troublesome. It also comes up when using https://fossa.com checking crates that depend on clap. Because clap depends on textwrap, although it does not use the hyphenation feature (Apparently fossa is not aware of cargo features).

[mgeisler]

Hi Marcel, thanks for letting me know about this.

From reading tapeinosyne/hyphenation#17 and the license information for hyphenation on https://github.com/tapeinosyne/hyphenation#license, it seems that

• The hyphenation crate is licensed under the MIT or Apache 2.0 license (choose that one you like the best).

• The individual hyphenation patterns are licensed under a myriad of different licenses. This is also mentioned in the hyphenation README.

So a commercial program should probably use the code from hyphenation and the ship the hyphenation patterns they need as individual files.

To use textwrap with hyphenation, one would then have to overwrite the

hyphenation = { version = "0.7.1", optional = true, features = ["embed_all"] }

dependency line from textwrap so that hyphenation does not use the embed_all feature.

From reading about the manifest format in Cargo, it seems that it's not actually possible for people to do this today!

Hmm... I wonder how one can work around this? Perhaps textwrap could add a hyphenation-no-embed feature, which would do

[features]
hyphenation-no-embed = ["hyphenation/???"]

to somehow include hyphenation but without its embed_all feature enabled. The documentation seems to mostly talk about additive features and I'm not sure how one would specify default-features = false in this format.

[tapeinosyne]

I should note that although the individually licensed pattern files (under patterns/*.txt) are part of the Cargo package as distributed through crates.io, they are not themselves part of any build artifact generated by hyphenation.

What embed_all embeds – and what the library can use – are serialized hyphenation dictionaries (dictionaries/*.bincode) obtained by parsing those patterns and translating them into a custom representation.

So, as for:

a commercial program should probably use the code from hyphenation and then ship the hyphenation patterns dictionaries they need as individual files.

That depends on whether the GPL propagates from the source patterns to the serialized dictionaries, which is unclear to me. (Before that, it is unclear to me how to correctly apply the GPL to something that is rather closer to data than code.)

[mgeisler]

Thanks @tapeinosyne for the explanation! I agree that it's hard to see how the GPL should apply to a program that loads a piece of data (the .bincode file) at runtime.

The GPL FAQ has a question about a similar situation where a proprietary program can load a module licensed under the GPL. It boils down to whether the two form a combined program:

If they form a single combined program then the main program must be released under the GPL [...]

However, if they are separate works then the license of the plug-in makes no requirements about the main program.

The above is about a main program that executed code in a loadable module. It's not well-defined when GPL plugins and a main program become a combined program:

It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. [...]

If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

I would argue that the situation is very different when a program uses textwrap/hyphenation: the program doesn't load and execute code from a GPLed module. Instead it loads and deserializes data (the hyphenation patterns in the .bincode files). The data format is not intrinsic to the GPLed languages — the data format is shared with all the MIT, Apache, etc... licensed languages.

Ultimately, the licensing question is for the program author to decide. If you write a CLI tool that uses textwrap with the hyphenation feature and if you rely on the GPLed hyphenation patterns of, say, Czech, then perhaps you could argue that your program is a combined work that should be distributed under the terms of the GPL.

Note that the licenses differ from language to language. Luckily, the en-US hyphenation patterns are under a simple license:

% licence:
%     text: >
%         Copying and distribution of this file, with or without modification,
%         are permitted in any medium without royalty provided the copyright
%         notice and this notice are preserved.

I hope that should be good enough for a majority of use cases. I might even change the hyphenation feature in textwrap so it uses the new embed_en-us feature of hyphenation to only embed these patterns. Thankfully, users can still grab one of the precompiled .bincode files if they need support for other languages.

@marcelbuesing, thanks for raising the issue in the first place. Based on all the above, I don't think there is a problem in textwrap or hyphenation. I'll see if I can update textwrap as outlined above to make the hyphenation feature smaller and safer for people who are worried about accidentally including GPL licensed code in their application. Hope that works for you?

[mgeisler]

I think we can close this now.