Symlink-or-copy LICENSE / LICENSE-* in workspace root when creating new member

[epage]

Problem

I just ran cargo new in a workspace and I had to manually copy over the license files.

Proposed Solution

LICENSE / LICENSE-* file names are a fairly strong convention that automatically linking them into a new package automatically seems to fit in along with our other workspace inheritance logic.

iirc we automatically move workspace.package.license-file into the package on publish, so we could skip this if that is set.

Notes

No response

[epage]

We discussed this in today's meeting.

The underlying need is "include license files in .crate"

license-file is automatically copied over on cargo package and cargo new will inherit the field if in the workspace but license-file is intended for custom licenses and is discouraged (via warning) to mix with license

That behavior around license-file is often confusing to users (e.g. #9908) and there are improvements we should probably make around it.

For example, what if we had

license = "MIT OR Apache-2.0"
license-file = { MIT = "LICENSE-MIT", "Apache-2.0" = "LICENSE-APACHE" }

(with us doing extra serde work to provide a good error message for Apache-2.0 which would be ["Apache-2", "0"])

See also #8537 (comment) for ideas that get into changes to SPDX

So what does that mean in the short-term? Most things we do with cargo new are two-way doors so we could do this now and then pivot in the future.

• There was some hesitance about blindly copying files from the workspace root. It could be a thing we exclusively do if we also inherit workspace.package.license.
• While I use symlinks, Windows users can have enough problems with them we might not want to push out a general policy that uses them
• If we instead copy files, that could cause problems for people who put copyright statements in the license files (either listing copyright holders or copyright years) as they would then need to copy these throughout their repo.

We could create a generalized solution, like

• package.extra-files for publishing but then we need to map where files come from to where they go
• workspace.new-files for saying what files to copy but then we are getting even more into templating which we're hesitant on.

For me, it seems like a short-term solution is not worth it. Hopefully someone (@joshtriplett ?) takes on a long-term solution.

[Manishearth]

I agree that the short term solutions don't seem worth it, a long term solution seems great.

extra-files could be allowed to be an array (in which case it copies to the root) but also a map if really requested. One open question is if those files are workspace-relative when specified in the workspace (I think they should be).