A (long) while back, I created a library for WordPress that allows plugin developers to easily add new buttons to the editing area, regardless of whether an author was using the rich text editor or the plain text editor. I released the library to the community, and be necessity it is licensed under the GPL.

Along the way, others have used the library in their plugins. One of the people that has used the library is Oliver Seidel for his cforms plugin. Unfortunately, Oliver has come under fire recently because someone pointed out that his plugin is not GPL-licensed, and as such has rightfully been removed from the WordPress.org plugin repository.

I commented on King Rat's site that if the cforms plugin used my GPL library, then it must be released under GPL. In response to that comment, I have received the following email from the author of the cforms plugin:

I don't have an issue with users not showing my credit line underneath their forms, there are in fact 0-cost options to remove it. Even without loosing the ajax feature.

Whether or nor GPL has never been an issue to me, I in fact encouraged people to change the source code and gave tips and examples.
I simply didn't approve of the fact that people would use my work, remove the credits and resell to make profit.
Being a developer I think you understand.

With that said, I will remove your code immediately, per your wish.

If you don't approve of people removing the credits and selling your plugin, then you should really market your free plugin better, which would make it easier for users to choose your free option over someone's for-pay version of your work. Surely not releasing the plugin as GPL, therefore making it unavailable via the WordPress.org plugin repository, makes it harder for people to find you and your services. Face it, you're just shooting yourself in the foot -- the people who don't want to pay to remove your link are just going to remove it anyway. The people who want to redistribute your plugin (which doesn't have any license file in it, and so one would assume it's GPL based on it's use of GPL source and relationship with WordPress) are simply going to do it anyway, whether you think it's legal or not. You're just losing all of the incoming links via exclusion from the directory and bad publicity because of your decision.

Regardless, having reviewed the plugin, there are other snippets of code that are surely derivatives of existing GPL code. It would be very difficult, even if the buttonsnap library was removed, to say that the plugin used no other GPL code. I'm sure that the author will disagree, but it would be much simpler to properly license the plugin as GPL, put it back in the directory, keep all of the extant source, and reap the benefits.

This is one of those weird cases where giving your code away is just more profitable than restricting access to it.

It's hard to make headway against the "leading brand" without showing exactly what sets you apart from them; what you do better. I think that Habari needs and can provide many examples of how we've taking what everyone looks toward - probably most rightly - as the "standard" in blog software, and done something radically better. This is one example that stands out firmly in my mind.

I am not the only person who has noticed that WordPress is released under the GNU General Public License. In the license, it very plainly states:

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

The only conclusion is that if your theme executes functions that are provided by WordPress, then your theme is indelibly connected to WordPress, and must itself be made available under the same terms as WordPress.

Of course, the howling cries of designers begin here. "How can a theme I design be restricted by a license on some other software?" The answer is obvious. Your theme doesn't run without that particular other software, and so to make legal use of the functions within that software you must abide by the terms of the license. Abiding by the terms of the license means that if you release your theme, then your theme must also be GPL-licensed. It's straightforward, simple.

The consequence of this is that when you sell your theme (which you are perfectly entitled to do even if it is GPL-licensed), then whoever buys it is granted permission to use it under that license. This includes giving it away for free, or even selling it themselves! So you had better charge a lot for that first theme download.

This bothers theme developers more than plugin developers, because it seems nonsensical that your graphic design should fall under this license when you're just using a few lines of GPL code. But if you choose to include GPL calls in your theme, like the_title() or the_content(), then your whole theme becomes tainted by the GNU GPL, and you're stuck. With plugins, the problem is even more obvious. Without the calls to register WordPress hooks, you can't even create a working plugin for WordPress.

This is not an unfamilar situation even in other fields. With video games, game manufacturers pay licensing fees to the console manufacturers before they're allowed to sell a product that runs on their systems. If you want to write a game for the Wii, making use of its components, and release it legally, you must pay a fee to Nintendo. Just like Nintendo applies a requirement to produce Wii games, WordPress (and any software that uses GPL) applies a requirement to supplementary modules like plugins or themes. The requirement is not money, but simply that your module be released under the same terms as WordPress.

The GNU GPL FAQ says it pretty clearly (emphasis mine):

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

Think this doesn't apply to WordPress? Think maybe the words "dynamically link" don't bind? Even Matt thinks they do. He's completely correct.

Another way this is evidenced as absolutely being true is that there are other open source licenses that do not similarly taint ancillary works. And this is the one way I was talking about in which Habari slaughters WordPress.

Habari is released under the Apache Software License. The ASL makes no such restrictions for released works. In fact, it specifically says that the ASL does not apply to works that merely link to the original:

Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

It's really the flavor of the licenses that needs to be taken into account. Understanding what the aims of the two licenses are brings into the light why they differ so much.

The GPL was designed with the intent that free software should remain free; the intent that anyone who benefits from the use of that free software should also contribute their work back to the community of free software users. It's a noble goal, growing the open source ecosystem. You can read this into the FSF's almost Marxist propaganda.

Of course it's correct that not all software that is "open source" is free, but applying a license to your software that removes the freedom of developers to license their ancillary software (themes and plugins) as they see fit doesn't seem like it holds so high those ideals of freedom, does it?

The ASL seeks to apply a license that protects the original work and allows a vibrant ecosystem of both free and commercial interests to take part. Just as free and open alternatives to pretty much any commercial software you can think of have arisen over the years, the ASL will allow the same behavior to build a thriving community for Habari users.

People have asked countless times why Habari is not GPL. It limits what libraries we can include because including GPL code in Habari's core code would taint Habari and require that we release it under the GPL. But we're insistent. We want our themers to have the right to charge for their hard work. We want a rich ecosystem of themes and plugins where market competition - not measured simply in money charged, but in who can make the best modules, free or not - dictates the flow of interest. I find it very hard to believe that if a popular plugin or theme was sold for $50 we'd see no free look-alikes released within days.

This issue is crazy because there are hundreds of themes out there whose authors have slapped CC licenses on them or included stipulations that their affiliate links can't be removed. The former is a failure to comply with the WordPress license and the latter is specifically what the GPL is meant to prevent!

So that's it. Before you even get into the technical merits of the platforms, think about the license, especially if you're a theme developer. Slapping a Creative Commons license on your theme will work just fine for Habari. Doing it for WordPress is a violation of their license.

Mark Jaquith is on stage at blogOrlando presenting WordPress, answering questions. It's nice to have a dev doing a presentation on the east coast. Very personable guy.

I encourage you other bloggers to get out and meet some of the folks that are involved in you software's development. Everyone's really approachable, and sometimes it's nice to get out from behind the impersonal communication of the mailing list to get a feel for what people are really thinking.

It's been since October with these Habari people, and I'm totally through. It's not worth it any more.

Day after ceaseless day, the agony of having decisions by committee... It's finally gotten the best of me. I thought I could handle it, but it's just not working out.

The latest straw to break this camel's back is the rush to release the Developer Review. I'm not sure what the all-fired hurry is to release software that is obviously not ready for prime time. Nevermind that we could have released at the end of January had we not wasted all of our time bickering over logos, default themes, HTML vs XHTML, and other irrelevant claptrap. 100+ messages about whether Habari should use HTML or XHTML. I mean, is that really necessary?

People have questioned whether the team could really pull off the release, and I told them, "No, no, we've got a great team. We'll release something soon." And I said that every day for months, and nothing happened. And then, out of the blue, they want to release this codeset? Forget it!

Well, clearly, I can't use WordPress any more, and I can't use Habari, so my only other option is to go it alone. So, here's my big news...

I've been working on a separate project for a few weeks now, but I haven't said anything because I hadn't really committed to it. But I've finally had enough, and I'm ready to announce it and maybe throw off those Habarians' developer release. My solution is more robust than Habari simply because I've not had to put up with the committee approval on every decision.

I've gotten a couple of folks to fly my banner, including skippy, and we've set up more support for our users in two weeks than Habari has even considered since October.

So, I'm kind of sad to see Habari go, but I'm glad to be rid of the bureaucracy. I hope people are as welcoming to ForkPress as they might have been to poor, doomed Habari.

Greetings, authors of blog-posting desktop clients! This post is for you!

Actually, this post is about you. I've spent the past four hours trying to implement Atom Publishing Protocol. Actually, it's been days longer than that as I've been implementing and re-implementing accoring to the various documentation I've found online, but I've spent the past four hours just trying to get Ecto to work with my APP server code, and now I'm flat-out angry. It's not just Ecto, and I'm not sure that I should only blame the Atom architects either, so let me explain my issues.

I'm trying to implement a lot of the Atom Publishing Protocol as a server. I want to be able to list blog entries, update them, and create new ones. I have written my Atom implementation to the most recent spec, and when I access the entrypoints using raw Telnet and HTTP headers over port 80, I get the appropriate responses back from my server according to the spec.

This seems great, but this is not the end of the battle -- The so-called "Atom clients" I've been able to find just don't seem to support the spec.

Let me start with some basic issues. Whether these are borne from problems with the spec itself or from the clients that attempt to implement it, we'll have to figure out somehow.

Atom has this thing called introspection that allows you to essentially ask a server what Atom information it can provide, and where you can go to get it. It's a pretty simple XML format, much simpler than the Atom collection/entry format itself, but it gets the job done.

The problem? Everyone seems to want it to look a different way. Maybe there isn't an final version of this structure, but it seems like for something so simple, you could have settled on something by now.

Be that as it may, there are some more official-looking introspection format documents that seem to agree, so I've used those. They're dated recently, and actually appear to me to work better than prior versions I've found. For example, Six Apart's Atom introspection format looks like junk.

Ok, so say we have this introspection document at all. Your client tool needs to use it. If your software asks for an Atom endpoint, you need to be asking for the introspection URL. I know that it's a big word, but let's eliminate that confusion right now, and make people learn it.

Either that, or you need to accept the collection (feed) URL and the introspection URL as input. But be aware: Some sites will have more than one collection stored, and your users may want access to all of them, so you should probably get the whole list all at once, don't you think? Use the introspection URL for this. It's handy.

RSD. Ok, if you're going to need Really Simple Discovery, then the API Link needs to point to, yes, the introspection URL! But this is just a nitpicky point compared to the one I will make next.

I know you're trying to make it easy by allowing your users to select the tool (blogging software) they are using in order to select the most appropriate API. I applaud your effort to make it easy on your users. But here's the thing...

I want Atom support. I do not want "Blogger" support, even if Blogger uses Atom. Why? Because for some reason, my Atom is not exactly like you expect Blogger's Atom to be (for example, it's not on Blogger's server), and even though it works exactly like it, you're not able to read it for some reason.

Ok, let's just skip to the fundamental problems here, because I'm sure you don't want to hear me rant about any tool in specific.

What I've been doing: I've essentially got a packet sniffer watching the requests that your client is making to my server in an attempt to figure out how I can appease it. Seriously, I'm that desperate as to have stooped to this kludgey level. That only tells me part of the picture, though.

The packet sniffing tells me where you're looking, but not what you're looking for. So if you require me to enter the Atom collection URL as an endpoint, but I enter the introspection URL, I see the request, but you fail to understand it. On the off chance you accept the introspection URL and that's what I provide, then I should see you make some additional requests as you read the introspection document.

But I'm tired of trying to figure it all out.

I keep thinking that if you were following the spec to the letter, then I could just write my code to conform to the spec and it would all "just work". But so far, I've been completely unable to point to any Atom client and say, "Here is a reference client. If I do something to my code and it can't be read by this client, then it's my APP implementation that's broken, not the clients."

Since nobody can seem to figure out how they want to get me to input the Atom URL (introspection? collection? entry? RSD?), I'm at a loss when trying to build a new APP server.

Here's what I would like to happen: Please publish samples of the formats that you read. Please describe the URL that you accept in your configuration, and what type of document it should point to. If you are using RSD, please describe what the API should say to point to an Atom introspection URL, or the colletion URL, and whether you support one or both. Please list the extensions to the base Atom format that you accept and how well you handle them.

The "draft" tag is another good example of practicality being thrown out for academics. It's not very clearly defined what an APP server should do with this tag. But most clients (and it's odd that this is so common when the basic entrypoint URLs are so different between clients) use true or false as values in the draft tag. If you were posting to WordPress, the draft tag is completely insufficient. WordPress does not have only two states. Why are you even using this tag? Are you even using this tag?

At this point, I just want to get things to work, and I would like things to work with the API that I'm writing to conform with the RFC. I know it's still changing, but it's not changing so much that the tools should fail too badly between versions.

This is the same madness that went on with XMLRPC and the original Blogger API/Metaweblog API, etc. You shouldn't treat Atom this same way. Atom is not XMLRPC. You shouldn't need to force users to select the software they are posting to in order to anticipate what their feeds will contain. The Atom feed and entry document formats are fairly flexible in that respect. Embrace the future.

Wanna talk about it? Maybe I've got something wrong here. Enlighten me. Please.