Are Your Paid WordPress Plugins subject to the GPL and Open Source - Developers Read This!

As I said back on my thread....

GPL means GPL so do not try to
claim ownership to any contributory
theme or script(software) no matter
what your input.

The quote allegedly from the Drupal license is very different from the GPL. The GPL says "based on," while the quote in the OP says "interacts with."

Huge gap there.


Paul

Looks like the graphics design itself would not fall under GPL as long as it was designed from scratch. The code without the theme graphics would be kind of useless really.

Edit: sorry, this thread was pertaining only to the plugins, not themes like the other thread.

James,

The section you quote from the actual GPL is VERY different from the assumption of rights in the Drupal license. Under the quoted Drupal terms, it would not be possible to develop any software that interacted with the main product without also being covered by the GPL. That is clearly not what the GPL itself says, as demonstrated in the quote you just gave from it.

That's rather an off-target reference anyway.


Paul

Jake,

The waters aren't especially muddy if you actually read the original document. You're trying to extend the GPL to cover things it wasn't intended to cover, so that you can violate the terms of use of a product that has features you don't care for.

Going back to the discussion that started this: Themes that are sold "off the shelf" are much less expensive because they're not exclusive. They're sold in quantity, and part of the marketing that makes that possible is the creator's branding link.

This is not rocket science. If you don't like the link and the creator doesn't allow it to be removed, don't use the theme.


Paul

This should only be a concern if you modify the core WP files. If you don't make any modifications to the wordpress core then you are OK and don't have to release the source. Like someone making an application that runs on linux. At least this is what I have been led to believe.

James, Sounds like a programming language, yes? Could be an interesting legal argument, but I'd think it was rather like suggesting that words are the same as content, or supplies the same as structure.


Paul

James,

There are two words there that make it clear that simply using the API doesn't force GPL terms on distribution: "It depends."


Paul

Could it be argued that you are selling your Plugin and ALLOWing Wordpress to interface with your plugin rather than the other way round?

I know functionally the plugin won't work without Wordpress, so it doesn't make much sense for anyone who doesn't have Wordpress to buy it, but it's not a prerequisite for selling that you must provide a copy of Wordpress.

In a similar view, you could sell a gallon of gas, and it wouldn't make sense for someone without a car to buy it, but it's not a prequisite of selling it to provide a car.

You are selling a piece of source code. What the user does with it is something different.

As a programmer let me give my opinion here...

The point of issue is reusing the WP code blocks to enable your plugin to interact with the WP core script. WP does have the right to regulate that however they want as you are using their code base for your own purposes.

However, any decent programmer can write their own code that accomplishes the same thing without using the built in hooks that WP has. It is the long way around and not quite as easy but if you write all the code yourself then you can have 100% control over it.

Look at it like this.. you have two options here.

Option 1 is take the lazy way and use the prebuilt hooks and functions that WP has that allows quick and easy integration of your own code. In this case you are reusing some of the WP core programming which they have under their own license and they control what happens to that section of the code. If you use any WP code, for any reason, then you are bound by their licensing structure.

Option 2 is write your own code that does the same thing but doesn't use the built in hooks. This is harder and not as quick but it allows you more freedom since you are not reusing any WP code from the core program. This means you control the licensing structure and not WP so you can pretty much do whatever you want with it.

If you use any block of existing WP code then expect to be held bound to their licensing structure.

This is why we did not do GPL with out software. When there is no money in it for developers, they tend to move elsewhere.

I suppose you would be right on that point, you could create a "blank" theme and then sell CSS files to style it, although I do not believe you would have much luck doing this.

I was not stating that "DESIGN" is irrelevant to the argument, I was stating that comparing WordPress to a Canvas is irrelevant because they have different licensing terms

I basically agree with you and have said so above, If WordPress wins this battle there will be a mass exodus from it as a development platform for IM.

I'm pretty sure I agreed that CSS would be exempt?

It looks like Thesis has basically agreed that all of the code is GPL'd and are only applying their license to the images they supply.

Which begins to "solidify" WP's standing.

James

James

The entire Wordpress/Thesis war is summed up here. Including the audio interview.

Matt Mullenweg Declares War on Thesis: A Summary | WPblogger

Scroll down to "Copied Code" to see how this relates to this discussion.

Hey everyone,

Hopefully I can do my part to clear this up.

