Skip to content

Slugify licensing update and PRs #166

Closed
Closed
Slugify licensing update and PRs#166

Description

@un33k
un33k
opened on Jan 8, 2026

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

Activity

  1. Arian-Ott commented on Jan 9, 2026

    @Arian-Ott
    Arian-Ott
    on Jan 9, 2026
    Collaborator

    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.

  2. ndrezn commented on Jan 12, 2026

    @ndrezn
    ndrezn
    on Jan 12, 2026

    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.

  3. Arian-Ott commented on Jan 12, 2026

    @Arian-Ott
    Arian-Ott
    on Jan 12, 2026
    Collaborator

    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

  4. ndrezn commented on Jan 12, 2026

    @ndrezn
    ndrezn
    on Jan 12, 2026

    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!

  5. Arian-Ott commented on Jan 12, 2026

    @Arian-Ott
    Arian-Ott
    on Jan 12, 2026
    Collaborator

    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.

  6. Arian-Ott commented on Jan 12, 2026

    @Arian-Ott
    Arian-Ott
    on Jan 12, 2026
    Collaborator

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

  7. ndrezn commented on Jan 12, 2026

    @ndrezn
    ndrezn
    on Jan 12, 2026

    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).

  8. Arian-Ott commented on Jan 12, 2026

    @Arian-Ott
    Arian-Ott
    on Jan 12, 2026
    Collaborator

    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.

  9. Arian-Ott commented on Jan 12, 2026

    @Arian-Ott
    Arian-Ott
    on Jan 12, 2026
    Collaborator

    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.

  10. Repository owner locked as resolved and limited conversation to collaborators on Jan 12, 2026

  11. un33k commented on Sep 8, 2026

    @un33k
    un33k
    on Sep 8, 2026
    OwnerAuthor

    This is Dojo, posting a maintainer-authorized follow-up linking this issue to #191.

    Addressed through backend, installation and license documentation. The base text-unidecode dependency remains; extras are additive. No blanket legal assurance is made.

    Closing this item under the maintainer’s consolidation decision. The default algorithm remains legacy; improved output rules are opt-in. This note does not announce a published release, and no individual PR is being merged by this follow-up. Thank you for the contribution and discussion.

    🚀 Generated with Dojo ⛩️

  12. un33k
    closed this as completedon Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions