Commercial plugins and GPL

[Simon]

I realise that questions around this area have been done to death, but I'm seeking to try and get some consensus, if possible.

Whilst I created and own commercial software (i.e. proprietary code) that can be used as a WordPress plugin (OIOpublisher.com), I've never really been very aware of how much tension there appears to be over the existence of commercial code used in WordPress plugins / themes. It seems a little strange to me, but I understand the rationale behind both sides of the argument.

I've seen some claim they can't talk about commercial plugin X or theme Y, because of the perceived retribution they'll risk if they do. I'm therefore trying to ascertain what methods the WordPress community currently accept with regards to creating commercial plugins (and themes).

Here's what I've seen mentioned previously:

1.) License the entire plugin as GPL (may as well include the obvious one!).
2.) Use a SaaS approach and create a GPL'd plugin to interface with a web service API.
3.) Create a GPL'd bridge that removes direct interaction between the WordPress core and the commercial code.
4.) License "assets" such as images and css commercially, with php code being GPL'd (this one is obviously aimed at themes).

As some of you may know (I did spot the OIO specific thread!), I opted for option #3. The primary reason for this was so that I could easily integrate with multiple platforms, if I ever wanted to, but it also comes with the benefit of being able to dual-license. I've even seen this approach questioned, however, since "sharing the same memory space" could be seen as a derivative work (personally, I doubt that would hold up from a legal standpoint).

So, what are your opinions on the methods listed above (I would expect #1 and #2 to be uncontested), and what other options are there (if any)?

P.S. I am asking similar questions in the Drupal community, as I know the issue isn't WordPress specific.

[andreasnrb]

If you want to make a plugin and have it accepted in the WordPress world and talked about on for example WPCandy you must be 100% GPL all the way. No bridges or anything. Because WPCandy is just a hold out for GPL fanatics so getting any news on there for non-GPL WordPress stuff is never gonna happen.

Option nbr 5 is making the whole plugin proprietary and non-GPL. Thats what I've done. but I use a bridge licensed under MIT license as well. Not welcomed into the WP fold =).

[ryanimel]

@andreasnrb: We cover split licensed and fully GPL plugins and themes. I don't think I'm a fanatic; that editorial position is something I've thought a good deal about, and even go back and forth on sometimes. I'm just interested in making WPCandy the best site I can for its readers, and right now that position is part of that. Feel free to ping me by email or Skype or something Andreas, I'd by happy to talk about it with you more.

@Simon: I'm honestly not as familiar with OIO as I probably should be, but those options sound just fine. Personally, I tend to like whatever makes using the plugin/theme the easiest for me to use.

[Simon]

Personally, I tend to like whatever makes using the plugin/theme the easiest for me to use.

A very good point. I had someone on the Drupal side come back to me and claim that I should make my script accessible through a web services API, to truly separate it from WordPress. Whilst I see a logic behind it, I don't believe I should have to make something that will inevitably degrade what the user gets, in order to get round a (perceived) licensing issue.

FWIW, I don't think websites making a stance on what to talk about is necessarily a big issue. In an ideal world, everything would be judged purely on merit, but (as an example) I like the fact that WordPress.org is more or less a commercial free zone.

The only thing I would object to is if anyone is put down for making (compatible) commercial software, or for choosing to talk about it. I don't know to what extent such an attitude may exist within the WordPress community (I can only go off 3rd party accounts I've read, each of which is unlikely to paint the full picture), but I would hope it's not prevelant.

Anyway, if the options listed above are indeed accepted by the community at large, then I'm happy. Writing modular, self contained code is good practice (IMO), so it's something I think authors of most commercial software should naturally do anyway. Not to mention the fact that monetising 100% GPL'd code is a very valid option in a lot of cases.

------

EDIT: at the risk of going somewhat off on a tangent and "ranting", I did want to express one other thing about the GPL. The "four freedoms" the license gives users is a very noble end goal (and not just for software). In a lot of cases, giving a product away for free is more beneficial to the owner than charging for it (I know the GPL doesn't prohibit charging, but the fact you can buy it and then give it away for free isn't exactly ideal either). The only thing that needs to be remembered, in my view, is that the freedoms shouldn't be considered an automatic right for all software, but an aspiration.

