[gkmngrgn]

Summary

The repo has shipped an MIT LICENSE since #74 (following #68), and the wheel bundles it. But pyproject.toml and .speakeasy/gen.yaml leave the license unset, so the published distribution has no License-Expression, no license field, and no license classifier. Scanners that read package metadata (such as Aikido) find nothing there and fall back to reporting clerk-backend-api as Proprietary. Every project that depends on the SDK gets a critical license finding as a result.

This PR declares the license in both places:

• .speakeasy/gen.yaml: python.license: "" becomes MIT, so future generations carry it.
• pyproject.toml: adds license = "MIT" (a PEP 639 SPDX expression) to [project], so the current tree builds with it.

PR #245 set the precedent of changing a gen.yaml value and the matching pyproject.toml entry together.

No version bump, no regenerated code, and no License :: classifier. PEP 639 deprecates the classifier when License-Expression is present, and some tools reject the combination.

Before / after

Wheel METADATA from an isolated build (python -m build, poetry-core 2.5.0):

Before (main):

Metadata-Version: 2.4
Name: clerk-backend-api
Version: 7.0.0
Summary: Python Client SDK for clerk.dev
License-File: LICENSE
Author: Clerk

After:

Metadata-Version: 2.4
Name: clerk-backend-api
Version: 7.0.0
Summary: Python Client SDK for clerk.dev
License-Expression: MIT
License-File: LICENSE
Author: Clerk

The sdist PKG-INFO shows the same License-Expression: MIT.

Please check on the next generation

Merging this does not publish anything by itself. The fix reaches PyPI with the next Speakeasy generation, which renders pyproject.toml from python.license. Could you confirm that generation keeps exactly one license = "MIT" in [project]? .speakeasy/gen.lock has persistent edits enabled for pyproject.toml. If the generator writes the license in a different place or format than the line added here, the merge could produce a duplicate license key, which is invalid TOML.

I know CONTRIBUTING asks for issues rather than direct PRs on generated code. This touches only generator config and the matching pyproject.toml line, so I hope it's small enough to take directly.