When you release a plugin or theme, any code that interfaces with WordPress is released under GPL, meaning that you can charge a "distribution fee" for it, and those who you distribute it to have free reign to decide if they want to give it away for free, or charge for it, or keep it to themselves. If you're like me, you believe this is good for biz.

Now, I understand that some things you just don't want to release under GPL. Even though people are always going to get their hands on your stuff for free no matter what precautions you take, you want to position yourself so that it's EASIER and MORE CONVENIENT for people to pay you, rather than find a way to get your stuff for free.

The best, easiest, and most deterring way to do this? Have your plugin/theme rely on a license key, and position it so that your code can be released for free all day but it doesn't matter because the plugin/theme won't work without an official key from you. Are there ways around this? Absolutely. You can make it so that the plugin randomly checks for a valid response from your server, but the tech-savvy can modify local DNS settings to spoof a valid response. Someone can even set up a second server that basically grants "free" serials to your software, and modify your plugin before distributing.

This will happen, yes. But at the end of the day, it's no big deal, and if anything, it's positive. Even Adobe and Microsoft have their software distributed for free by hackers, and there's nothing you can do about it. But the truth is that if your stuff is so good that others are willing to go through the hassles of hacking your code and forfeiting timely updates just to get a free copy, you've got a winner. When word gets out that your stuff is so good it's worth hacking, you're bound to generate more sales than you would have without the hacker's support.

Hope this helps. Look forward to reading your feedback.

Sincerely,
Russell

This thread really made me sit up and take notice. I had been planning to go premium in some form with my Wordbay eBay listings plugin. It's been GPL/open source since day one, but I can no longer justify the many hours I pour into developing and supporting it - as someone pointed out, programmers have families to feed too.

