How does this GPL licensing issue play out?
October 8, 2012 6:23 PM Subscribe
Are WordPress and Drupal themes, plugins, extensions, etc. legally obligated to be released under the GPL?
WordPress and Drupal core code is GPL. Are plugins and functions that interface with them using the supplied APIs etc. "derivative works" that must also be released under the GPL?
My understanding is that there was some furor over this question in the past, and Automattic's stance was that any PHP in plugins and themes must also be GPL. Drupal takes a similar stance. Is that the legal standard?
It seems odd to me, as plugins and themes don't alter the core code. Utilization seems separate to me from derivation. Were any actual legal opinions/decisions reached, or are there only the opinions of non-lawyers with extremely vested interests on one side or the other?
Part the second, assuming plugins and themes must be GPL (just roll with it, even if that's not the case): Am I correct in my understanding that the GPL cannot place restrictions on secondary distribution, so that if anyone purchases a premium WordPress or Drupal plugin or theme, which is GPL, they are then legally and morally free to distribute the source however they wish, including for free?
How (assuming GPL) would premium pay plugins that don't run on a service model (pay for support or whatever) make any meaningful number of sales, as surely the source code would become publicly available almost immediately?
Part the third, regardless of anything else: My understanding is that modifications of GPL code that are used internally by a person or company do not need to be shared. In other words, a company can take a GPL product, extend it for internal use, and not be required to release the code to anyone.
If the company used a GPL framework to power an online stopwatch API, it could sell access to the stopwatch service running on its own servers without being forced to disclose the derivative source. Is that correct?
Part the fourth: The Drupal licensing FAQ mentions that you can't build an intermediary framework or bridge and have non-GPL licensed code interact with the framework. The framework must be GPL, as would be anything interacting with the framework. That also seems counterintuitive to me. Is it correct? Has that perspective had a day in court, and what was decided?
WordPress and Drupal core code is GPL. Are plugins and functions that interface with them using the supplied APIs etc. "derivative works" that must also be released under the GPL?
My understanding is that there was some furor over this question in the past, and Automattic's stance was that any PHP in plugins and themes must also be GPL. Drupal takes a similar stance. Is that the legal standard?
It seems odd to me, as plugins and themes don't alter the core code. Utilization seems separate to me from derivation. Were any actual legal opinions/decisions reached, or are there only the opinions of non-lawyers with extremely vested interests on one side or the other?
Part the second, assuming plugins and themes must be GPL (just roll with it, even if that's not the case): Am I correct in my understanding that the GPL cannot place restrictions on secondary distribution, so that if anyone purchases a premium WordPress or Drupal plugin or theme, which is GPL, they are then legally and morally free to distribute the source however they wish, including for free?
How (assuming GPL) would premium pay plugins that don't run on a service model (pay for support or whatever) make any meaningful number of sales, as surely the source code would become publicly available almost immediately?
Part the third, regardless of anything else: My understanding is that modifications of GPL code that are used internally by a person or company do not need to be shared. In other words, a company can take a GPL product, extend it for internal use, and not be required to release the code to anyone.
If the company used a GPL framework to power an online stopwatch API, it could sell access to the stopwatch service running on its own servers without being forced to disclose the derivative source. Is that correct?
Part the fourth: The Drupal licensing FAQ mentions that you can't build an intermediary framework or bridge and have non-GPL licensed code interact with the framework. The framework must be GPL, as would be anything interacting with the framework. That also seems counterintuitive to me. Is it correct? Has that perspective had a day in court, and what was decided?
GNU Faq: Distribution
You are free to make modifications and use them privately, without ever releasing them...But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
where 'modification' is open to interpretation because there's very little case law(I am told, IANYL).
I have heard a commercial company (who authored some GPL JavaScript) assert that:
a) using the JavaScript at all created a derivative work - even unmodified.
2) opening a web page in a browser amounted to 'conveyance' (i.e. delivery) since the JavaScript is transmitted to the browser via http request.
C) the entire web app (front and back-end) would have to be GPLed, and source made available.
Whether or not these assertions are true may not be as important as 'will they get legal'?
I agree with xiw, the definition of derivative is a grey area, as are the definitions of modifications and conveyance. Sorry, not so helpful, but at least now you know it's not a really considered a trivial black and white issue. j_c
posted by j_curiouser at 8:00 PM on October 8, 2012
You are free to make modifications and use them privately, without ever releasing them...But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
where 'modification' is open to interpretation because there's very little case law(I am told, IANYL).
I have heard a commercial company (who authored some GPL JavaScript) assert that:
a) using the JavaScript at all created a derivative work - even unmodified.
2) opening a web page in a browser amounted to 'conveyance' (i.e. delivery) since the JavaScript is transmitted to the browser via http request.
C) the entire web app (front and back-end) would have to be GPLed, and source made available.
Whether or not these assertions are true may not be as important as 'will they get legal'?
I agree with xiw, the definition of derivative is a grey area, as are the definitions of modifications and conveyance. Sorry, not so helpful, but at least now you know it's not a really considered a trivial black and white issue. j_c
posted by j_curiouser at 8:00 PM on October 8, 2012
In the Wordpress world there was a major showdown about this a couple of years ago. (Overview of the story here.)
I don't know if this is the last word on the legal status, as this one did not go to court, and I haven't exactly been following the issue. However this case did get to the stage where the Wordpress founder took legal advice, threatened to sue, and also offered to pay for anyone to buy any other premium theme to help them move away from the one he felt offended about.
However, for what it's worth, there are plenty of paid themes that are GPL licensed, and while you might think people wouldn't pay for them, they actually do. (This is a well known example.)
posted by philipy at 8:17 PM on October 8, 2012
I don't know if this is the last word on the legal status, as this one did not go to court, and I haven't exactly been following the issue. However this case did get to the stage where the Wordpress founder took legal advice, threatened to sue, and also offered to pay for anyone to buy any other premium theme to help them move away from the one he felt offended about.
However, for what it's worth, there are plenty of paid themes that are GPL licensed, and while you might think people wouldn't pay for them, they actually do. (This is a well known example.)
posted by philipy at 8:17 PM on October 8, 2012
With respect to "derivative works", the argument isn't that the plugin is derived from Drupal, and must therefore be itself GPL licensed. Rather, the idea is that the combination of Drupal and the plugin is a derivative work of both, and this totality must respect the provisions of the GPL. The plugin itself may be under a different license, like the MIT License; as long as it's GPL-compatible, such that the combined work can comply with both licenses.
There's indeed debate about the validity of this argument. Some claim that using Drupal and the plugin are "mere aggregation", just two separate things side by side that aren't really a combination. Others say that the code for Drupal and the plugin are mingled in the memory of the Apache process as it runs, and that the plugin can't stand on its own in any way, so the combination must be a derived work of both.
For what it's worth, the position of the Free Software Foundation, who wrote the GPL, is that this is in fact a derived work. This has not been definitively decided in a court, AFAIK. However, about every time someone has challenged the FSF's interpretation, they've ended up settling out of court and complying with the GPL's terms. Some authors of GPL code are more or less litigative than others, but I'd personally hesitate to take my chances. Also, from a less legalistic perspective, the authors of such code are kindly allowing me to distribute and modify their software for many purposes. They chose the GPL for their code knowing its common interpretation, and I'd feel bad going against their intent. If you really badly want different licensing terms, you're free to offer to pay the authors for that, and sometimes they'll accept.
Onwards to your remaining practical questions. I'll be assuming the FSF's interpretation from here on.
It seems odd to me, as plugins and themes don't alter the core code.
Plugins are code, mixed in memory, yadda yadda. In the case of Drupal (and I think WordPress too?) themes are also typically code, so the same applies. But there's no reason you couldn't separate the code and non-code parts of a theme. So you could have a general theme framework under the GPL that includes some basic images and CSS. Then you'd have an add-on theme that only supplies alternative images and CSS without any code, and that could be proprietary if you want.
How (assuming GPL) would premium pay plugins that don't run on a service model (pay for support or whatever) make any meaningful number of sales...?
Sometimes this can be done with cleverness, see above. Some games have done this sort of thing, open-sourcing the engine so that people can hack on it, but leaving the resources under a proprietary license so you can't just give your friends the whole game. (You can do a similar sort of thing based on trademark law in some cases, but it's probably not useful for web dev.) As you pointed out, selling support, implicitly or explicitly, is another way to do this.
Premium plugins can also work just based on common consideration and psychology. Most people who have paid for a theme don't want to screw over the person who sold it to them, and don't want other people to get it for free.
Modifications of GPL code that are used internally by a person or company do not need to be shared... It could sell access to the stopwatch service running on its own servers without being forced to disclose the derivative source.
Correct.
You can't build an intermediary framework or bridge and have non-GPL licensed code interact with the framework
This is a bit more complicated. The general rule is that as long as there would be a combined work including both GPL and non-GPL-compatible code, it's not allowed. So if you had a proprietary PHP mapping module, you couldn't write a Drupal plugin that calls the module, because GPL and proprietary code would be mixed in memory. But if you instead have your plugin use the Google Maps API, that would be ok even though Google Maps is proprietary. Google's code is running somewhere else and communicating with your code over a common transport (HTTP), so there's no code being mixed.
Sorry for the wall of text!
posted by vasi at 8:49 PM on October 8, 2012 [1 favorite]
There's indeed debate about the validity of this argument. Some claim that using Drupal and the plugin are "mere aggregation", just two separate things side by side that aren't really a combination. Others say that the code for Drupal and the plugin are mingled in the memory of the Apache process as it runs, and that the plugin can't stand on its own in any way, so the combination must be a derived work of both.
For what it's worth, the position of the Free Software Foundation, who wrote the GPL, is that this is in fact a derived work. This has not been definitively decided in a court, AFAIK. However, about every time someone has challenged the FSF's interpretation, they've ended up settling out of court and complying with the GPL's terms. Some authors of GPL code are more or less litigative than others, but I'd personally hesitate to take my chances. Also, from a less legalistic perspective, the authors of such code are kindly allowing me to distribute and modify their software for many purposes. They chose the GPL for their code knowing its common interpretation, and I'd feel bad going against their intent. If you really badly want different licensing terms, you're free to offer to pay the authors for that, and sometimes they'll accept.
Onwards to your remaining practical questions. I'll be assuming the FSF's interpretation from here on.
It seems odd to me, as plugins and themes don't alter the core code.
Plugins are code, mixed in memory, yadda yadda. In the case of Drupal (and I think WordPress too?) themes are also typically code, so the same applies. But there's no reason you couldn't separate the code and non-code parts of a theme. So you could have a general theme framework under the GPL that includes some basic images and CSS. Then you'd have an add-on theme that only supplies alternative images and CSS without any code, and that could be proprietary if you want.
How (assuming GPL) would premium pay plugins that don't run on a service model (pay for support or whatever) make any meaningful number of sales...?
Sometimes this can be done with cleverness, see above. Some games have done this sort of thing, open-sourcing the engine so that people can hack on it, but leaving the resources under a proprietary license so you can't just give your friends the whole game. (You can do a similar sort of thing based on trademark law in some cases, but it's probably not useful for web dev.) As you pointed out, selling support, implicitly or explicitly, is another way to do this.
Premium plugins can also work just based on common consideration and psychology. Most people who have paid for a theme don't want to screw over the person who sold it to them, and don't want other people to get it for free.
Modifications of GPL code that are used internally by a person or company do not need to be shared... It could sell access to the stopwatch service running on its own servers without being forced to disclose the derivative source.
Correct.
You can't build an intermediary framework or bridge and have non-GPL licensed code interact with the framework
This is a bit more complicated. The general rule is that as long as there would be a combined work including both GPL and non-GPL-compatible code, it's not allowed. So if you had a proprietary PHP mapping module, you couldn't write a Drupal plugin that calls the module, because GPL and proprietary code would be mixed in memory. But if you instead have your plugin use the Google Maps API, that would be ok even though Google Maps is proprietary. Google's code is running somewhere else and communicating with your code over a common transport (HTTP), so there's no code being mixed.
Sorry for the wall of text!
posted by vasi at 8:49 PM on October 8, 2012 [1 favorite]
Response by poster: The FSF's idea that sharing a process and memory is the definitive idea of whether or not two code bases are joined enough to be a new, single, unique thing seems like dirty pool—an attempt to force a relatively meaningless* and often uncontrollable technical detail to be the deciding factor. It's a function of how scripting languages are constructed, and language construction should not be the deciding factor.
PHP does allow for processes to fork via PCNTL. The child process inherits data (objects and variables) from the parent process. If a child process is forked, inheriting wordpress data and objects, and that is where the plugin lives, is that (from the FSF standpoint) suddenly not a derivitive work, or is it tainted by the data it's inherited?
*for this discussion, it seems to me, etc...
posted by jsturgill at 8:35 AM on October 9, 2012
PHP does allow for processes to fork via PCNTL. The child process inherits data (objects and variables) from the parent process. If a child process is forked, inheriting wordpress data and objects, and that is where the plugin lives, is that (from the FSF standpoint) suddenly not a derivitive work, or is it tainted by the data it's inherited?
*for this discussion, it seems to me, etc...
posted by jsturgill at 8:35 AM on October 9, 2012
I believe that would still require compatible licensing. (I also suspect that mod_php wouldn't be confused by this.) Again, using standard transports instead would be fine. So you could take the HTML or XML output of WordPress, and have a proprietary program that manipulates that however you want.
(I don't really want to have an argument about what "derivative works" should mean, but a small historical correction: The idea that sharing an address space causes something to be a "derivative work" actually originates in compiled languages and dynamic linking.)
posted by vasi at 7:17 PM on October 9, 2012
(I don't really want to have an argument about what "derivative works" should mean, but a small historical correction: The idea that sharing an address space causes something to be a "derivative work" actually originates in compiled languages and dynamic linking.)
posted by vasi at 7:17 PM on October 9, 2012
This thread is closed to new comments.
Internal modifications of GPL code don't need to be distributed, no. There are GPL variants such as the Affero GPL or the OSL that count running publicly as distribution - for example, if you modify Magento and run it on a public webserver, you need to distribute your changes.
Whether or not plugins are derivative works is really grey - wordpress says yes, magento says no.
posted by xiw at 6:49 PM on October 8, 2012