WP Text Ads – GNU license violation

Hello everyone,

I’m Alex, the developer of WP Text Ads.

About this issue of GPL, I hesitated because of posts like those below, and other discussions.

https://blog.taragana.com/index.php/archive/a-gpl-license-question/
https://www.oastler.ca/my-002/wordpress/20080116_open-questions-on-premium-plugin-business-models/

Whether plugins need to be GPL’ed or not, I’m not sure.

But what I’ve done in WP Text Ads is this. I’ve put all code that calls WordPress functions into a file. If I make that file LGPL, would WP Text Ads still violate GPL, assuming it is?

blogcms, thanks for reading through the FAQ. It’s nice to know my effort wasn’t a waste. ??

My issue with your WP plugin is not that you’re selling it. My problem is the proprietary license (not allowing free redistribution of the source code after sale). I believe that most of us would like to do what you’re doing (from a financial standpoint). How great it would be to be able to release proprietary WP interfaced code ?? ??

I believe that GNU is specific that plugin code is considered to be included in the main product license, if the plugin relies on direct function call interaction with the main product. I believe that the program would be considered independent if it was executed via system() call, passing command line parameters, or some other similar ‘disconnected’ communication. Possibly others here could clarify.

I think that your marketplace is an example of how many open source developers profit from open source development. For example, a developer will release a product such as yours, adhering to GNU license terms, and when the product has a wide user base, they will charge for value added services such as your marketplace. Or, charge for technical support, etc.

The reason this sort of thing is not clear is because the law is not particularly clear on the topic either. It all hinges on whether or not some program is a “derivative work” or not.

My general feeling is that plugins should usually not be considered to be derivative works. However, my common sense and my interpretation of the licenses and the relevant case law tells me that they almost always are.

There are individual cases, of course. A plugin like, say, Bad Behavior is clearly not a derivative work. Why? Because all the main code is separate and it comes with interface modules for WordPress and MovableType as well as other blog packages and even a generic way to use it. The code is clearly a separate work, with interfaces to other works. It can be used as a separate work, without any reference to the original works that it has interfaces to. Now, those interfaces may be derivative works of their main works, but who’s to say?

The short of it is that it really doesn’t matter until somebody sues you for it. If the WordPress copyright owner(s) are willing to allow proprietary plugins to exist, then it really doesn’t make any difference what the license says. Why? Because they’re the only possible people with the ability to make an issue out of it in a court of law, which is the only place it really matters.

Note that plugins listed on www.ads-software.com must be using a GPL-compatible license, period.

Themes are harder. Themes are *much* more tightly integrated to WordPress. There is much less of a case to argue that a theme could be a non-derivative work, and most likely all themes must be GPL or they are in violation of the license.

alexchoowk: My understanding is that putting the function calls to WordPress in an LGPL file is OK but with a big caveat: I don’t think you can then distribute non GPL code with GPL code.

I found a big discussion on Joomla forums and Drupal mailing list which cover the same things. It seems the debate centres on whether plugins constitute “part of the program” – a question complicated by the fact that the language used by the GPL is more appropriate for compiled languages.

Plugins in WordPress become tightly integrated in the program, but only because WordPress has hooks to make it simple. Perhaps the fact that WordPress works with/without the plugins is enough to determine they are different programs (this is not fact, just thought).

Anyway. Good luck with that minefield ??

I don’t think the GPL license is being broken. BlogCMS, I believe your logic is flawed and I do not interpret the GPL license in that way. WordPress plugins sold in and of themselves are not part of the larger WordPress system. Linux is GPL-licensed. Does that mean no company can write commercialized or proprietary-licensed software for it? Of course not–even if it uses open source API calls. In effect, that’s all that a WordPress plugin is doing.

Also, I don’t understand what you mean by a “proprietary” license. What would be the point of selling your work if the buyer could merely turn around and resell it himself? Do you mean that the work shouldn’t be sellable without the source code, thus making it modifiable for the original buyer?

In effect, that’s all that a WordPress plugin is doing.

Actually, that is debatable. A WordPress plugin has a great level of access to the internal functions and workings of WordPress itself.

Linux is GPL-licensed. Does that mean no company can write commercialized or proprietary-licensed software for it? Of course not–even if it uses open source API calls.

This is not like writing software that runs on top of Linux (in user-space). This is like writing a kernel module for the Linux kernel, which changes how the kernel works.

And as the Linux Kernel is GPL-licensed, yes, that would indeed mean that no company or individual could write kernel modules that did not fall under the GPL.

