LICENSE.txt

[GaryJones]

Since the contents of the GPL license don't need to be within each or any file, then it may be beneficial to move the contents to a LICENSE.txt file. Any further commits on this file then stand out more than just text within another file, which make any licensing changes for the project easier to spot.

That leaves the plugin header License tag with GPL-2.0+ as the default value, as per the SPDX registry.

[grappler]

Otherwise you could do something like this. https://github.com/Automattic/_s/blob/master/style.css#L8-l9

[GaryJones]

That's actually what I prefer (except using the SPDX standard identifier), but some folks prefer to keep a copy of the license within the project, so that the copyright info can be maintained.

[tommcfarlin]

This conversation is actually one that I've been on the fence about for a while. The majority of the time, I simply place the license in the header of the file despite the fact that it rarely changes and takes up a bit of space.

It tends to me more commonly done (which doesn't mean that it's the best way, though).

When it comes to bundling the license with the project, I lean in the direction of including it rather than just providing a URL, because I want developers (and users in real world products) to have the full product with them. Since the license is part of the product, I see it as being a bit fragmented.

Any further commits on this file then stand out more than just text within another file, which make any licensing changes for the project easier to spot.

This has convinced me to move it to another file; however, I'm going to opt to include an unversioned copy of the GPL. Back in March, Chip Bennett shared a note on why this matters.

The crux of it is this:

The most likely occurrence of this issue is with Themes developed using Twitter Bootstrap. When reviewing such Themes, please be sure to check that, if the Theme is licensed under GPL, that the license specifies either unversioned GPL, or GPLv3.0.

Since I don't know what frameworks the developers will use with this boilerplate, I want to make sure that it's built in their favor rather than including something that may be against current licensing issues.

[GaryJones]

My understanding of it, is that there's no such thing as "unversioned". There's version 1, 2 and 3, and what you've included here is version 3. If version GPL 4 is released after someone creates a plugin from your boilerplate, then the contents of the license.txt file in that plugin won't automagically update, so it will be stuck on version 3.

If you really mean the latest version of the GPL, then what you really mean is GPL 3 or later, which is identified via GPL-3.0+.

Plugins released under version 3, or 3 or later, can be accepted into the .org repo, but components of it can't then be submitted for inclusion into core as a patch. I think the recommendation is to keep plugins as GPL 2 or later, if possible, since that is what core itself is.

My suggestion would be to include the license text from GPL2 into LICENSE.txt (I think this is what WP itself does), use a version 2 specific URL for a License URL (as a side note, WordPress.com just asked StudioPress to change the Genesis framework from the agnostic URL to a version 2 specific URL), and change the License value to GPL-2.0+.

This then brings the boilerplate default, and therefore any plugins built from it, in line with WordPress itself, and allows plugin users to use them in GPL2-only systems (which wouldn't be possible with plugins that are GPL3 or later). Plugin authors can still artificially limit the use of their plugin if they really want, but it's not something the boilerplate should be encouraging, IMO.

[tommcfarlin]

The file links to version 3 of the GPL but notice the URL includes gpl.txt, so - presumably - this file will also include whatever is to be considered the most recent "unversioned" edition of the license so this was intentional.

FWIW, the back and forth with the conflict in licenses and making sure that we're catering to all the various conditions is a little tedious and I wish it wasn't really even an issue. Such is the nature of the development world, I guess.

My team and I have been sticking with the second version of the license in our work and we've never been asked to change based on the reviews from the Theme Team, of course this probably has more to do with the environment in which it's running than anything else.

My concern still remains that if plugin authors opt to use frontend frameworks in their work:

If the Theme is licensed under GPL, that the license specifies either unversioned GPL, or GPLv3.0.

And I assume the same still stands true with plugins.

So the suggestion of rolling with GPL2.0+ is something with which I'm content, though I still may provide a note about licensing in the documentation for this particular issue.

[GaryJones]

If someone opts to add anything to the boilerplate, then it's up to them to also check licensing considerations - it's not just a front-end / bootstrap / Apache 2.0 thing, and it's not sensible to try and explicitly cater for those conditions.

GPL-2.0+ is sensible default, which will cover most plugins built from the boilerplate.

[tommcfarlin]

Done and done with a note left in the README as per this commit.