[andreasnrb]

ryanimel:
You guys are fanatic. When its just ideology that decides decisions and not quality etc then its fanaticism. You started a thread for how to convince companies to go GPL when there is no real reason for it. Just ideology and if they want to be accepted in the WP sphere. Not even most users care. Same goes for the post you made about DotNetNuke community manager post.
Did you read my reply on how GPL is dwindling in usage compared to other licenses and critique of your and Ottos arguments?

You cover split license yes. But only themes that go GPL for PHP and other license for the rest. In this case its a plugin. Everything that makes plugins special in almost all cases are the PHP code. Therefor you won't ever find split licensed plugins.

Simon:

Anyway, if the options listed above are indeed accepted by the community at large, then I'm happy. Writing modular, self contained code is good practice (IMO), so it's something I think authors of most commercial software should naturally do anyway.

Thing is bridge code is not that well received either. GPL is considered infectious in nature. If you link dynamically to a GPL library etc it is considered as a work as a whole by the vocal WP community (and Drupal for that matter). Even if its the user that creates the work so to speak. You don't distribute a complete work. So even if you make a bridge you can still get heat for it. Would be interesting to see if thats acceptable in the community I doubt it. WP Candy hasn't covered OIO Publisher at all for example. Not one word.

I for example got an MIT license on my bridge. Its not even a bridge but I use WordPress as a viewengine and "framework". I extend interface to connect the "bridge" to WordPress. It works standalone as well. Funny thing is that WP folks mostly license their free stuff as GPL as well. The stuff I give away I license as MIT. I want people to be able to do whatever they want with my free stuff.

[Simon]

Thing is bridge code is not that well received either. GPL is considered infectious in nature. If you link dynamically to a GPL library etc it is considered as a work as a whole by the vocal WP community (and Drupal for that matter).

I had seen that in the Drupal licensing FAQ (and also the fact that WordPress.org links to it), which certainly made me wonder. I'd certainly argue that the dynamic linking / sharing the same memory address etc doesn't have any bearing on whether something is a derivative work or not.

I suppose it comes down to how much the community takes it to be a "hard and fast" rule, as opposed to guidelines that don't apply to every case. I've certainly seen people on both sides of the fence - some take it very literally, others take context more into account (but I don't really follow the "vocal" WP community much).

[leewillis77]

Just thought I'd chime in here with some thoughts and opinions. I've read your post a couple of times, and I think my first comment would be that you need to be clear what you mean by "Commercial" as there are a couple of different interpretations.

For me, "commercial" is an issue purely of cost, ie is the plugin provided free of charge for anyone, or is it sold for a fee by the author/designer/developer. To me, that doesn't conflict with the GPL at all. I know of plenty of places that sell GPL code/themes/addons and it's a model that can work pretty well. Usually it works because there are added services / advantages for buying it rather than getting free off someone else (Support / access to online support materials / auto-upgrades etc. etc.).

However, I *think* you're talking about distributing code under a non-GPL license. I don't see this as being "commercial" or "no commercial", it's about restrictive vs. open licensing. The "tension" you refer to comes about because some people have chosen to use WordPress because of its open licensing. To have someone "breach" those license terms by linking it to non-open-licensed software is just a serious legal breach as someone taking restrictively licensed software and distributing it for free. I'm sure if someone did that with your privately licensed software you'd be tense as well ;)

For me, GPL is important. I've bought "commercial" [in my definition of the word] plugins before, and even when they've been bought from big, well known organisations, the code is often less than perfect. Knowing that the source is open and accessible means that I can usually resolve these - and contribute the fixes back to the community where that's relevant.

[As an aside, I've installed multi-million £GBP non-open software and it's generally no better in the bug-to-functionality ratio than OSS].

So, as a summary of your "options":

1.) License the entire plugin as GPL (may as well include the obvious one!).

I would go for this. Knowing that a plugin is GPL would encourage me to use the plugin as I know I can fix it or extend it as my needs require. This is especially true if it was paid-for. I'm unlikely to use a paid-for, closed-license option unless there really is no alternative. This works best where it is combined with access to one or more services as I mentioned earlier.