In that particular case, Linus has seen fit to allow it, but by a particularly strict reading of the GPL, binary-only modules would not be allowed. To that extent, Linux has implemented a parameter where plugins can identify their license to the kernel and certain functionality is only available to GPL-compatible licensed kernel modules. Google for “GPLONLY” for more information.

Thanks for that analysis, Otto. I found this comment posted on another blog and I’m curious for your thoughts. I don’t mean to reply to your post in cheap-shot fashion by saying “quick, look over there!”; it’s just that this particular law office makes the point better than I can:

Technology Law offices of Rosenlaw & Einschlag has this to say on derivative works:

Here’s how I would decide in the edge cases that I described above:

· The primary indication of whether a new program is a derivative work is whether the source code of the original program was used, modified, translated or otherwise changed in any way to create the new program. If not, then I would argue that there is not a derivative work.

· The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.

· Derivative works are not going to encompass plug-ins and device drivers that are designed to be linked from other off-the-shelf, unmodified, programs. If Linux is designed to accept separately-designed plug-in programs, you don’t create a derivative work by merely running such a program under Linux, even if you have to look at the Linux source code to learn how to do so.

· In most cases we shouldn’t care how the linkage between separate programs was technically done, unless that fact helps to determine whether the creators of the programs designed them with some apparent common understanding of what a derivative work would look like. We should consider subtle market-based factors as indicators of intent, such as whether the resulting program is being sold as an “improved” or “enhanced” version of the original, or whether the original was designed and advertised to be improvable “like a library.”

So, if a plugin developer is in no way modifying the original (i.e. WordPress) code, wouldn’t the plugin not be a “derivative” work by that interpretation?

freerobby: Yes, I’ve read that article from rosenlaw before. There’s only one important point to make about it. Read it more closely, this bit is important:

Here’s how I would decide…

They’re saying that that is how things should be. And I’m not inclined to disagree with them on that point. It would make things clearer if that is in fact the way things were.

However, things are not that way. There is actual case law that disagrees with the positions they are making. So that article, as a whole, is somewhat useless from a practical standpoint. If there was a push to drive that sort of thing into law, then I’d be for it.

But in the meantime, we have to work in the real world with the way things really are.

Additional: rosenlaw also makes this point in their article:

The real reason you should care about this issue is that we want to encourage as much free and open source software to be created without scaring proprietary software users away.

This shows a lack of understanding of a lot of the free software movement in general. Quite a few free software advocates would be quite happy to drive away proprietary software users away. There are a number of library authors who take the hardline stance that if you use their library, then you are indeed creating a derivative work and must abide by the license. This is why the LGPL was created, because the GPL is the hardline position.

There are those that believe that selling of software should be eliminated, and the GPL is indeed one of the tools they use to enforce that position. The GPLv2 is a hardline license, it has little wiggle room in it. Libraries using the GPLv2 have successfully forced non-open projects to use other libraries and/or to open up their own code. Both outcomes are considered success by many free-software advocates.

Otto42,

Thanks again for the analysis. I read that Rosen piece some time ago and was persuaded by it–more than I should have been, apparently.

There is one point that I’m not sure that you’ve countered though, and that is: what of plugins that contain nothing but new code that are not distributed with GPL code? In other words, if a plugin contains not a trace of WordPress code, and is distributed completely independently, on what basis would it be forced under the GPL license? Merely because it is intended to be used with the WordPress system, which is under GPL license?

Is there really case law that would back up such a supposition?

–Robby

There is one point that I’m not sure that you’ve countered though, and that is: what of plugins that contain nothing but new code that are not distributed with GPL code? In other words, if a plugin contains not a trace of WordPress code, and is distributed completely independently, on what basis would it be forced under the GPL license?

It’s certainly possible to write such a thing, and I have seen several of them. Mostly back in previous WordPress versions. These are plugins which contain their own functions, don’t call any WordPress functions, and are only WordPress plugins by the virtue of the standard WordPress comment template at the top of the function. You only can use them by adding their function calls into your theme somewhere. That sort of thing.

And you’re correct, there’s no real way that anybody could argue that these must abide by the restrictions of the GPL. However, plugins that are actually this separate from WordPress are few and far between, and getting fewer and further.

Merely because it is intended to be used with the WordPress system, which is under GPL license?

No, intent doesn’t matter. Only the code in question does. If it uses GPL code or makes calls to GPL functions, then by a strict reading of the license, yes, it must abide by the GPL as well. This was the whole purpose of the LGPL, to allow for open source libraries without applying those terms to mere users of the libraries.

