back
2 comments
Has that ever actually been tested though? Ultimately, to work, a plugin only needs to call a handful of WP functions, if at all -- hard to argue it's a derivative work, just because it can be used _with_ WP. Is grep a derivative work of bash because you can use bash to execute grep?

Something like the following would be a valid plugin, but it doesn't directly or indirectly use _any_ code by WP. It's only executed by WP. I don't believe that it would be considered a derivative work of WP, because that file would happily run without WP as well.

<?php /* Plugin Name: My Plugin Version: 0.1 */

if($_SERVER["REQUEST_URI"] === "/my-url") { // do something interesting, use curl to fetch some content }

I've always been confused by this assertion, too. It's often the justification for privacy of paid plugins, too.

In addition to your example, I can imagine a very defensible scenario where a plugin is "standalone" with a shim layer to connect to WordPress (and maybe other CMSes, too).

Yeah, the infectious nature can hardly infect a third party software, even if the shim itself would be infected.

The one case I just remembered where it was remotely challenged was Thesis [1], but Automattic chose to throw money into bullying the challenger rather than going after the alleged license violation.

[1] https://wptavern.com/mullenweg-and-pearson-square-off-on-pat...

No, it must be according to the core‘s license, but if the plugin author doesn‘t license it as GPLv2, it isn‘t.

The plugin‘s author breaches the core‘s license, but that doesn‘t make the plugin GPLv2 by itself.