2.) Use a SaaS approach and create a GPL'd plugin to interface with a web service API.

Depending on the implementation of this I think it's debatable about whether this avoids the license issues at all [Although IANAL the answer here may help - http://www.gnu.org/licenses/gpl-faq....ereAggregation]. I recognise that it could be a good option for *some* services, but for most I think it just makes the software more uncomfortable and inconvenient for users to use.

3.) Create a GPL'd bridge that removes direct interaction between the WordPress core and the commercial code.

I don't think this avoids the licensing issues at all - see the link above.

4.) License "assets" such as images and css commercially, with php code being GPL'd (this one is obviously aimed at themes).

This doesn't make sense to me. Either you're licensing your work openly because you recognise the benefit that gives you and your users, and the lack of control is acceptable, or you're not.

The images/css vs code solution is a technical one, but not one that makes sense for the end-user (What?? - I can fix bugs in the code, but not the CSS/images???), or for the developer since it arguably indicates that the images/css are somehow more "valuable" than the code.

[Disclaimer to all of the above: I have GPL plugins provided free-of-charge through WordPress.org, I also have (GPL) plugins that I sell commercially. I'm also not a lawyer, so comments are purely my personal interpretation!]

[Simon]

Some good stuff here. Thanks for chiming in! I'll try to respond as best I can with my point of view on what you've said.

I think my first comment would be that you need to be clear what you mean by "Commercial" as there are a couple of different interpretations.

Good point - I've ammended the first post to specify non-GPL licensed software. I also agree that selling GPL'd software is a good route in a lot of cases (value added services etc).

To have someone "breach" those license terms by linking it to non-open-licensed software is just a serious legal breach as someone taking restrictively licensed software and distributing it for free.

This is where we'll have to disagree. It's true that it *may* be a breach to link non-GPL'd software to GPL (we don't know, without any legal precedent), but the case of what constitutes a derivative work is far from clear.

Knowing that the source is open and accessible means that I can usually resolve these - and contribute the fixes back to the community where that's relevant.

I suppose it depends on your definition of the source being "open", but the only restriction my license has that the GPL doesn't concerns distribution. The source code can be read / modified / extended by anyone who purchases, fixes and enhancements can be fed back into development (via a publicly accessible forum). The only thing you can't do is give the original to someone else (they have to purchase).

(As an aside, it's possible that I could distribute under GPL and suffer no ill-effects, but that's not an argument for or against the point in question.)

The images/css vs code solution is a technical one, but not one that makes sense for the end-user (What?? - I can fix bugs in the code, but not the CSS/images???), or for the developer since it arguably indicates that the images/css are somehow more "valuable" than the code.

Interesting one, because you've assumed you can't fix bugs with css/images, if they aren't licensed in the same way as GPL? I don't see why that's the case at all; it depends on the license, distributor etc.

http://www.gnu.org/licenses/gpl-faq....ereAggregation

Indeed, the million dollar question(s) - can dynamic linking constitute a derivative work? If so, under what circumstances? I believe it's the 2nd question that is the more relevant one, in fact. If the issue is as black and white as saying "if your code is dynamically linked, then GPL applies" (which is what that FAQ states), then there are some good opinions out there (written by legal minds) that would show this is the wrong way to approach it.

I don't think we can treat the FAQs as much more than an opinion, from a legal standpoint. Let's not forget Linux and the GPL.

[andreasnrb]

leewillis77
You have a very distorted view on licenses. Nothing you writes that refers to modification etc is inherently just about GPL. I use a license that gives users the right to modify, get consults to modify the code etc. I just ask them to ask for permission before redistributing any of my own code to a 3rd party for their usage.

Simon:
Leewillis is a typical representative of the vocal WP community. Steadfast no grey areas attitude and a tendency to consider the GPL FAQ as law and not biased. Of course the GPL FAQ tries to give the impression that GPL applies to everything. Another thing that comes up is the "spirit" whatever supernatural phenomenon that is. Which is even more biased in nature than the GPL FAQ since it means whatever the user of the term want it to mean.

[ryanimel]

andreasnrb:
I like this conversation, and want to have it, but I don't want to hijack Simon's thread. I started up a thread in the WPCandy forum.