And, like I said above, plugins that keep their own code separate and merely include compatible interfaces to WordPress (see Bad Behavior for the best example of this method that I am aware of) could probably not be reasonably argued to be derivative work. Probably. Nothing is certain when it comes to the law. ??

Thanks again, Otto. Check your email when you get a chance–I can’t really continue this conversation here because it involves mention of a commercial plugin.

And, like I said above, plugins that keep their own code separate and merely include compatible interfaces to WordPress (see Bad Behavior for the best example of this method that I am aware of) could probably not be reasonably argued to be derivative work. Probably. Nothing is certain when it comes to the law. ??

I would argue that the Bad Behavior program should be able claim non-GPL license if desired, not because it keeps its interface code separate (in separate file), since the mere fact that it contains interface code would be the issue that would seem to pull it into the GPL license. The reason that Bad Behavior could be considered standalone is that it is generically written, and currently interfaces with many programs, AND it has a ‘generic’ interface that can be used with ANY program. It’s obvious that Bad Behavior was not written to be a WP specific program. WP Text Ads is so specifically written for (and tightly integrated into) WordPress that it is impossible to argue that it can exist outside of GPL, even if the author separates the WP functions into a separate file (an obvious contrived way of attempting to circumvent GPL).
Another point that I would make is that nobody should be allowed to do what WP Text ads has done, because it hurts the open source effort, and it also sets a bad precedent. Matt and Automattic must know of this program’s existence, and though the author is outside of the US (I believe), there at least ought to be a strong statement against the program and the author’s intent, so that the community (open source and WordPress) understands where the Automattic team stands on this type of issue.

I would argue that the Bad Behavior program should be able claim non-GPL license if desired, not because it keeps its interface code separate (in separate file), since the mere fact that it contains interface code would be the issue that would seem to pull it into the GPL license.

You could argue that the interface code itself must be under the GPL or a compatible license, while the separate code would not be. Just because they are distributed together doesn’t put them all under one license.

The reason that Bad Behavior could be considered standalone is that it is generically written, and currently interfaces with many programs, AND it has a ‘generic’ interface that can be used with ANY program. It’s obvious that Bad Behavior was not written to be a WP specific program.

Totally true, but from the standpoint of licensing and law that is probably irrelevant. The separation of the main code from the interface code prevents it from having to be GPL-Compatible.

I have no opinion on WP Text Ads. Have not looked at it.

You could argue that the interface code itself must be under the GPL or a compatible license, while the separate code would not be. Just because they are distributed together doesn’t put them all under one license.

You could argue it.

Totally true, but from the standpoint of licensing and law that is probably irrelevant. The separation of the main code from the interface code prevents it from having to be GPL-Compatible.

Nobody would wish your loose interpretation of the GPL to be true more than I would. Depends upon what you mean by “separation”. Simply moving interface code to a separate file does not exclude the non-interface code from GPL. Not sure if that’s what you’re suggesting (is it?), but that would seem to make it very easy to circumvent GPL licensing, and the intent of the licensing.

Simply moving interface code to a separate file does not exclude the non-interface code from GPL.

Well, actually, that depends on how you look at it. I’m not saying that a separate file is necessarily required, but yes, adding some form of separation between can indeed make the code a separate work. The important question is whether the separate code is a usable piece of work on it’s own, without the interface portion.

Take Bad Behavior again (it’s just such a good example here). It has a generic interface to that separate piece of work. The package includes several plugin interfaces to hook that code to several different platforms. The Bad Behavior code itself is clearly separate and can be used separately from the GPL’d WordPress interface entirely, because it can be used with other platforms via these different interfaces.

that would seem to make it very easy to circumvent GPL licensing, and the intent of the licensing.

That depends on what you define the “intent” of the licensing as, and on that topic you start getting into matters of philosophy rather than law.

More to the point, it doesn’t mean that anything is “circumvented”. If I write a piece of code entirely on my own, then it can be under any license I wish. I own that copyright, it’s mine to do with as I please. If I then write a plugin to interface my code to WordPress in some fashion, does that mean that my code is retroactively forced to be GPL’d? What if somebody else writes the interface instead?

The sane answer in both cases is no, I can choose whatever license I want for the code that I wrote from nothingness.

Yes, I am aware that the Free Software Foundation has a different opinion on this topic (I have had email conversations with some of them on this exact topic, in a different circumstance), but their opinion has no legal basis in either the wording of the license or in actual case law.