`--license` doesn't change `LICENSE` file

[ara303]

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

The --license argument doesn't behave differently when given values other than the default, MIT.

I tried several license names using the keywords from this page. I wasn't sure what else to use.

I wish to license my WP package under LGPL-2.1, because granting maximum freedoms is important to me.

(I recognise this is a low priority issue. I personally feel it's important for the OSS ecosystem that licensing be respected properly.)

Describe how other contributors can replicate this bug

I ran both:

• wp scaffold package <name> --license=GPL-2.0
• wp scaffold package-readme <dir> --license=BSD

Mustache templating works, but I notice it appears hard-coded to only operate on the MIT license.

Describe what you would expect as the correct outcome

When including the --license=<license_tag> parameter, I expect the license to change in the LICENSE file.

Let us know what environment you are running this on

OS:     Linux 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025 x86_64
Shell:
PHP binary:     /usr/bin/php8.4
PHP version:    8.4.18
PHP memory limit:       -1
php.ini used:   /etc/php/8.4/cli/php.ini
MySQL binary:   /usr/bin/mariadb
MySQL version:  mariadb from 11.8.6-MariaDB, client 15.2 for debian-linux-gnu (x86_64) using  EditLine wrapper
SQL modes:      STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      phar://wp-cli.phar/vendor
WP_CLI phar path:       phar:///usr/local/bin/wp-cli
WP-CLI packages dir:    /home/pc/.wp-cli/packages/
WP-CLI cache dir:       /home/pc/.wp-cli/cache
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.13.0-alpha-fa5285f

Provide a possible solution

Two that I can think of, but I'm absolutely open to ideas and feedback. I would be delighted to contribute a PR to fix this issue myself!

1. If the --license argument isn't intended to be any other than MIT (I note all wp-cli packages are MIT-licensed), the path of least resistance is to outright remove mention of --license.
2. If this is intended to be used, it should be compared against a list of known licenses, error if an unknown one is given, but if a valid license name is given then that license's text should be parsed with Mustache and then overwrite the current LICENSE text. I note Choosealicense.com (a GitHub-maintained repo) which could be used as a basis to expand the current templating.

[swissspidy]

Heya, thanks for opening this.

Yeah the current implementation is a bit half baked. I meant to revisit this.

We should support the most common licenses out of the box. Basically what https://choosealicense.com/ covers.

• MIT
• Apache 2.0
• GPL v2 or later
• GPL v3
• MPL

PRs welcome :)

[ara303]

Thanks so much, @swissspidy. I'd love to PR the second solution I mentioned above.

I haven't written any code yet but I'm thinking something like:

1. Expand current templates/ directory with a subdirectory, licenses/, that I'll manually populate with the common licenses from Choosealicense.com
2. Go through the text of those licenses and add the Mustache {{year}}, {{name}} and any other variables the license text wants.
3. Add a guard to src/ScaffoldPackageCommand.php for the code around the package and package_readme function that checks for the presence of --license and checks its value matches one of Choosealicense.com's.
4. Pass the validated value to the mustache_render function to pull the specified license text so Mustache can parse the variables.

The key thing to keep in mind is making sure I do it for both package and package_readme, I guess. Although it's hardly common to change a license during a project's lifespan, it may happen and I want to be thorough.

I'd also like to change README.md and specify a list of licenses supported – explaining that will help out, I think.

If the above sounds good and you approve I'll get to work on it when I have some time.

[swissspidy]

Sounds like a plan!

Please note that the README is auto-generated from the PHP documentation. So you can list the available license options there, and the README will be updated accordingly.
That will also automatically perform argument validation for you (convenient for step 3).

Also keep in mind thst the desired license is also populated in composer.json.

We might want to support --license=none if someone wants to add their own later on.

[ara303]

Got you on README.md auto-generation and argument validation. This week I converted a one-file CLI helper I use a lot to a WP package using scaffold and it's been awesome. That was actually where I found out the license generation needs improvement.

I have some design questions:

1. As per Composer docs, they strongly recommend "license": "proprietary" over omitting it, leaving it blank, or specifying none. Would you prefer:
   a. Use --license=none and map it internally to proprietary, or
   b. Use --license=proprietary instead of none?

2. Should wp scaffold package-readme also support changing license?
   a. Should --license=none delete an existing LICENSE file if present?
   b. Should "license": "<license_identifier>" be modified in composer.json if present?

My feeling is that scaffold-readme invoked with --license=[none|proprietary] means the user intends to strip all licensing-related data from their scaffolding (meaning both removing the file and setting the json to "license": "proprietary") but I wanted to ask for confirmation! 😀 Thank you.

[swissspidy]

Great questions!

1. a) sounds fine. We can always revisit later.
2. Let's try both

We also need a way to preserve the existing license if you currently use something custom. So perhaps that could be the default value if not explicitly specified.