[http-client-rust] License generation for client Implementation

[lmazuel]

Services can define custom licenses. See https://azure.github.io/typespec-azure/docs/howtos/generate-client-libraries/02package/#unbranded-license.

In this case, we should probably emit (or even update?) Cargo.toml to use a license-file with a manifest-relative path to the file we'd have to generate e.g., LICENSE.txt and not use license.workspace = true.

[jhendrixMSFT]

@heaths do we need a LICENSE.txt file per crate? I don't see any such files at present.

[heaths]

All the crates inherit the license = "MIT" workspace field. If there are more requirements here that it has to be our "branded" MIT license file and why (it's not typical to ship a license file for standard license types), I can change that. @lmazuel can you please expand (in general; this title on its own is ambiguous as was the namespace one).

[heaths]

/cc @ronniegeraghty. As I noted above, license files aren't common to ship in crates that use standard license SPDXes. And you can't have both a license and license-file. We could, however, package the LICENSE.txt in crates but why? Nothing will surface it and the crate is already idiomatically covered by the license package metadata. It'd be useless.

See https://doc.rust-lang.org/cargo/reference/manifest.html#the-license-and-license-file-fields (I guess it's only a warning, though we do turn warnings into errors).

[lmazuel]

Related work:

• [tcgc] add license config support typespec-azure#2353
• https://azure.github.io/typespec-azure/docs/howtos/generate-client-libraries/02package/#unbranded-license

This is about integrating the licence from TCGC YAML, in order to know what licence to use in the generated code. For instance, generated code that is MIT in all headers and contains the right file.

[heaths]

For context, it is idiomatic and common to use an SPDX identifier in Cargo.toml e.g., license = "MIT", which we do currently. license takes precedence over license-file. So we would have to elide license and use a license-file that points to the license file we'd generate, which from the PR above seems to be a custom branding (and a little more) of an MIT license.

I emailed CELA, but comparing with Azure SDK for JS, they do use a license SPDX: https://github.com/Azure/azure-sdk-for-js/blob/4eed3b9c9829e7fc6b5fe346c63769999d2ba4bc/sdk/keyvault/keyvault-secrets/package.json#L6

But also include the license file: https://github.com/Azure/azure-sdk-for-js/blob/4eed3b9c9829e7fc6b5fe346c63769999d2ba4bc/sdk/keyvault/keyvault-secrets/package.json#L31

We could, as a loose file, but there's really no good reason to. People aren't going to see it. Even dubious for NPM packages (also zips) but at least those typically go into your project source tree under node_modules/ while crates are all unzipped together for any project for your user in ~/.cargo/.

Also to note, it behooves us - though IANAL - to show "MIT" because:

VS a license-file even if it just a branded standard license like MIT (like our LICENSE.txt is):