GPL3 or GPL2… or why Automattic won’t release wordpress.com plugins

While we’re waiting for a response from Matt with either his WordPress.org (voice of the community) or Automattic (voice of the leader) hat on to fill us in on what’s going to be the future of WordPress MU and perhaps answer a few of my questions, I figured I’d jot down some possible answers to a topic that came up quite a bit in the discussions related to that post.

Namely, a fair few people asked – Well, Automattic doesn’t release their code (or themes) for plugins they use of WordPress.com, or VIP sites like GigaOm – and yet they kick up a stink about our themes and plugins being behind a paywall.

What’s up with that?

Well it’s simple really, whether by design or coincidence, WordPress chose a really great GPL license, namely GPL2 rather than GPL3.

Now, IANAL, but I believe that the fundamental difference between GPL2 and GPL3 is that GPL2 allows you to develop and use integrated code (plugins, themes etc.) as a service with no obligation to share it publicly *unless you distribute it in some way* whereas GPL3 forces you to supply that code to anyone who asks for it.

So, were WordPress GPL3 I could rock up to Automattic’s VIP clients (and Automattic themselves) and demand they provide me with the source code, whereas with GPL2 I can’t because the code hasn’t been released yet.

I’d be more than happy to be proved wrong (and I’m sure there are more erudite readers of this blog than I am – especially in this area) – but I’m pretty sure that’s the answer to the question.

So do let me know if I’ve got it completely wrong!

However, whether that’s ‘ok’ or not is another thing entirely :)

Personally, I’m fine with it, as it seems to make sense that if a WP user develops their own theme they shouldn’t have to hand it over to anyone who wants it.

Also, I wouldn’t stress too much about things like BuddyPress membership site plugins not being released, as we’ll be making a great one for you down the line at WPMU DEV Premium (we’ll be doing this because the generous members of the site allow us to dedicate time, employ developers and generally make it).

But whether everyone thinks it’s A ok I’m not sure?

It does strike me that some of the more ‘strident’ (ahem) open sourcers out there would much prefer a GPL3 license., and apparently there are good reasons to upgrade, but I for one ‘aint clamouring for it.

