Summary

The upstream project rfc3987-syntax appears to be unmaintained, while the functionality it provides is still relevant.
To ensure continued availability and compatibility with modern Python versions, I intend to:

• Fork the project
• Apply necessary fixes and maintenance
• Package the fork under a new PyPI name
• Publish and maintain it going forward

This ticket documents the plan, legal considerations, and required tasks.

Motivation

• The upstream repository shows no recent activity.
• The PyPI package is outdated and may no longer meet current ecosystem requirements.
• Users benefit from a maintained and installable version.
• The MIT License explicitly allows forking, modifying, and redistributing the software, provided attribution is preserved.

Publishing a maintained fork ensures the community continues to have access to a working implementation.

Scope of Work

• Create and maintain a fork of the original repository
• Update packaging metadata and project structure
• Publish the fork under a distinct PyPI package name
• Document the fork’s purpose, changes, and maintenance status
• Ensure full MIT License compliance (see Appendix A)

Appendix A — Legal Obligations (MIT License Compliance)

To remain fully compliant with the MIT License when forking and publishing, the following obligations must be met:

1. Preserve the original MIT License

• Keep the upstream LICENSE file exactly as provided.
• Do not alter or remove the original copyright.

2. Add a new copyright notice

Add a line such as:

Copyright (c) 2024 <Your Name> — modifications and maintenance.

3. Clearly identify this as a fork

• State in the README that this is a maintained fork of the original project.
• Link to the upstream repository.
• Describe the purpose of the fork.

4. Use a distinct PyPI package name

• PyPI does not allow overwriting the original package.
• Choose a new name that avoids confusion and does not imply upstream endorsement.

5. Avoid trademark issues

• Do not reuse protected names or branding from the original project.
• Descriptive names (e.g., rfc3987-syntax-ng) are safe.

6. Do not imply upstream endorsement

• Make it clear that the original author(s) are not responsible for this fork.

7. Document changes

• Maintain a changelog or a “Differences from Upstream” section in the README.

Appendix B — Tasks Checklist

Repository Setup

• Fork upstream repository
• Preserve original LICENSE
• Add new copyright notice
• Add LEGAL_NOTES.md summarizing obligations
• Update README to explain the fork
• Add link to upstream project
• Document changes and maintenance goals

Packaging & Metadata

• Choose a new PyPI package name
• Update pyproject.toml / setup.cfg
• Update author/maintainer fields
• Update project description to reflect fork status
• Add appropriate PyPI classifiers

Publishing

• Build the package
• Upload to TestPyPI
• Verify installation works
• Publish to PyPI
• Tag initial release (e.g., 0.1.0)

If additional documentation is needed (e.g., a LEGAL_NOTES.md, a README fork notice, or a suggested PyPI name), it can be added in follow‑up tasks.

after all is done, ask the authors of existing hanging PR's tp pullrequest their changes

• Make is_valid_syntax parts lazy loaded willynilly/rfc3987-syntax#14
• Remove incorrect license data willynilly/rfc3987-syntax#13
• Lazy import (after #11) willynilly/rfc3987-syntax#12
• Speed up import ~9x by using one shared Lark parser willynilly/rfc3987-syntax#11
• Fix a typo in RFC3987_SYNTAX_TERMS willynilly/rfc3987-syntax#9
• Lazy-load syntax validators on attr access willynilly/rfc3987-syntax#8
• tests: parameterize willynilly/rfc3987-syntax#6
• tests: additional tests for ucschar, iprivate, IPv6address willynilly/rfc3987-syntax#5
• fix: grammar according to rfc3987 willynilly/rfc3987-syntax#4