Dual-Licensing Gutenberg: Should we keep some code GPL-only

[mchowning]

What problem does this address?

As part of the effort to dual-license Gutenberg under the GPL and MPL licenses, we may want to keep some of the WordPress specific modules GPL-only since they are unnecessary for any client using Gutenberg outside the context of WordPress.

Possible concern

This issue is for discussion of what code we want to keep GPL-only and how we want to accomplish that. In doing this, we need to ensure that there is a way to generate a bundle that is guaranteed to only have dual-licensed code (i.e., no GPL-only code). That bundle would be used by mobile clients and clients that are not WordPress-related.

[gziolo]

There are a few packages that make sense only in the WordPress core context, the web version which in theory could stay licensed as GPL:

• packages/customize-widgets
• packages/edit-navigation
• packages/edit-post
• packages/edit-site
• packages/edit-widgets
• packages/list-reusable-blocks

Some that are deprecated or aren't used on production:

• packages/block-serialization-spec-parser
• packages/nux

Some are tools that could as well be MIT licensed like:

• packages/create-block
• packages/create-block-tutorial-template
• packages/docgen
• packages/env
• packages/e2e-test-utils
• packages/e2e-tests
• packages/project-management-automation
• packages/scripts

there is more, I can provide the full list if necessary.

[adamsilverstein]

If dual-licensing proceeds, we need to consider the code that was brought over to Gutenberg from WordPress core, then published as npm packages and consumed by core from npm. I'm thinking about packages like a11y, api-fetch, dom-ready, hooks, i18n, url, wordcount and probably others I am missing.

For these packages, I feel like we would need to get approval from the original code authors for the code that was brought over from WordPress core. Have you looked at these code sources?

[mchowning]

If dual-licensing proceeds, we need to consider the code that was brought over to Gutenberg from WordPress core, then published as npm packages and consumed by core from npm.

Thanks for bringing this up @adamsilverstein. It is an issue we need to address for sure.

For these packages, I feel like we would need to get approval from the original code authors for the code that was brought over from WordPress core.

That is the preferred way to handle it. The only other options I see are to remove/rewrite those parts of Gutenberg or, if these parts of Gutenberg would only be needed when Gutenberg is used as part of WordPress, we might be able to create two Gutenberg releases: one would be a GPL-only Gutenberg-for-use-with-WordPress, and the other would be a dual-licensed Gutenberg-for-use-outside-the-context-of-WordPress, which would not contain any of the WordPress GPL-only code. The two release idea is really just an idea, I do not have a good sense for whether that would be possible or feasible, so getting permission from the previous authors certainly seems preferable.

[mchowning]

It seems that the next step is to identify all code that was brought over to Gutenberg from another repository (i.e., WordPress Core). That will allow us to make a decision about whether we are better off:

• attempting to get consent to relicense that code from its original authors;
• creating separate releases for use with/without WordPress (with any GPL-only code only being included in the release for use with WordPress); or
• some other idea I haven't thought of

What would be the best way to identify this code that was brought into Gutenberg from somewhere else?

[adamsilverstein]

Thanks for working on this @mchowning - it is a huge undertaking and I realize my bringing this up only complicates your work. I still felt it important to bring up because otherwise it could come back to cause much worse pain later when the omissions were discovered.

What would be the best way to identify this code that was brought into Gutenberg from somewhere else?

One idea would be to look at the earliest commits from the packages, you could then cross reference these code blocks with the core repo and use Git or svn to determine the original author there.

This would be a good place to start:

#7556

I believe that all or most of the packages introduced in this PR are code ported directly from WordPress core:

You would then look for this code in core, where it was removed roughly around the same date (Jul 9, 2018). I would expect the git mirror to contain the correct attributions: https://github.com/WordPress/wordpress-develop

One other approach would be to review the core trac tickets where packages were initially created by extracting core code:

For example: https://core.trac.wordpress.org/ticket/45066

[mchowning]

Can we safely assume that only javascript changes might have been copied from WordPress into Gutenberg? If so, that makes the search a lot easier.

Any thoughts on this @adamsilverstein ?

[adamsilverstein]

Can we safely assume that only javascript changes might have been copied from WordPress into Gutenberg? If so, that makes the search a lot easier.

All of the packages I mentioned above are entirely JavaScript, so yes you can safely assume that for the packages I mentioned. I'm not aware of any other code that was imported.

[mchowning]

Noticed that stylelint-config-wordpress was copied into Gutenberg last year, but I don't think that's an issue for the dual-licensing because that code was MIT-licensed in the original repo, which liberally permits relicensing and is GPL-compatible.