14 Responses

  • Well the problem, as I see it, is that according to this http://www.gnu.org/licenses/rms-why-gplv3.html , and assuming (for now) that a plugin has to have the same license as WordPress (GPL), then all plugins must use the same GPL version as WordPress (GPL2?) as GPL2 and GPL3 are “incompatible”

    “When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. This is because both GPLv2 and GPLv3 are copyleft licenses: each of them says, “If you include code under this license in a larger program, the larger program must be under this license too.” There is no way to make them compatible. We could add a GPLv2-compatibility clause to GPLv3, but it wouldn’t do the job, because GPLv2 would need a similar clause.”

    Just to add that little extra bit of complexity to the issue :)

  • New Recruit

    @James

    You got it totally wrong: GPLv3 would not do what you claim. Even the famous anti-tivoization clause deals with tangible products. Affero GPL (or AGPLv3) would do what you are asking for.

    On the other hand, given that you probably had never heard of that license before, you should not blame others for not using it…

  • New Recruit

    @Tuomas

    Like I said, I’m not an expert by a long shot, but I have it on fairly decent authority that that’s what GPL2 protects (even if it’s in fact AGPLv3 that allows it rather than GPL3).

    And I’m certainly not blaming anyone :) Just trying to answer an oft asked question.

    So I’m being quite genuine when asking for enlightenment – I’ll happily update the post to reflect any inaccuracies that can be cited.

  • Oh James, you are such a joker. You sell something that is free to people who don’t know any better. You do this by cleverly taking a domain name that makes you look official, creating an ethically ambiguous business out of it.

    From what I can see Automattic have released many plugins and themes into the community. What have you done for it? Do you want yet more code to masquerade as your own and re-sell as ‘premium’?

    Your interpretation of GPL3 is wrong, by the way.

  • New Recruit

    There’s nothing ethically wrong with the premium business. It’s called marketing. The actual product is a good product and if people – like me – want to pay for it, that’s our business.

    It should be noted, that Free Software is “free as in free speech” not as in “free beer” (To quote RMS). It is fully in line with both the letter and the spirit of GPL to sell the code. What’s different with the proprietary EULAs is that you actually sell the program, not just a right to use the it.

    As it happens this means that your clients have the right to resell it under the same terms. Therefore business models that are based around the scarity of a program don’t exactly work. If you charge very much of the program, you are likely to get competitors from your license. In stead you can build your business model around something that is utterly untransferable, namely expertise. (You get the program for free as in free speech AND in free beer, but to get the support you will either have to re-engineer it or pay.)

    To the client there are a number of upsides in this approach. First, the entry barrier is low, as you can start using the program with very low cost. Second, there’s no fear of vendor lock-in. If you have EULA and the vendor goes out of the business, you are in shit. If the code is GPL’d, you can give it to any vendor who is willing to learn it and you can continue to get support for it. Third, you are more likely to get the code customized for your needs. It is in the interest of the original vendor to keep advantage in understanding the codebase (thus keep competitors away) so that they maintain and can sell the expertise to make the modifications. And if they wont or you want to make any modifications yourself, you can: it’s your code.

    There are also many advantages to the company selling the products. First, they get a very close ties to the clients: understand the customers needs and are able to answer them promptly. This tightens the customer relationships creates customer loyality. It also boosts innovation and product development: customers share many needs, and once you make something for one customer, you can turn it as a value added to other customers as well. And you didn’t even have to come up with the idea yourself.

    Another interesting view is the intellectual liabilities (as opposed to intellectual assets) that open source vendors can utilize. If they make a customization, it may be a good idea to contribute it to the core project. Otherwise they are in danger of having to re-implement it every time there’s a (major) change in the sofware core. But if they actively push code – especially fundamental features their other products use – to the software core, they effectively get to outsource the maintenance of those features with people working on the core. And as a side-effect gain goodwill for contributing to the core.

    In fact there are many other advantages of contributing technologies you have developed to the core project. First, if it is something that will be put in the core anyway, you will want your implementation to be there. That gives you advantage of knowing it best, and that’s a marketing gain. Also it gives an impression that you are a benevolent company giving some of their core technologies into free usage. But the fact is that unless you do that, you will end up having some obsolete technology and implementation that is not (as good as) yours, and you don’t know as well.

    So, here are some suggestions as on how to utilize your expertise in the letter and spirit of GPL. Many of these you are already doing, and quite well.

    1) Make yourselves known in the community. Get goodwill. Make people to think that you want the best to the community and that if someone wants to pay a bit more, they will get much more. Don’t blame people, but praise them for what they have done. You don’t have to market your own solutions all the time, just proove that you are experts. Participate and give free high quality help on the public forums, but apologize for your lack of time, because the closed support forum has the priority. It’s called marketing. People will both see your kind attitude, and expertise, and know that they can get better. And not-only those, who you help, but also others, who search the forums. And no-one can complain that you are trying to force-feed your payments. You will want everyone to talk just good about you.

    2) Advertise “Premium” stuff as a community that develops and gives support to the technologies such as plugins and theme-packs. Invite members of that community to contribute and ask them for a gentleman’s agreement not to share that code onwards, lest the community will suffer. (It’s legal, as such agreement is not binding, but people are likely to comply, as it is in their own benefit.) Also, ask the community members to participate in various ways.

    3) Search GPL licensed projects you see worth developing, and start developing them into premium versoins. Multi-domain plugin is good, your version is better. And if someone has problems with it, help. If people want some extra features and the original author can’t do it – e.g. because they are not paid for it – take a look at it.

    4) When it seems evident that some of your premium features are getting serious competition from no-cost alternatives, either in the core or in plugins, make sure your versions are technologically superior release them without charge. You want people to be using your code, whether they pay to get access to the code or not. This way people will come to you with the code, and anyway you will retain your technological advantage, the only real value added of experiise. The other option means that you have only to lose.

    5) Create documentation and tutorials. Make sure it’s high-quality, both in content and layout. Update and impruve them over time. Use them to create the feeling, that with your help everything is easy as breeze. Release some of that as freebies (Andrea’s ebook about installing WPMU is an excellent idea. It directly brings potential customers). A public whitepaper discussing on different webserver setups (Advantages of Apange vs. nginx, vs. lighttpd vs. cherokee and WP their specific setup) or MYSQL database security measures and how WP uses them creates an image that you are people one should turn to when there are questions.

    6) Keep two versions of the code: one well documented, and another with documentation stripped. License the documentation, and release it with a more restricting license. (E.g. do not share.) Keep however the essential freedoms intact: people must still have the right to modify, use, redistiribute etc. the *code*.

    7) Make sure all the material is up to date and that people will know it. If a plugin is said to work in 2.5.3, I for one am wary to use it with 2.8.4. Just make sure it works and update the info. And if it needs a touch-up, give that. The same applies to tutorials. Update the screenshots and version numbers. Even if the content is the same, up to date version number and up screenshots make a new version appealing. A touch-up of color will help too. It’s cheap, and well worth it.

    8) Services such as wp.mu and blogs.mu are good ideas. If you don’t want to go for AGPL, you can do the same as automattic and build in them some additional GPLd, non-released goodies. How-about a self-extracting package with installing wizard, one could use to install to any system?

    9) It seems I cannot automate premium feature updates the same way as the rest. Create a plugin for that. Make sure it can also handle themes and Buddypress/bbpress stuff. Use registration key with timestamp.

    10) Make it all searchable from one place. Easy navigation. Set up an eMarketplace for individual products (such as subscriptions or single documents, or services) and where community members can sell their stuff to the open audience (and each other). Take overhead from the revenue (but not just placing the products there.)

    I’m just saying this because I use the services and want the services to keep running smoothly – and because I want GPL-spirit commerce to thrive. So, just my 2c.

  • Well, Automattic doesn’t release their code (or themes) for plugins they use of WordPress.com, or VIP sites like GigaOm – and yet they kick up a stink about our themes and plugins being behind a paywall.

    1. Not completely true:
    http://code.svn.wordpress.org/
    http://code.trac.wordpress.org/

    2. You DO understand that its not wise to release all themes/plugins that make the look/feel and functionality of WordPress.com, WordPress.org, Automattic.com etc into the wild, cause then its 100% certain that someone with poor ethics will take advantage of the code to make some quick bucks, luring users to believe that faux sites are genuine sites.

    3. Regarding the stink, I also feel some bad smell but I`m not sure where it comes from, but what I do know is that this “fight” hurts your brand and makes people like me hesitate in spending money on your services.

    I`ve been thinking about joining for a while, but now I think I`ll put it on hold to see what your next move will be and if wpmudev will support the merged code. I dont know what my conclusion will be but from a marketing/branding point of view this flaming seems counterproductive.

  • thanks for the great post. i love this site. but i have a few plugins running that are from automattic. i dont know if they actually developed them or just distributed…but anyways.

  • New Recruit

    OK, I’ll keep going on my rants… Some of these you may already have done, but I just haven’t noticed, so excuse and correct me.

    I think you should consider wpmudev.org as a showcase for the premium site. As such it should be a place where people want to came, and where people get so interested in you that they will want to became premium members. Here are a couple ideas:

    1) Plugin taxonomy. There are over 200 plugins, and by default they are ordered in chronological order. Standardize and categorize the tags into a fairly short and meaningful list. List the tags of a plugin (or whatever) clearly on the plugin description. Helps searching big time. (This applies also to the premium side.)

    2) The only thing chronological order is good for, is seeing that you don’t go too far back in time! And the oldest ones have been added over three years ago. For an average Joe this seems like there is all kinds of crap still in there that no-one has bothered to clean out, and if the open side is in this shape, whose to say that the premium is like? At least prune out the oldest stuff, having verified that it no longer works. If a plugin is not maintained, it should not stay on the site.

    3) Many of the plugins seem to be updates to older versions, just listed separately. Also, many have effectively been deprecated by some premium plugins or core changes. As for some of these, an idea is to provide a stripped down version of a premium plugin, and mention what it’s premium counterpart offers (in addition to more frequent updates).

    And to the other direction: from time to time release some of your premium plugins as standard. Contribute your premium code to the core. You want people to use your code, as it eases the upgrade path. That makes you look generous and co-operative. But if you don’t do it, someone will re-invent the wheel in a way that is incompatible with your code and people will hate you.

    4) Arrange the search in such a fashion, that it possible and search plugins from both premium and standard collections on the same query.. Premium members may like to install also non-premium plugins. Mark the premium plugins clearly. Opt-out for premium stuff, if other users insist in not seeing all that great premium stuff.

    5) The LDAP plugin is maintained elsewhere. It is an excellent plugin, and I think it would be a good idea to introduce it and link to its site. It doesn’t matter that it’s not your plugin: people come to the site in search for solutions, and if they find one, they are likely to come again. You are essentially telling them that this is a site to find solutions, some of them free, some of them third party and some of them premium. The more often people land on this site the more likely they are to get interested in the premium stuff.

    And remember, these projects themselves hardly oppose any advertisement themselves :) In general, when you recommend other sites, it creates an image that you are a good site to start from. And on your frontpage you can then advertise your products, both standard and premium. It’s a win-win. Partner with them: You praise them and agree that they link to your site for similar reasons: people who are in need of LDAP authentication are likely to need of other advanced technology as well. And there may be other similar plugins and solutions, e.g. themes / theme frameworks à la sandbox or WPML. You could have them categorized as third party products. Remember to keep up with the updates, partnering will help here.

    6) Consider hosting the best projects, even if they would not put their stuff in premium. Encourage and help them in their efforts.It is again a win-win situation: people come to you for great stuff, and you get more great stuff and active developers in your community.

    In fact, you could consider creating and maintaining such community a priority. That means more plugins, more developers, and potentially more premium developers. Make devs feel welcome and wanted. High quality content will attract people in the first place, and even higher quality premium stuff will make them pay.

    7) There are some old plugins in the list, that seem quite interesting, but people are not likely even to try, because they have been added so long ago. These could be updated, again in two versions, standard and premium.. For example: SMTP mailer. Premium features to support remote servers with SSL/TLS connection and authentication per user basis. Or webmail, with similar – and more – premium features. Or live IRC-chat on local server. Premium features remote servers, jabber etc. protocols… (maybe as plugins to the plugin) You can well borrow the code from other GPL projects and charge for the derived version – it’s legal and totally in the spirit of the license.

    8) Make a list on supporter compatible plugins available at the supporter plugin page. Consider releasing a stripped down version of it as standard, and many of the features as premium plugins. (some as standard as well). It’s a good throw in.

    9) You could advertise WP.MU as keys to hands (or whatever is the English expression) solution. That’s what people will be searching for.

    10) Make your own site a showcase of your technologies. Explain how you use login redirect plugin, domain mapping plugin, autoblogger etc. to do all kinds of nifty features. Make a whole section, where you explain in detail how some plugin is used to create certain functionality. Example is good marketing. Use your own set of plugins to create community features use them to improve the co-operation and feedback. (As in: How do I contact an individual developer about a plugin? Just clicing the username didn’t do it…) Or, if you like, use BuddyPress.

    And finally: Stop bashing automattic. (Or anyone else for that matter.) Like in this blog, or in the one where you asked claimed they want you to go out of business. It’s not about what you say, it’s about how you say it. I understand you were upset by what Matt said. But Matt had on point, a point you can actually turn into profit. So have the right attitude and create a good impression.

    Remember, there are three things that are crucially important to you: 1) Your technological expertise 2) Your client community 3) Your reputation. People will come pay you because they need something and are willing to use more money than time to get it.

    You want your technology being used as widely as possible. You want people to think that it is both useful and easy to use. You want people to come to your site in search of solutions. You want people to have painless upgrade paths from the standard plugins to your premium ones. You want people to come for you for your nifty stuff and learn about the absolutely amazing stuff (like supporter, ad stuff, admin stuff, and domain mapping (with remote login!).

    Smile, and the world will come to you with their wallers open. Be cranky, and they will leave you.

    Just my 2c. I want to have my premium service also in the next decade.

  • New Recruit

    Heh, I take it all on board apart from the automattic thing – us bashing them would be like a sparrow taking on an eagle – ill advised at best and and if approached, only done with all your friends onside :)

    Having said that, the chances of me stopping calling a spade a spade, or playing politics with niceties, are even slimmer… so we’ll see how we go.

  • New Recruit

    Still thinking about selling GPL’d code… (must be an obsession) you could actually use subcontractors. The great thing about GPL is that you can take code written by someone else, use and change it as you wish, and redistribute it – with a cost if you like. The only catch is, that it has to be under the same license, as the original copyright remains.

    Thus the following scenario is fully possible (and completely legal and within the letter and spirit of the GPL): You spot a good GPL’d plugin someone else has written, refine it to be even better and put it in your premium collection. Unless you do the refining part, the original plugin will undersell you, so there has to be some value-added. But there is an even better idea you can do: you can actually compensate to the original author in some way, e.g. giving money or – in some cases even better – providing them free access to some of your restricted resources, such as high quality documentation instructing them how to make even better code.

    Taken to the logical conclusion, this actually means an affiliate program: Developers work with you and for you, and you return them some of the profits. (Your current affiliate program is only about extending the customer base, this would be about extending the product base. Consider your ability of being able to get customers to pay in the first place an advantage.)

    If you play this right, and demand high quality code & documentation and demand regular updates, people will actually come to you asking you to sell their products with a small royalty. (Their options: give it away without any royalty or create their own, competing business.) I think that eventually most of the code should be released for free – as in beer, all code should be released as Free. The really good code – like MultiDB and other complex stuff – and directly money making applications – ad stuff, eCommerce, supporter/upgrades stuff – should always be commercial. All the newest stuff could of course have a price ticket. The better code, the longer. After an initial release behind walled premium garden much of the code could be released for free in the standard side. For example, when a new version with the I-want-that-feature of a-cool-plugin comes up, the last season’s model gets dropped to the standard side. Or when the novelty is over and it’s getting copycats. And the sub-premium -standard and not-well-enough maintained code you should just drop out of the premiums to the standard side.

    As long as the code is GPL’d, its essentially Free anyway, and people can hand it out freely, if they think that it is a sensible to undermine their own advantage of getting the code. This means that sooner or later your code is bound to leak – the sooner the less value added your customers see in it. (Think of First Comment vs. MailChimp.) The value added’s here would be novelty, complexity, custom demand and maintenance. Remember, the only reason people don’t give their copies forward for free is because they don’t want to.

    Oh, and BTW, I don’t think you would like the WordPress codebase to be licenced with AGPL(v3). Your customers might not like it.

    Just thinking how as many coders as possible would get paid to create as much as high quality Free software as possible, which could in turn then be released with as low cost as possible to as many people as possible… Got to get rid of this obsession…

Comments are closed.