Slugify licensing update and PRs

[un33k]

All,

Slugify is a mature Python utility under a permissive license. It does not automatically install any GPL dependency. Users may opt in if they choose to add one. The creator of Unidecode confirmed that this model is clean and acceptable.

Licensing issues are closed automatically. Breaking change requests are closed automatically. The package is intentionally simple and focused on one job.

If you have edge cases, prepend or append your own logic around slugify to meet your needs.

Feel free to clone or fork the code as you wish, however python-slugify is a reserved namespace. Please do not register python-slugify-1, python-slugify-2, python-slugify-x or other confusing variants.

Val

[Arian-Ott]

Except this package does require install of a GPL dependency: See https://github.com/un33k/python-slugify/blob/master/setup.py#L14. text-unidecode is GPL licensed and it's not possible to install this python-slugify without also installing text-unidecode.

Certainly, developers could write a fork of python-slugify that removes the required dependency text-unidecode but it's misleading to say python-slugify "does not automatically install any GPL dependency", when it clearly does... If the maintainer of text-unidecode doesn't want a copyleft license, then I would expect to see the license changed in that library, unverified guarantees aren't representative of a license agreement.

No, it doesnt.

Check PR #163 for an explanation.

[ndrezn]

Ah, I misunderstood the licensing as text-unidecode allows the user to choose their license. Original comment removed.

I think it would be useful to clarify in this pinned issue that text-unidecode allows users to choose Artistic License as part of their statement -- that confusion (myself included 😅) is likely what is causing this issue to come up so often.

[Arian-Ott]

Ah, I misunderstood the licensing as text-unidecode allows the user to choose their license. Original comment removed.

Good. Next time please avoid deleting comments in PR or issues. They help others to understand other contributors the context of the conversation.

I think it would be useful to clarify in this pinned issue that text-unidecode allows users to choose Artistic License as part of their statement -- that confusion (myself included 😅) is likely what is causing this issue to come up so often.

The readme explains this in the the license section.

https://github.com/un33k/python-slugify#license

[ndrezn]

FWIW, the licensing documentation is confusing:

Released under a (MIT) license.

Notes on GPL dependencies

Though the dependencies may be GPL licensed, python-slugify itself is not considered a derivative work and will remain under the MIT license.
If you wish to avoid installation of any GPL licensed packages, please note that the default dependency text-unidecode explicitly lets you choose to use the Artistic License instead. Use without concern.

It can be plausible interpreted from this that python-slugify has GPL dependencies, with the use of the word, "may". I would recommend something like:

License

Released under a (MIT) license.

Notes on dependencies

python-slugify has text-unidecode as a dependency, which can be redistributed under the Artistic License or the GPL license. As a result, the default installation of python-slugify does not necessarily require GPL dependencies and can be further redistributed under a non-copyleft license.

Or similar. The current phrasing is ambiguous, leading to confusion unless a developer does homework. Given the amount of confusion on this issue I think it's worth the effort to clarify that section. Happy to open a PR, cheers!

[Arian-Ott]

I don't think there is much of a problem. The readme explains the License well enough imho.

Though the dependencies may be GPL licensed, python-slugify itself is not considered a derivative work and will remain under the MIT license.

Also Val explained that licensing issues will be closed automatically and there is no record of any legal troubles with using slugify. Hence, a change is not needed.

Licensing issues are closed automatically. Breaking change requests are closed automatically. The package is intentionally simple and focused on one job.

[Arian-Ott]

And those developers who care about the license will do their homework. Those who just pip install don't care :)

[ndrezn]

Totally agree a code change isn't needed.

there is no record of any legal troubles with using slugify

Plotly customers have dropped software we distribute that depends on python-slugify because of license confusion, specifically out of consideration of possible legal issues. I think a docs change would help with this kind of issue (which clearly comes up a lot, given the number of issues folks raise).

[Arian-Ott]

I understand that there can be some confusion with non-technical people. But it would be the job of plotly to educate the customers that there is absolutely no legal risk.

text-unidecode is released under GPL2 or Artistic license, this debate shouldn't have happened.

Legally a documentation is from my perspective irrelevant.

In FLOSS the contents of the LICENSE file is significant. In Debian packaging we trust upstream that they did their homework and selected the license correctly. If developers can't rely on the license specification, development cycles would slow down.

[Arian-Ott]

I think everything has been said on this topic. Since the licensing is clearly defined in the LICENSE file and Val has already provided a final statement in the issue #166, I'll lock this Issue now to keep the discussion focused on technical contributions. Thanks for your understanding.