This question[1] got me thinking. It seems that excanvas[2] is becoming a standard dependency for Javascript charting libraries but it is licensed with Apache 2.0, not GPL 2.
The core question I'm asking is would a plugin that is otherwise GPL licensed be denied inclusion into the WordPress plugin repository if it includes excanvas because of the Apache 2.0 license? Or given the circumstances would the potential license conflicts be overlooked?
> This question[1] got me thinking. It seems that excanvas[2] is becoming a > standard dependency for Javascript charting libraries but it is licensed > with Apache 2.0, not GPL 2.
> The core question I'm asking is would a plugin that is otherwise GPL > licensed be denied inclusion into the WordPress plugin repository if it > includes excanvas because of the Apache 2.0 license? Or given the > circumstances would the potential license conflicts be overlooked?
> On Sat, Mar 19, 2011 at 1:47 PM, Mike Schinkel > <mikeschin...@newclarity.net>wrote:
>> This question[1] got me thinking. It seems that excanvas[2] is becoming a >> standard dependency for Javascript charting libraries but it is licensed >> with Apache 2.0, not GPL 2.
>> The core question I'm asking is would a plugin that is otherwise GPL >> licensed be denied inclusion into the WordPress plugin repository if it >> includes excanvas because of the Apache 2.0 license? Or given the >> circumstances would the potential license conflicts be overlooked?
Well I think it's safe to say Mark Jaquith wasn't thinking since GPL v3 is later than GPL v2 and his response says it has to be GPL - more specificallt GPL v2 or later. Also the plugin about [1] states it has to be compatable with GPL which according to gnu [2] Apache V 2.0 is.
> On Sat, Mar 19, 2011 at 1:47 PM, Mike Schinkel > <mikeschin...@newclarity.net>wrote:
>> This question[1] got me thinking. It seems that excanvas[2] is becoming a >> standard dependency for Javascript charting libraries but it is licensed >> with Apache 2.0, not GPL 2.
>> The core question I'm asking is would a plugin that is otherwise GPL >> licensed be denied inclusion into the WordPress plugin repository if it >> includes excanvas because of the Apache 2.0 license? Or given the >> circumstances would the potential license conflicts be overlooked?
Thanks. So in a nutshell am I reading that you think it should be okay to include Apache v2.0 licensed dependency into a GPLv2 licensed plugin and that it should be allowed in the repository?
Can anyone official confirm this?
-Mike
On Mar 19, 2011, at 5:18 PM, Iain Cambridge wrote:
> Well I think it's safe to say Mark Jaquith wasn't thinking since GPL > v3 is later than GPL v2 and his response says it has to be GPL - more > specificallt GPL v2 or later. Also the plugin about [1] states it has > to be compatable with GPL which according to gnu [2] Apache V 2.0 is.
>> On Sat, Mar 19, 2011 at 1:47 PM, Mike Schinkel >> <mikeschin...@newclarity.net>wrote:
>>> This question[1] got me thinking. It seems that excanvas[2] is becoming a >>> standard dependency for Javascript charting libraries but it is licensed >>> with Apache 2.0, not GPL 2.
>>> The core question I'm asking is would a plugin that is otherwise GPL >>> licensed be denied inclusion into the WordPress plugin repository if it >>> includes excanvas because of the Apache 2.0 license? Or given the >>> circumstances would the potential license conflicts be overlooked?
> Thanks. So in a nutshell am I reading that you think it should be okay to > include Apache v2.0 licensed dependency into a GPLv2 licensed plugin and > that it should be allowed in the repository?
> Can anyone official confirm this?
> -Mike
> On Mar 19, 2011, at 5:18 PM, Iain Cambridge wrote:
> > Well I think it's safe to say Mark Jaquith wasn't thinking since GPL > > v3 is later than GPL v2 and his response says it has to be GPL - more > > specificallt GPL v2 or later. Also the plugin about [1] states it has > > to be compatable with GPL which according to gnu [2] Apache V 2.0 is.
> > On 19 March 2011 18:51, Chip Bennett <c...@chipbennett.net> wrote: > >> I'm guessing that it would not be allowed.
> >> After all, even with the official WordPress License "clarification", the > >> official policy is that even GPLv3 Plugins will not be allowed to be > hosted > >> in the Plugin Repository:
> >> On Sat, Mar 19, 2011 at 1:47 PM, Mike Schinkel > >> <mikeschin...@newclarity.net>wrote:
> >>> This question[1] got me thinking. It seems that excanvas[2] is becoming > a > >>> standard dependency for Javascript charting libraries but it is > licensed > >>> with Apache 2.0, not GPL 2.
> >>> The core question I'm asking is would a plugin that is otherwise GPL > >>> licensed be denied inclusion into the WordPress plugin repository if it > >>> includes excanvas because of the Apache 2.0 license? Or given the > >>> circumstances would the potential license conflicts be overlooked?
<mikeschin...@newclarity.net> wrote: > This question[1] got me thinking. It seems that excanvas[2] is becoming a standard dependency for Javascript charting libraries but it is licensed with Apache 2.0, not GPL 2.
> The core question I'm asking is would a plugin that is otherwise GPL licensed be denied inclusion into the WordPress plugin repository if it includes excanvas because of the Apache 2.0 license? Or given the circumstances would the potential license conflicts be overlooked?
Official answer: As Pete pointed out, The Apache 2.0 license is not compatible with the GPL version 2. So that does not meet the current licensing criterion, which is that the license be compatible with the GPL version 2.
I'm still deliberating about whether to relax that criterion to allow GPLv3-only or GPLv3+ (or compatible) code. We're already in the situation where some plugin directory code is GPLv2-only instead of GPLv2+, so combining that plugin code with WordPress already requires care.
If you're writing a plugin, and are able to, I strongly urge to to license it as "GPLv2 or any later version" (GPLv2+) or just as "GPL, any version," as that allows for maximum flexibility.
> On Sat, Mar 19, 2011 at 2:34 PM, Mike Schinkel > <mikeschin...@newclarity.net>wrote:
>> Hi Iain,
>> Thanks. So in a nutshell am I reading that you think it should be okay to >> include Apache v2.0 licensed dependency into a GPLv2 licensed plugin and >> that it should be allowed in the repository?
>> Can anyone official confirm this?
>> -Mike
>> On Mar 19, 2011, at 5:18 PM, Iain Cambridge wrote:
>>> Well I think it's safe to say Mark Jaquith wasn't thinking since GPL >>> v3 is later than GPL v2 and his response says it has to be GPL - more >>> specificallt GPL v2 or later. Also the plugin about [1] states it has >>> to be compatable with GPL which according to gnu [2] Apache V 2.0 is.
>>> On 19 March 2011 18:51, Chip Bennett <c...@chipbennett.net> wrote: >>>> I'm guessing that it would not be allowed.
>>>> After all, even with the official WordPress License "clarification", the >>>> official policy is that even GPLv3 Plugins will not be allowed to be >> hosted >>>> in the Plugin Repository:
>>>> On Sat, Mar 19, 2011 at 1:47 PM, Mike Schinkel >>>> <mikeschin...@newclarity.net>wrote:
>>>>> This question[1] got me thinking. It seems that excanvas[2] is becoming >> a >>>>> standard dependency for Javascript charting libraries but it is >> licensed >>>>> with Apache 2.0, not GPL 2.
>>>>> The core question I'm asking is would a plugin that is otherwise GPL >>>>> licensed be denied inclusion into the WordPress plugin repository if it >>>>> includes excanvas because of the Apache 2.0 license? Or given the >>>>> circumstances would the potential license conflicts be overlooked?
So we are writing a plugin from scratch for a well-loved SaaS vendor and need to incorporate charts at their request. We looked at flot which includes Apache 2.0 excanvas. Explicitly, since you talk of relaxing, would including flot in a plugin keep that plugin out of the WordPress plugin repository?
-Mike
On Mar 19, 2011, at 7:18 PM, Mark Jaquith <markjaqu...@gmail.com> wrote:
> On Sat, Mar 19, 2011 at 2:47 PM, Mike Schinkel > <mikeschin...@newclarity.net> wrote: >> This question[1] got me thinking. It seems that excanvas[2] is becoming a standard dependency for Javascript charting libraries but it is licensed with Apache 2.0, not GPL 2.
>> The core question I'm asking is would a plugin that is otherwise GPL licensed be denied inclusion into the WordPress plugin repository if it includes excanvas because of the Apache 2.0 license? Or given the circumstances would the potential license conflicts be overlooked?
> Official answer: As Pete pointed out, The Apache 2.0 license is not > compatible with the GPL version 2. So that does not meet the current > licensing criterion, which is that the license be compatible with the > GPL version 2.
> I'm still deliberating about whether to relax that criterion to allow > GPLv3-only or GPLv3+ (or compatible) code. We're already in the > situation where some plugin directory code is GPLv2-only instead of > GPLv2+, so combining that plugin code with WordPress already requires > care.
> If you're writing a plugin, and are able to, I strongly urge to to > license it as "GPLv2 or any later version" (GPLv2+) or just as "GPL, > any version," as that allows for maximum flexibility.
On Sun, Mar 20, 2011 at 1:17 AM, Mark Jaquith <markjaqu...@gmail.com> wrote: > I'm still deliberating about whether to relax that criterion to allow > GPLv3-only or GPLv3+ (or compatible) code. We're already in the > situation where some plugin directory code is GPLv2-only instead of > GPLv2+, so combining that plugin code with WordPress already requires > care.
Total number of plugins in the repo: >13.000
Number of plugins that got included in Core, ever: <10
<mikeschin...@newclarity.net> wrote: > Explicitly, since you talk of relaxing, would including flot in a plugin keep that plugin out of the WordPress plugin repository?
Right now, it would, yes.
On Sat, Mar 19, 2011 at 8:00 PM, scribu <m...@scribu.net> wrote: > Total number of plugins in the repo: >13.000
> Number of plugins that got included in Core, ever: <10
> Need I say more?
Sure. But I was thinking more about forks and core/plugin bundles that third parties might want to distribute. But it's a very small concern.
On Sun, Mar 20, 2011 at 2:16 AM, Mark Jaquith <markjaqu...@gmail.com> wrote: > Sure. But I was thinking more about forks and core/plugin bundles that > third parties might want to distribute. But it's a very small concern.
Denying inclusion of plugins just so that other third-parties can make bundles without doing their homework seems even less of a legitimate reason than the "would prevent inclusion in core" one.
On Sat, Mar 19, 2011 at 8:39 PM, scribu <m...@scribu.net> wrote: > Denying inclusion of plugins just so that other third-parties can make > bundles without doing their homework seems even less of a legitimate reason > than the "would prevent inclusion in core" one.
It would make certain bundles *impossible*, no matter how much homework you did. GPLv2-only and GPLv3+ can't be combined. But I'm not sure that outweighs the benefit that would be realized by allowing GPLv3 and GPLv3-compatible code.
I infer from his comment that he was referring to such downstream distributors doing their homework regarding what they could and could not bundle with a WordPress derivative. (In other words, I think he's 100% in agreement with you on this point.)
Regardless, I don't at all understand why it would be the responsibility of WordPress.org to act as a clearinghouse for Plugins that are or are not eligible to be bundled with a distributed WordPress derivative, nor do I understand why WordPress.org would even *want* to assume that responsibility, especially considering that to do so would be to consider that responsibility more important than the opportunity to provide otherwise completely legitimate, useful Plugins to the tens of millions of end users of WordPress, the vast majority of whom will never know about a Plugin unless it is included in the Plugin repository.*
So, I am quite happy to hear that you are reconsidering this policy.
Chip
* I'm also quite certain that's the longest sentence I've ever written.
On Sat, Mar 19, 2011 at 9:17 PM, Mark Jaquith <markjaqu...@gmail.com> wrote: > On Sat, Mar 19, 2011 at 8:39 PM, scribu <m...@scribu.net> wrote: > > Denying inclusion of plugins just so that other third-parties can make > > bundles without doing their homework seems even less of a legitimate > reason > > than the "would prevent inclusion in core" one.
> It would make certain bundles *impossible*, no matter how much > homework you did. GPLv2-only and GPLv3+ can't be combined. But I'm not > sure that outweighs the benefit that would be realized by allowing > GPLv3 and GPLv3-compatible code.
