Skip to content

Dear Wordpress'rs, or, What is GPL?

Not sure if anyone has watched this yet, but Matt's latest video contains important misconceptions about the GPL.

Matt says (5:22):

So a common misconception about the GPL is that, like let's say, I'm hired to make a theme for a client. Does that theme fall under the GPL? And the answer is, no! Because it's not being distributed. Uhm, when something is distributed it's available for download to the public, you're selling it in a store, you know, it's sort of mass-distribution. When you do something for one site, or just for yourself, like for example, the theme on my blog, it's just for one site. It's not being distributed in any way. The GPL doesn't kick in.

But the GPL kicks in.

First off, whenever you base your work on GPL code it becomes GPL. Matt also agrees on that (if you watch the entire video).

The questionable part is:

  • Is distribution really a requirement? Or is it GPL right from the start?
  • How do you define distribution?

First off, I could not figure out the distribution requirement, but if in doubt, I think it is not a requirement for your code to become GPL. This is indeed what a lot of people describe as a loophole in the GPL and this is why the AGPL was invented.

Furthermore, what Matt thinks distribution is ("available for download to the public, you're selling it in a store"), is wrong. It does not matter if the code is distributed given to a friend, client, your grandmother or someone riding the subway with you. It's always GPL.

What I agree on is, that the GPL does not force anyone to distribute their code, or changes to GPL code.

In the end, the bottom line is: When the code is given away, it is GPL — the license applies!

AGPL vs GPL

I've previously blogged about the differences of the GPL to AGPL. The fundamental difference is that when GPL code allowed anyone to make changes and they could keep the changes to themselves, the AGPL requires them to contribute those changes to the project. In today's world, and with the nature of most of the software and its environment, it's virtually impossible (or illegal) to not contribute them back.

Conclusion

In a nutshell — I believe even Matt's own theme is GPL. **The real misconception about the GPL is, ** that people think you have to give it away (for free).

The GPL really means that whenever Matt decides to give his theme away (for money, or for free), he will have to provide the full sources of it, etc.. So for example, Matt couldn't use an encoder to hide his secret PHP code and then offer it for download.

And that is all.

Forced contribution

I'm not exactly neutral when it comes to anything remotely related to the GPL license. Personally, there's a bit of a GPL scare when I see code that's released under that license and I usually try to avoid it.

But (primarily) due to RoundCube being licensed under the GPL, I think I do know what it entails to release code using this license. In addition to that I have read a lot about the license, I even wasted spent three hours one night to listen to RMS.

In the end — the GPL just did not grow on me, or made me happy.

Open source

I am a firm believer in open source. I release code for free. Whenever I have the choice, my free contributions include the freedom to really do whatever you want with my code. Because if I did not meant it, I would either sell the code, or not share it at all.

I recently read Zed Shaw's reasoning why he believes in the [A,L]GPL and that same day I walked into yet another license discussion on PEAR's IRC channel (#pear@efnet), and I felt like I need to write it all out.

The GPLs

GPL in a nutshell

  • The GPL means that whenever I use code that is licensed under it in my code, my code automatically becomes GPL too.
  • The GPL requires me to release the source code of the software when I give it to others [them].
  • The GPL allows them to give it to other people as well, license still applies.
  • (Contrary to popular believe, ) The GPL also allows me to sell software. I'm not required to give it away for free.

If you still do not understand what the above means, here's an example: Wordpress. Wordpress is GPL and therefor all plugins written for Wordpress are GPL too. I realize some people may think that there might not be too much that you can do in a plugin, but if you wanted to make money of your work (plugin), the options are pretty limited.

LGPL in a nutshell

The LGPL is basically the same as the GPL, but if I use LGPL software inside my software, my software does not become GPL.

Affero (L)GPL

Because web software is often not distributed (think of SAAS), the GPL people came up with an Affero clause.

This clause requires you to open source your changes to a software/library even if it's only accessible through the network. In plain English — if you do SAAS (Remember, plain English!), or a simple website, and do not directly distribute your source code to your customer, you will still have to open source your changes because your customers can access it anyway.

The Affero clause is currently available as AGPL, and soon as ALGPL.

Non-restrictive licensing

When I speak of non-restrictive (or liberal :-)) licenses, I think of the (new) BSD, MIT and Apache licenses. In a nutshell, they all allow you to really do whatever you want. Whatever, of course except for removing the copyright on the source code.

  • They do not force you to open source your changes to the code.
  • They do not force a license on your own code just because you happen to use it.
  • The do not force you to release the source code to your customers.