Now I am in two minds - call me naive, but it never really sank in that the GPL licence required derivative works (assuming that's what a plugin is - I am still not convinced) to also bear the GPL licence! Sure, I can still sell it, but what's the point when others can then share it? Probably some sort of member site model is better in that case - that was kind of my plan B.

But there are hundreds of premium Wordpress plugins out there! Few of them are GPL, and most have obfuscated or encrypted code (certainly not Open Source). Just take Wishlist Member as only ONE very prominent example. So what are they going to do there, take them all to court? And is that really in the spirit of the open source philosophy?!

On the other hand, some conspiracy theorists see all kinds of ominous portends in Wordpress recently being transferred into the hands of a foundation, we shall see. Sort of leaves me in a quandary right now though...

Wanted to leave this here for everyone, too. But I also wanted to say DON'T GET BUMMED OUT OVER IT! There's really no big deal here, and this is actually GOOD for biz when you play by the rules

wordpress.org/news/2009/07/themes-are-gpl-too/

Interesting Russell, so I basically put my WP hooks, filters etc in my main pluginname.php, open-source, under GPL, and put the main functionality, that doesn't use WP core, in encrypted modules or whatever under my proprietary licence? Most regular users aren't that interested in hacking my plugin or sharing it around anyway, I just want to stay within the GPL.

You make a convincing arguement. I guess until a test case happens then it's just a risk you have to take if you want to sell WP plugins.

Russell, I would be very interested to hear the opinion of a real lawyer on the notion of conflating the words 'dependent' and 'derivative.'

I'm not a lawyer, but I don't buy it. That has no resemblance to the meaning of the word 'derivative' as I've seen it used in the context of copyright law. It is so different, in fact, that the term 'overreaching' seems rather a gross understatement at the moment.


Paul

This thread is like reading arguments about how many angels can dance on the head of a pin. Much of it is sheer nonsense.

The term "API" stands for "Application Programming Interface". It is a SPECIFICATION of an INTERFACE intended to be used by THIRD-PARTY PROGRAMMERS to access functions provided by and through the API. In short, APIs are created specifically to ALLOW third-parties to EXTEND the basic abilities of the core code. Further, APIs do not create derivative works -- they insulate against derivative works.

Fundamentally, there is no reason to define an API if you do NOT want anybody using it. So saying that uses by third-parties constitutes proprietary extensions is ridiculous, even if the "proprietary" part extends an "open-source" code base.

Here's an analogy:

A power plug in your house is an API of sorts. It is a standard interface that follows well-known specifications, and allows you to plug electrical devices into it to power them. The electricity delivered through the plug is delivered to it by the power company. You have a license agreement from the power company to consume power provided through your meter at a well-defined rate. That agreement does not give you the right to re-sell the power to your neighbors, even though the API (the plug) makes it very easy to do so.

(An interesting legal question might be if you set up a business designed to recharge batteries. You're basically reselling the energy. But you're certainly not extending the power grid!)

Imagine a court ruling that anything you plug into a power plug is a "derivative work" of the building or power grid. That's the tail wagging the dog. But it poses more problems as well. Anything that gets plugged into a wall outlet becomes part of the building! Or, worse...

If you look at the established laws about what a "derivative work" is, that implies that whomever creates one inherits (or is subject to) the intellectual property rights of the original work. Meaning that if a power saw plugged into the wiring of a home created a "derivative work" then the owner of that power saw would effectively inherit rights to either the building containing the electrical conduits, or the power company and its distribution network, or both. Sounds pretty silly, no?

If a Wordpress theme constitutes a "derivative work" of Wordpress, then the theme owner is essentially inheriting copyrights (and other rights) of the entire Wordpress code base. One right granted by US copyright laws is the right to create a derivative work. If the original copyright holder did not grant that to the person who created the derivative work, then the original copyright holder could go to court and, after convincing the court that it WAS a derivative work, request compensation or assignment of the rights.

But the purpose of GPL is to force everybody who uses the GPL'd material to inherit and distribute ALL copyright rights, removing the ability of anybody to claim any proprietary rights over any of the material. The GPL prevents anybody from prohibiting the creating of proprietary derivative works.

MORE ON DERIVATIVES VS. EXTENSIONS

Before there were power plugs, someone had to get into a wiring box and attach wires directly to some other wires. You could not easily unplug anything connected this way. In THIS case, it would make more sense to argue that the additional wiring EXTENDS the original design, but it certainly is NOT a "derivative work".

For example, adding a string of Christmas tree lights to a building does not create a "derivative" instance of the building's electrical system; it EXTENDS it.

However, if you used Photoshop to add lights to an IMAGE, then the NEW IMAGE would be considered a "derivative work" of the original.

Wordpress started out with no "plugs"; people had to go in and hack the code to add plugins and themes. These could rightfully be considered "extensions" to the code base. They certainly wouldn't be "derivative works" in any sense of the term.

Over time, Wordpress has added a number of APIs and well-defined interfaces to simplify and codify the process of extending it via plugins and themes.

Originally, "hacking the code" might have been a common approach shared by both Wordpress and Drupal for creating extensions, and it might have made sense for Wordpress to refer to the Drupal license at that time. Today, the two code bases have evolved considerably and they both employ APIs. I personally can't see how a license based on no APIs would be meaningful to interpret WITHIN the context of extensively evolved APIs.

Again, there's no way that plugins and themes that utilize the standard APIs would constitute "derivative works" of the core code base. They are "extensions".

WHAT ABOUT WORDPRESS VS. THESIS?

There also seems to be some overlap between two unrelated things regarding what's been said about Thesis' themes. There are two different issues at play.

First, the mere fact that a theme or plugin uses the established SPECIFICATIONS to interact with the Wordpress framework does NOT (IMO) in itself impose the GPL terms on that theme or plugin. They're using the API for exactly how it was intended.

Again, go back to the power-plug analogy. You cannot utilize a 110VAC outlet to power a 9VDC device. It is simply impossible. You'd fry the device! You need a power adapter. That power adapter is NOT an "extension" or "derivative work" of either the building, the power grid, or the electrical company. Or even of the power outlet itself. It is simply utilizing the well-defined specifications of the power outlet to transform the power coming through the plug into another form that can be consumed by a device with different power requirements.

Second, if the Thesis developers originally lifted a bunch of code from the Wordpress source distribution and used it as the basis of their themes, then THAT CODE would constitute a "derivative work" of the ORIGINAL CODE -- not the entire code base, but whatever modules they used. THAT code would inherit the original GPL terms, without question, since GPL prohibits the creation of proprietary derivative works. They can sell it; they just cannot claim ownership or any specific rights under GPL terms; nor can they impose any additional rights that might restrict its further distribution and adaptation.

GPL -- THE BIGGER PICTURE

Historically speaking, the GPL and related licenses were created in large part as an attempt to undermine the ability to patent software. There's a school of thought that says software patents should not be allowed. Indeed, most countries do not allow them.

Patents involving software were not granted in America until a ruling was issued regarding a process used to cure rubber in tires that was controlled by software. In that case, the software was merely considered instructions used as part of a larger process that happened to employ a computer to control the process, and the court ruled mainly that the patent could not be denied simply because software was involved. (Prior to that, software was considered in the same light as mathematical equations, which are also not patentable.)

But some think that courts have gone overboard and allowed patents to stand that are just plain silly. The GPL evolved as an attempt to build a broad code base that can serve as "established art" in undermining patent assertions.

So from a legal standpoint, GPL and derived licenses create a very nasty pile of spaghetti that would take quite a bit of effort and cost to resolve if they were ever taken to court. This is EXACTLY what they were designed to do -- make it cost prohibitive to litigate PROPRIETARY rights of anything that can be legitimately tied to any GPL code ever written.

So don't expect Thesis (or any other developers) to take legal action.

Similarly, I cannot see Wordpress or anybody trying to litigate a violation of GPL terms either. The "best case" is they'd win and the court would hold that GPL terms are legitimate, and probably tell the losers to stop claiming the code is their own. It's hard to see any monetary awards being made; if any, the winners would probably designate any award be given to a charity. The "worst case" is that they'd lose and the court would rule that GPL terms cannot be upheld under the law.

A NOTE ON THE USE OF API CODE EXAMPLES

Virtually any API will have some coding examples provided that show how to use them. These examples exist for the purpose of helping API users get up to speed quickly. They are not intended to constrain or limit API users in any way.

Trying to argue that the use of code examples to build plugins and themes would necessarily make plugins and themes that use them "derivative works" of the EXAMPLE CODE is extremely difficult to swallow. It's contrary to the purpose of building an API, and even delivering example code!

There's a test that courts have used when it comes to determining the likelihood of copyright infringement between equivalent code modules. This is where they determine how likely it is that different programmers of reasonable skill would create substantially similar code modules given the same specification.

It's entirely possible that certain API specs are so constrained that most programmers would create nearly identical code from the same specs.

This means that, in principle, it could be difficult to create plugins or themes that would vary much from the original examples. Examples are examples. They're good to use as a starting point, and the "fair use" doctrine usually makes it ok to use them in production code -- although as examples they're usually woefully inadequate for production purposes.

WHAT ABOUT FRAMEWORKS?

But if the example code actually defines a "framework" that needs to be embellished, rather than re-written, then that raises a whole bunch of additional issues that haven't been addressed at all. Frameworks are usually considered an integral part of the API if the API won't work any other way.

Personally speaking, I'd say that wordpress plugins and themes employ a framework more than a simple API. This is much more evident since the API has been rewritten to use a number of objects (php classes) that must be used to derive child objects with certain additional methods defined and specific behaviors implemented that conform to well-defined guidelines.

The base class objects, method names, and interfaces are already defined. The developer cannot change them, but must extend them to get the behavior they desire.

If ten programmers of reasonable skill levels were given the same spec, they'd probably all create very similar plugins. That does NOT mean the plugins are "derivative works" of the examples! The framework imposes very rigid boundaries on names and coding practices.

-David

I think the one thing that people are forgetting is this. In order to Use Wordpress, Develop a theme for WordPress, and or Write a Plugin for WordPress, you must agree to their licensing terms.

I keep hearing arguments about API, Copyrights, Trademarks, this is not necessarily about any of these it is about the licensing agreement, which in this case is the GPL (Note: the GPL does provide for copyright as well, but this is primarily a licensing argument as I see it).

You as a developer are under no obligation to develop a plugin/theme for WordPress, nor are you required to distribute your plugin/theme. If you choose to do so then it must be determined if the GPL applies.

James

The link discussing the Thesis themes state very clearly that the Thesis themes were based on pre-existing themes and code.

The works published as themes under the "Thesis" name could therefore be very easily determined to constitute derivate works under the existing copyright laws. Generalizing this to say ALL THEMES are derivative works based on how Wordpress works and some some silly notions about the use of include files and the way Wordpress calls various functions is absurd.

17 U.S.C. § 103(b) provides:

The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material.

US Copyright Office Circular 14: Derivative Works notes that:

A typical example of a derivative work received for registration in the Copyright Office is one that is primarily a new work but incorporates some previously published material. This previously published material makes the work a derivative work under the copyright law. To be copyrightable, a derivative work must be different enough from the original to be regarded as a "new work" or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes. The new material must be original and copyrightable in itself. Titles, short phrases, and format, for example, are not copyrightable.

Clearly, if you take a 100% original and unique piece of code and treat it as a theme within the context of the Wordpress framework, you are free to submit a copyright registration on that code. Since it uses NO pre-existing code, then it would NOT constitute a derivative work according to the explanations above and existing case law. Filing it as a derivative work would probably not be effective for copyright purposes.

The above article attempts to base the argument on the following logic:

This is saying, "the way Wordpress is designed, with very porous interfaces, few if any error checks, and direct access to internal variables -- all in direct violation of 'best practices' that have been used and promulgated throughout the software industry for 25 years -- that this somehow magically transforms the legal interpretation of what a court would say a 'theme' would be."

In other words, since Wordpress is poorly structured and lets theme developers access internal data in a potentially dangerous and destructive manner, the code making up the theme should be considered a "derivative work" rather than an "original work" for copyright purposes.

WTF? What does the internal programming architecture of Wordpress have to do with the legal interpretation of code that interacts with it?

I'd love to see any possible interpretation of the above statements that explain how a novel, unique work with zero duplication or inclusion of existing material could possibly be confused with a derivative work.

Is there any existing case law that supports this silly position?

It doesn't matter if the entire open-source community, the FSF, their aunts, uncles, cousins, and half the US Army agree with this position or not!

A 100% original work is not going to be treated as a "derivative work" for copyright purposes based on some argument about how the run-time environment might cause it to be executed!

However, IF you were to go down that path, then it's far more likely that Wordpress itself would be considered a derivate work of the Zend Engine and the rest of the php interpreter! I mean, it's pretty clear that they're running in the same memory space. The Wordpress code won't run without the presence of the php interpreter and run-time libraries. And since php is interpreted, Wordpress is able to modify and interact with large portions of the php run-time support environment and manipulate its state and operating variables directly.

These are the exact same claims being made to justify why themes should be considered derivative works of Wordpress!

But wait! What about MySQL? Maybe since Wordpress access MySQL code through the same mechanisms, is co-resident in memory with MySQL code, and can modify MySQL's internal state directly, then ... Wordpress is a derivate work of MySQL!

Or maybe Wordpress is a derivative of BOTH php and MySQL?

Either you're going to use the definition of what constitutes a "derivative work" in the copyright laws, or you're going to use something else that a court would ignore if presented with it in a copyright case.

Which is it?

-David

I've done a lot of reading on this the last few days and I need to change my opinion here.

From what I now understand if you create something that interfaces with a GPL licensed program in such a way that the output the user sees is combined in a way that would give the impression of a single program then your work must be GPL licensed as well.

As has been said above, this is not a copyright issue. GPL does not deal with what the author can do with their products as much as it deals with what the end users can do. It is an extension of end user rights more than it is a limitation of creators rights. I believe that is where things get muddy as most people are looking at it from the creator point of view only and the GPL is written from the end user point of view.

The main reason I prefer the MIT license model for working outside propitiatory code, is that you dont have to deal with all this Junk, and that is what this is, junk, I mean look at all the different opinions, here, all the different takes on the same issue, anything that is this confusing is just useless for what it was intended to do.

And to make it even more ironic, there will be those that will argue that the above statement is not so according to their opinion and understanding of the way that GPL, LGPL, FGPL< yes, that last one is made up, and you can guess what it stands for, still regardless of how you understand it, there is one thing that cannot be changed, that is your rights under the laws in your respective jurisdiction.

That trumps all other arguments, but really who wants to argue all that nonsense.

Does the legal parlance then define the word 'derivative' differently to what it means in the English language in general? I don't mean this ironically, I am genuinely bemused. When I use the word 'derivative' I mean something that to a large extent includes elements of something which preceded it (not meant to be a dictionary definition). So we say, "that song is highly derivative", meaning it has parts of the melody or words lifted wholesale from some song that existed before it. Or "natural gas is (a) derivative of coal" (ok, with the article it's a noun, not an adjective) meaning natural gas is taken from coal in which it exists in some form previously.

So the word 'derivative' used in relation to software in the common English sense would refer to code which is based on code taken from another source. E.g. you took Wordpress and you branched off your own version, called LetterPress, which included some portion of the original code. Which is what I understood the word 'derivative' to mean all along with regard to GPL!

Yet now there is this (to me) novel meaning of the word which refers to code which could not run without reference or extension to the original software, even if it contains no significant amount of code taken from the product it depends on.

*shakes head in confusion*

I started to feel a bit confused here.
can I ask my proggramer to build plugin and sell it later ?
can i sell other plugin as affiliates ?

skatir, yeah sure you can sell it. Just be aware those you can sell it to can do anything they like (so long as they still stick to the GPL too). Which includes modifying it and selling it on etc etc