Resolve license and packaging metadata mismatch (pyproject.toml vs setup.py)

[DhanashreePetare]

Summary:
The repository currently exposes conflicting packaging metadata: the PEP 621/PEP 517 configuration in pyproject.toml lists the license as Apache-2.0 and uses hatchling as the build backend, while setup.py sets license="GPL" and declares legacy fields such as python_requires=">=2.7". Having two authoritative sources with different values creates legal and tooling ambiguity.

Impact:

• Legal uncertainty for downstream users and redistributors due to conflicting license declarations.
• Packaging and release tooling may produce mismatched metadata in published artifacts.
• Contributor confusion about project policy (license, supported Python versions).
• CI/dependency automation may behave inconsistently.

Recommended resolution:

• Choose a single canonical metadata source (prefer pyproject.toml since the project already uses hatchling) and document it in README.md or CONTRIBUTING.md.
• Make license metadata consistent: update pyproject.toml or setup.py so both show the same license, and ensure the LICENSE file matches.
• Align Python support (python_requires / project.requires-python) to supported versions (recommend dropping Python 2 and declaring >=3.8).
• Simplify or remove redundant setup.py (if kept, make it a minimal shim that reads metadata from pyproject.toml).
• Add CI checks to validate package metadata during builds (e.g., python -m build + inspect generated METADATA).

Suggested PR scope:

• Update license fields to Apache-2.0 (or change both files to GPL if that is intended).
• Add/update LICENSE file if needed.
• Add a short note in README.md/CONTRIBUTING.md clarifying that pyproject.toml is authoritative.
• Run a local build and report metadata verification in PR description.

[codebynikhil08]

The PR fixes duplicated content in pyproject.toml and clarifies authoritative packaging metadata.

Changes made

Removed duplicated pyproject.toml configuration
Declared supported Python versions (>=3.8)
Aligned license metadata to reference the LICENSE file
Verification

Ran python -m build successfully
Confirmed generated metadata is correct
Notes
These changes reduce packaging ambiguity, improve tooling compatibility, and make the packaging metadata clearer and more consistent.

[DhanashreePetare]

sorry @codebynikhil08. but I am not able to see any commits and PRs for the same. Did you mean something else

[Hellboy28D]

@DhanashreePetare i Want to work on this . Please assign me this issue

[RitikaSen27]

Hello,

I’d like to take this issue. I have examined the existing packaging structure and concur that the use of conflicting authoritative metadata between the pyproject.toml (PEP 621 / hatchling) and setup.py brings about legal ambiguity as well as tooling inconsistencies.

My proposed approach is:

Use only a single canonical source of package metadata, i.e. pyproject.toml, as hatchling is already used and write up in README.md or CONTRIBUTING.md.

Make license statements consistent across all files and make sure that the LICENSE file is the same as the license selected. Any change that might impact licensing will be confirmed with maintainers before making any change.

Maintenance Python version Support Python version support should be updated to reflect the currently supported versions (Python 2 will be dropped, python requirements / requires-python values should be the same, e.g. >=3.8).

Reduce setup.py to a simple shim, or eliminate it if it is not necessary anymore, to prevent identical metadata.

PR Python -m build and inspect the generated METADATA Check the final package metadata with python -m build and Inspect the final package metadata with python -m build.

I will just maintain the PR area to metadata cleanup and documentation only, without any alteration of runtime behavior. It is important to know whether this direction is acceptable or there are project-specific constraints that I should adhere to.
I would want to take up this issue if its okay.

Thank you.

[DhanashreePetare]

@Hellboy28D , and @RitikaSen27, I don't have these permissions. I opened it but want to get the issue verified by the authors first.

[mightqxc]

@tmaeno I don't have strong opinion about this. Do you have some comment?

[Hellboy28D]

@DhanashreePetare Thanks for information