Reading the above, one would see that these licenses are very compatible with typical business interests. They all come in handy for frameworks such as ezComponents or the Zend Framework — and many PEAR components use them as well. They really bring freedom of use the user, without imposing any duties on the user, and the best of all: the user can contribute anyway.

Impose

For a lot of people the world is black and white. You see other people benefiting from your own work hiding everywhere. And it's all too easy to find a license to impose your own beliefs on others. Because if they do not get it, there is a way to make them.

This rather simplified approach to a pretty complicated topic is easier to comprehend and therefor popular. And I can't blame anyone. Think further — religion. People who convert or find a thing for themselves easily become outspoken about and start preaching their new found happiness to others.

It's very human. If it makes you happy, you want to share.

This is of course meant with no offense to people like Zed Shaw who feel like they did not get their share of the cake (even though — Hey Zed! — a ton of people run your software (Mongrel)). I do understand Zed's point of view though. Visibility in the open source world does not pay your monthly bills. I'm not naive like that. On the other hand, there are more than a few examples from the the open source world where a company is build around an open source product and the company offers services — such as consulting and support — for said product.

The bottom line for myself is that I do not like to force people to do something. And no one does, right? (Except when the motives allow it!)

Conclusion

I believe that more people will contribute to open source because they believe in the cause. Not because some license forces them to do so. A lot of people get into open source because they use(d) open source software already and decided to contribute to the community. A lot of commercial entities fund open source development — heck, for whatever reason, even Microsoft does it.

If anything, the Affero clause will cause is to hinder the adoption rates of the software in question. And that is not just because all these licenses are written in English which requires a law degree, but because when you manage to understand them, they impose a threat on your own intellectual property.

Mail_Queue: 1.2.3

Despite Mail_Queue being a PHP4-compatible package, I still like to use it on current projects because it is so easy to implement and because it gets the job done. So, over the last weeks (and especially since PHP moved from CVS to SVN :-)), I put in a little time, and especially with the help of Ken, we managed to push out the 1.2.3 release today.

What's new?

changed license from PHP to the (New) BSD license

This is good news for two reasons. Numero uno, GPL-licensed (open source) projects may bundle Mail_Queue now since the (new) BSD license is compatible with the GPL. And secondly, because (re-)releasing the code using this well-known license also gets rid off another entry barrier for commercial entities and also provides them with enough flexibility to use this code inside commercial applications.

bug #7850

This one is a tough one, and only bites you if you really adhere to backwards compatibility (aka BC) and work with an older code base. ;-)

So the story is, that with PHP4, a constructor cannot return a PEAR_Error object. PHP4 also did not have exceptions. So what we implemented as a work around it, and of course to keep BC, was to introduce a new "factory" method (which can return a PEAR_Error object). In addition to the factory, we added helper methods (Mail_Queue::getErrors() and Mail_Queue::hasErrors()) so you can check the state of the class at any time.

bug #14626

This one's self-explanatory — and the only real bugfix in this release.

minor CS fixes

To make the PEAR test suite happy. :-)

request #15049

We added a method to count emails in queue. This is currently only implemented when you use the MDB2-based backend. (Side-note: DB, MDB and creole backends are deprecated!)

request #14921

Implemented optional support to sleep() in between the sending process — to not hammer mail servers.

request #6456

Additional parameter validation to deal with PHP's loosely typed variables.

requests #16064, #16068

These are Ken's contributions to the Mail_Queue release — callback support to run a custom function whenever an email was send (or queued on the SMTP side). This could be used to provide extended monitoring and metrics on the sending process. Yay!

Installation, or upgrading

Existing install:

pear upgrade Mail_Queue

New install:

pear install Mail_Queue

There is nothing else to do. All new features are optional, and nothing requires you to touch your code base. The beauty of BC!

What's next?

I added a roadmap for 1.2.4 last night, but I'm not sure if we will really get to it. I'm trying to channel all efforts to Mail_Queue2 (which is a PHP5-only port of Mail_Queue and already contains most (if not all) the features included in Mail_Queue's 1.2.3 release. If you would like to contribute, please check out the project on Google Code and let me know your thoughts.