Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

They say WordPress is GPL, and therefore all plugins and themes made with it are supposed to be GPL. Fine, but if I spent three months coding an extremely complex app theme with the intent on selling it repeatedly for profit, such as a medical office scheduling system theme, then how can I protect my investment, if even a moderate amount?

share|improve this question
    
Simple: Can't be done. –  kaiser Dec 20 '11 at 23:39
    
my apologies if i am wrong... its true that wordpress is a free GPL cms but any theme you create is subject to Copyrights laws just as anything else is... the thing you cant sale or claim any rights to is wordpress or other people plugins etc. –  Sagive SEO Dec 20 '11 at 23:45
    
@Sagive it is opinionated by many in WordPress community that themes and plugins are derivatives and their code should be under GPL. One can go against this, but it is fast way to put yourself in negative light for many and not something that should be first pick. –  Rarst Dec 20 '11 at 23:53
    
i agree @Rarst but speaking purely leagly ;/ –  Sagive SEO Dec 21 '11 at 0:23
    
As long as people can copy they will copy, you can look to many products in many different markets to find examples of this, i'd agree with Chip on this, have your code use an API key, if your code expects a key and there's only one avenue to getting one it negates the worry of code copying(and it's inline with the GPL, so covers both your bases). –  t31os Dec 21 '11 at 13:18
show 2 more comments

5 Answers

up vote 10 down vote accepted

In addition to the other two suggestions, there is another possible approach: move all of your custom-app functionality out of the Theme, and into a hosted web service, to which the Theme connects via API key. That way, redistribution of the Theme itself does not impact your custom app-based business model, because the app would require Theme plus valid API key.

This approach may or may not work, depending on the nature of your custom app, but it is a successful model for some commercial Plugins, and is fully GPL compliant.

share|improve this answer
3  
Along with requiring an API key to work I've also seen requiring one to upgrade. This makes the app fully functional but any upgrades require a valid key. This allows you to provide one click upgrades to thouse who pay for the app. –  BandonRandon Dec 21 '11 at 21:18
add comment

Legality aside, I generally look at it this way, write good code and offer good support and people will come to you. There are many premiume themes that are GPL and are doing great. Look at WooThemes,Headway,StudioPress (Genesis) to name just a few companies that write quality, fully GPL themes and make a living doing so.

In my opinion some of their sucess is credited to providing quility support and pricing their themes at an amount which they can afford to live but others can afford to pay for them.

I think this idea of "If I make my theme GPL someone is going to steal it and all my work is going to be gone" is just false. Sure, maybe someone will steal it, give it away. But if you offer support people will still be come to you and get it. Not to mention the fact that they know what they are getting. Free/stole premium themes (and some non-premium ones) often contain spyware/malware. I'd rather pay someone for something I know works then deal with a virus later.

One last example (and maybe my favorite) is Justin Tadlock's Theme Hybrid, He releases it for free as GPL and charges $25 a year for support. A fee I gladly pay because his support is amazing.

Bottom line, if you create a trusted environment and people will come.

Another solution would be a terr solution, $X for the product, $Y for support, $Z for additional add-ons

PS: personally I don't buy anything for WordPress that is NOT full-GPL.

share|improve this answer
1  
"Free/stole premium themes (and some non-premium ones) often contain spyware/malware. I'd rather pay someone for something I know works then deal with a virus later." Extremely good point! –  Volomike Dec 21 '11 at 12:28
1  
Almost exactly what I would have written, if I'd had the energy to write it yesterday. –  Chip Bennett Dec 21 '11 at 12:53
add comment

If you want to apply some legal restrictions to your product and stay in line with GPL practices of WordPress your best option is split license:

  • PHP code under GPL;
  • other components (such as design, images, CSS) under license of your choice.
share|improve this answer
    
What if I've included in the theme some PHP files that don't load the WordPress header bootstrap, and don't use any WP Codex APIs? Are those supposed to be GPL too? –  Volomike Dec 21 '11 at 0:08
2  
@Volomike GPL stuff in context of PHP is kinda grey area and things are usually matter of opinion rather than legal facts. In my personal opinion it is least confusing and problematic to have all of PHP code under GPL[-compatible]. –  Rarst Dec 21 '11 at 0:37
1  
The problem with this approach is that the custom-app code is very likely written in PHP, so if one desires to adhere to the official WordPress interpretation that all PHP code is derived, then a split license won't help. –  Chip Bennett Dec 21 '11 at 12:58
add comment

Something that hasn't been mentioned in this thread are the topics Encryption and Obfuscation.

Encrypting your code with IonCube or Zend Encoder are but two popular methods for protection themes and or plugins that I've seen in use.

The problem with encryption is that with enough will and desire you can decrypt the files back into their original state. Sometimes the results will vary and depending upon how well the the type of encryption methodology is understood will often determine the success or failure in decrypting files.

There are unscrupulous individuals who have become quite skilled at the art of decrypting files from IonCube, Zend and others. For the average person, the hassle with often outweigh the worth.

The next methodology is obfuscation which I have rarely if ever seen used. In my opinion it can make it near impossible to decipher files that have been properly obfuscated which in turn also means you can not edit files with obfuscation in the traditional manner and need to keep copies of your master files for any modifications, updates, bug fixes which usually isn't a problem.

However a combination of both encryption and obfuscation would make it near impossible if not absolutely impossible steal your proprietary code. It wont stop people from using it, assuming it functions, but it will stop people from modifying it or copying functionality to create their own similar product.

Using an API Key as mentioned above is the other great method to help secure your products BUT there is a downside to this method and that is by storing some of your application logic out of the original theme or plugin means that the user needs to connect to your server to retrieve that logic in order for the theme or plugin to operate properly.

This sounds like a great thing and it is for the most part but consider what happens if your server were to go offline even for an hour or two. Would this render your theme or plugin unusable? No doubt it would. Then you'd need to consider what kind of impact that would have on the end user.

You could circumvent this, as best as possible, by having some failsafe server locations handle the distribution of your API logic such as using cloud based services from reliable companies such as Amazon and more in addition to directly accessing logic from your server.

Then you'd need to weigh up the cost in overhead and ultimately the worth to you. Is it really worth the time? I guess that's project specific and dependant but considerations one must make ultimately.

The bottom line is that most people who will pirate or steal your product, theme or plugin are most likely to have never bought your product, theme or plugin in the first place.

There are often thought to be three types of people in our environment,

  1. Someone who will steal and pirate anything, always.

  2. Someone who will attempt to steal or pirate anything, before purchasing a product.

  3. Someone who will simply buy your product, because its the right thing to do and the most reliable way to guarantee that your product operates as described.

Although pirating and stealing of themes and plugins in rife around the Internet, the amount of people who actually use your themes or plugins consistently enough to warrant any damage to your bottom-line is somewhat miniscule.

Its not to say that we shouldn't do everything within our power to minimize that loss, but often your efforts would be better spent in creating more products and or marketing existing products further, as well as diversifying the way in which you offer your product.

With the rate at which many products either update with new features or fix bugs, it often renders previously pirated products useless or not as fruitful had it been paid for.

As mentioned above, Encrypting and Obfuscating code, combined, are two methods well worth further investigation in addition to API style integration, to help secure your products, themes or plugins in the best possible manner.

share|improve this answer
    
Please don't suggest this, The GPL license required the code to be "the preferred form of the work for making modifications to it." That means no obfuscation or encryption. –  Wyck Apr 7 '12 at 15:07
    
How is it any different than using an API key? Which if you haven't noticed was the accepted answer! Hosting part of your application logic on a third party server and withholding it as a result is effectively the same thing as either encrypting or obfuscation. If you are encrypting or obfuscation proprietary code that does not include any WordPress specific API functions then I don't see how this is a problem. –  userabuser Apr 7 '12 at 16:11
    
It's completely different, the API code is still open source and compatible with the license, it's a service. Please read up on the GPL. –  Wyck Apr 7 '12 at 20:12
add comment

If you are selling it then it doesn't need to be under GPL as you can't sell it on WordPress's Sites. You can just distribute it yourself under whatever license you like. The GPL restriction is just for the Wordpress.org repository's, and seen as you can't sell it under Wordpress.org, you can have whatever license you like.

share|improve this answer
2  
That is simply untrue. All PHP that extends WordPress is either GPL or in violation of WordPress' own licence. –  Chris Cox Aug 6 '12 at 14:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.