⇥ PHP 5.2 support ends just as its adoption begins

In case you missed it, the PHP team has just released 5.2.14, which effectively ends active support for the 5.2 branch¹:

This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance.

The logic behind this decision is… puzzling.

Several large projects—WordPress and Drupal among them—recently announced that they intend to push support for 5.2 into their products with their next major release. For example, Drupal 7 will accept 5.2 features, and the WP folks are just working on EOL’ing their support for PHP 4.

This means that a large number of people are just beginning learning, using and stress-testing PHP 5.2. Remember—these projects have very large user bases, so even moving a small percentage of adopters over to a different platform means a big shift. Perhaps—just perhaps—it might be better to reconsider canning 5.2. If, from a technical perspective, the move from 5.2 to 5.3 is an easy one, there is a huge psychological barrier to finally adopting 5.2 only to have it yanked from under your feet.

The real issue at hand, however, is the fact that these large user communities are not engaged in the PHP world, and vice-versa. Ignoring the hundreds of thousands of Drupal and WordPress integrators and developers is bad for both PHP and for those products; we should, instead, try our best to open a dialogue between all the communities that are centred around PHP and ensure that everyone’s interests are properly represented.

This is not to say that the fact that WP has only now decided to move to PHP 5.2 should necessarily affect the progress of PHP, nor that the PHP developers should take a “we don’t need you” attitude toward projects that are based on the language. Ultimately, it’s up to these projects if they want to actively contribute back to PHP or not, and that is the only way for them to effectively affect the development of the language itself.

However, PHP development is too unevenly connected to downstream adopters. Some—particularly framework makers—have an unusually high level of participation in deciding how PHP evolves, and that needs to change.

At least year’s WDC, a small conference organized by Microsoft, I made this very same point and managed to bring a room full of developers into complete disarray in less than five minutes—which means that, in addition to the fact that my ability to drive a bunch of people up the wall in no time flat has not changed over the years, there is plenty to talk about.

[Update: the latest 5.2.x release is 5.2.14, not 5.2.11 as I originally stated. Thanks to Ilia for pointing that out.]

Headway Themes is now licensed under the GPL… uhm, no, wait. It isn’t. Well, sorta.

Grant Griffiths on split-licensing the PHP code of his themes under the GPL and the images/CSS/JS files under a proprietary license:

The split GPL license still allows us to retain enough teeth that we can bite someone in the butt if they violate our own license for Headway.

I fear that Grant hasn’t quite thought this whole affair through. But let’s take a look at the Headway ToS themselves:

All WordPress themes produced by Headway Themes are released under the GPL version 2.0 license (http://www.gnu.org/licenses/gpl-2.0.html GNU/GPLv2). Specifically, the PHP code portions are distributed under the GPL version 2.0 license.

Are “all themes” released under the GPL or the PHP portions? I think the intent of the author are fairly clear, but this language introduces contradiction in a legal document—not a good start. You’ve just given a prepared attorney a way to show that your language is ambiguous and a reasonable third party could interpret it in a way other than the one you claim is the correct one. And believe me, they’ll latch on to this like the Shuttle on the Space Station.

The Headway Themes Proprietary Use License is a GPL compatible license…

Who has decided that it’s compatible? What happens if a court should decide that it isn’t?

You are authorized to make any necessary modification(s) to Headway Themes to fit your purposes. You may not however redistribute or release modifications as GPL or otherwise.

Wait, what? You get to release under the GPL but I can’t? Sorry, but the GPL says the exact opposite:

4.  You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License.

Incidentally, you also don’t get to choose which pieces of the GPL your code is subject to:

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License.

See how confusing things get? And that’s without even counting the fact that a clever lawyer may well point out that the CSS, JS and image files are derivative of the theme because they cannot be used meaningfully outside of it (much like GPL proponents claim that the theme itself cannot be used meaningfully without the underlying WP code).

I hope that Grant got legal advice… uh-oh:

While I know Matt would rather we would have gone 100% GPL, we felt more comfortable with a split GPL license.  We actually modeled our license which we have included in a revised TOS after what Jason has at Press75.  Below, you will see the exact language we now have which according to Matt Mullenweg is “100% legal.”

These people are playing with fire.

⇥ A note on comments on T·A·B

This blog doesn’t get a lot of comments, which suits me fine—I prefer quality of discussion over quantity of words.

However, comments are moderated and, inevitably, the following happens:

1. I publish a post (usually on PHP or OSS)
2. Someone leaves a comment
3. The comment is placed in the moderation queue
4. The author immediately posts another comment, which also ends up in the moderation queue, telling me off for moderating comments
5. Lather, rinse, repeat.

The reason why moderation is on is simply to weed out spam. Generally speaking, I let any comment through, regardless of whether they agree with what I say or not—if I only wanted people to agree with me, I wouldn’t allow comments to start with. In fact, the system is set so that, unless I decide otherwise, once a user’s first comment has been allowed, future comments will be published without any further moderation. Basically, I just want to make sure you’re not trying to sell me Viagra. And who knows, in twenty years I may change that rule, too.

So if you post a comment and it doesn’t immediately show up, please refrain from writing me and accusing me of trying to silence your Very Important Opinion™. I may be simply busy, on the phone, out, or maybe I’m just sitting on the can and need a little time to myself. Remember, my house, my rules. Thank you.

⇥ WordPress, the GPL and cherries on top

The WordPress community is abuzz with news that the WP Foundation has essentially gone to war with the makers of the Thesis WP theme. The substance of the argument, as I understand it, is that the makers of WordPress claim that themes, since they rely on WP’s GPL’ed code to run, must be covered by the GPL as well because they are derivative works. Thesis, on the other hand, is distributed under a commercial license, therefore violating this tenet.

I have, in the past, expressed my dislike for the GPL, which, inevitably, colours my “legal” opinion on the matter—though, I assure you, this post is not about the GPL and I have absolutely no intention on engaging on a debate on the license. Write me or comment on the GPL and I will simply not care—you’ve been warned.

Legal opinions abound

As always when a legal matter is involved, everyone and their dog is giving an opinion. Matt went and asked the Software Freedom Law Center to officially render theirs, and they came through, true to their name, with a nine-paragraph letter that illustrates how themes are, in fact, derivative works covered the GPL.

Arguments on the other side of the fence typically focus on the fact that themes are not derivative works, or because of the fair-use doctrine¹.

Personally, I find the SFLC’s argument very weak from a technical standpoint—particularly in the citation of the use of include (which is not a function²) as justification for their claim that themes are derivative works. Includes are designed specifically to create interoperability between different programs—in the world of PHP, where there is no concept of “binary,” they are the equivalent of dynamic linking.

One would have to physically copy code between projects, or physically include files from another project in a new work, in order to create a derivative work in this context, and to claim that themes do this is simply ridiculous because WordPress is designed to be expanded in precisely the way that themes are developed. To impose the GPL on themes—unlike, say, imposing it on a fork of WP itself, which would be perfectly logical—is to restrict a developer’s ability to interact with a particular piece of software and this would constitute an artificial limitation on a developer’s ability to interact with WordPress, which could give grounds to a fair-use claim.

Obviously, the SFLC probably believes that any form of linking or reliance of a piece of software upon another creates a derivative work, and they may well be right. Larry Rosen of the OSI believes that the determination of what constitutes a derivative work in the context of software should also take into account the element of intent—that is, whether the author of the work in question wrote their software in a specific way because they were aware of and attempted to circumvent the application of a license to derivative works. If he’s right, building a theme cannot possibly constitute the creation of a derivative work—again, WordPress is designed to be expanded, and it cannot taint downstream work that is not a direct derivation of itself, much like Linux cannot impose the GPL on commercial drivers or on commercial products built on it³).

Legal opinions are meaningless

Here’s the kicker: what I think is meaningless. What Matt thinks is equally meaningless. And what the SFLC means is most meaningless of all.

I am not a lawyer, and neither is Matt. The SFLC, which has an obvious bias towards the enforcement of the GPL⁴ is made up of lawyers and they, more than anyone else, should have made sure to cover their collective ass and Matt’s by explicitly pointing out that there is but one legal opinion that matters: that of a judge and jury.

Unless the WP Foundation ever takes the makers of Thesis to court, therefore, all these “legal opinions” have absolutely no legal value whatsoever. They are nothing more than a form of posturing and an exercise in public relations in the world of court opinion, to cite Adlai Stevenson.

And that is what puzzles me, because from a business and strategic perspective, the WP Foundation has nothing to gain from this exercise. Let’s look at the possible outcomes:

• The WPF could sue and lose, and look like idiots who spend their time litigating rather than innovating (which is what they should stick with).
• The WPF could sue and win—and still look like idiots because the implications of themes being covered by the GPL would have an enormously chilling effect on the professional WordPress community. More than that, they would have to sue every infringer, or risk looking like they are pursuing some secret Matt-centric agenda.
• The WPF could do nothing and look like warmongering zealots—belligerent only in words, all they would achieve is a polarization and eventual schism of the community between those who believe that software is free, and those who believe that GPL is about freedom.

The way I see it, there is no possible outcome of this diatribe that could benefit the WPF, which is why I am puzzled.

Incidentally, you may be wondering why I think that GPL’ing the themes will be problematic for the entire community. Well, what I am wondering is: how will it affect the thousands of freelancers who create custom one-off themes for clients?

This is a big problem, because the GPL does not attach itself to a derivative work until you distribute it—this is why, for example, you don’t need to release GPL code if you hold copyright and use it for your internal purposes. If you are a freelancer, however, you normally hold copyright on a theme you develop but don’t use it for your own purposes—you give it to a client under some sort of license… which is exactly what amounts to distribution.

Unless you assign the copyright in your work to the client (and why would you want to? You are a freelancer, not an employee, and giving up copyright in a particular work is tantamount to giving up your trade secrets), you are, effectively, distributing the theme you developed, which now becomes covered by the GPL. Should the theme somehow include code that is owned by the client—for example to interface to one of their internal systems—that code might well be covered by the GPL, too, thus opening a can of worms of elephantine proportions: the client has gone from ordering a bunch of templates for its website to having to open-source and distribute its own proprietary code. If I were said client, I’d probably be switching to another CMS right now.

Naturally, the WPF could say that it won’t pursue those cases, but they don’t get to choose what the GPL attaches itself to or not—remember, the GPL is not GPL’ed itself: you can’t modify it, you can only use it or not use it. And the GPL says that derivative works must also be released under the GPL period.

So, what the WPF thinks the GPL applies to and what it actually applies to could be two completely different things. Therefore, while you may not get sued by the WPF for writing a proprietary theme specifically for a client, the GPL may still apply to it and all the code that is part of it—which means that, if your theme uses a client’s proprietary code, you’re both in potentially big, big trouble.

So, what should the WPF do?

First, it should back off; this fight isn’t helping anyone—least of all the WPF itself.

Second, it should draw very clear lines in the sand:

1. WP is released under the GPL, and so has to be any direct contribution to core or fork thereof.
2. Themes and plugins are not derivative works and are not covered by the GPL and can be released under commercial licenses.
3. Themes and plugins distributed by wp.org must be released under a GPL.

This creates a fair and balanced set of clear guidelines for everyone to follow: if you want the exposure of wp.org—for example to increase your reputation and credibility as a WP expert freelancer—you have to release your code under an open-source license. If you want to distribute your code commercially, the burden of promotion and public relations is on you since the community doesn’t benefit directly from your work.

Now, I anticipate that some will simply say that, under my proposal, nothing would prevent commercial vendors from circumventing the fact that core is GPL and simply using plugins to effectively fork WP without forking it. Well, nothing has prevented them from doing that until now⁵, so how would this be different, other than giving developers and freelancers the confidence that the WPF board isn’t going to wake up on the wrong side of the bed one day and start suing people left and right?

An SSH server written in PHP? Why, yes, you can.

Mark Karpeles

Last time I already tried to prove PHP can do anything when it comes to network protocols by implementing a DNS server. This time I’m doing it again with a server-side implementation of the SSH2 protocol.

Leaving aside for a moment whether one should write an SSH (or DNS) server in PHP, the fact that one can is pretty cool.

Should we get ready to go nuts over cookies?

The Register on a new EU law, due to go into effect next year, that requires sites to ask for consent prior to storing cookies on a user’s browser:

An exception exists where the cookie is “strictly necessary” for the provision of a service “explicitly requested” by the user – so cookies can take a user from a product page to a checkout without the need for consent. Other cookies will require prior consent, though, and the law must be implemented in member states by May 2011.

So, how do you define “strictly necessary?” If your PHP installation has sessions on by default even though you don’t use them, is that a violation of the law? What if you use Google Analytics on your site? Should you, or Google, request permission?

If any of my European friends want to chime in with what this means, I’d welcome the information. Please try keeping the swearing down to a minimum, if you can…

⇥ NoSQL, round holes and square pegs

Ivo Jansch:

In last year’s conference, there was a talk on CouchDB, introducing a ‘NoSQL’ database as a response to relational databases often being a hassle when web data needs to be stored and manipulated. This year, we could see that NoSQL is catching on and becoming more mainstream. Matthew Weier O’Phinney, project manager of the Zend Framework, discussed NoSQL in detail, and MongoDB (Another NoSQL database) was mentioned in a couple of talks. NoSQL is definitely something to have a look at, and it might be useful even in existing projects. More info can be found on the Wikipedia page.

We saw the same at this year’s TEK·X conference. More and more people are realizing that working with SQL is, at least in some cases, an exercise in fitting a square peg to a round hole; NoSQL, however, still presents a movement “on the rebound” from SQL, so that they seem to be trying to round out a lot of pegs that maybe don’t need to be. On the other hand, some uses of RDBMSs are a little ridiculous. If you’re storing documents inside a MySQL database, you’re not using the best tool for the job.

However, the NoSQL community still has a long road ahead of itself, with many issues that need resolving. Right now, fragmentation—the result of the relative youth of these systems¹—makes the adoption of any one system risky, while the lack of a common data querying language (or even vocabulary) makes it difficult to future-proof any project based on a document-oriented database system.

Eventually, I suspect that we’ll reach some sort of equilibrium in which one of the document-oriented systems will prevail and become as ubiquitous as, say, MySQL has become, or, at least, some sort of bottom-of-the-barrel standard like SQL will become common among the various implementations, so that developers will be able to switch between systems more easily and focus on the differences that make one more appropriate than the others in a particular development scenario. Of course, the various NoSQL leads could simply attempt to get together and find some common ground that can help them grow more organically and cohesively—but this is software… so I won’t be holding my breath.

⇥ Software, APIs and all the king’s men

These days, it’s a rare occurrence that a web-based application is only ever going to remain web-based. What starts as a website usually ends up taking on a life of its own and expanding into mobile apps, GUI-based interfaces, and so on.

Unfortunately, the vast majority of websites are still built with the old “web-only” approach in mind—which, in today’s world, introduces by-design limitations in what your software can do: when the client comes calling and asking for, say, an iPhone version of your application, or a client-based management console built in Flex and AIR, mixing your presentation and business-logic layer is going to become a very expensive decision.

To be sure, even if you—or, more likely, someone before you—has made the decision of designing “one big ball of code” from which you now have the unenviable task of extracting a viable API, there are solutions that can help make that process easier: for example, my good friends at echolibre make FRAPI, a product that makes it possible to “wrap” a web-based API around an existing codebase or data source, thus making it relatively painless to breathe new life into an old design.

Building from the API

On the other hand, if you’re starting a new project today, there is absolutely no good reason why you shouldn’t begin your design with an API—in fact, you should make your web application a client of the API to make sure that you do not inadvertently build functionality in the wrong layer of your application.

This is exactly how we’ve built most of php|architect (something that I have, at some point or other, already explained in this blog): we have a “service layer” that is physically separate from our many application layers—in fact, it now resides on its own server for performance reasons and to isolate our frontend, where we run software we have no direct control over, like WordPress, from our backend.

We draw a number of advantages from this approach: first, we never duplicate code; if a function is used in more than one place, I assure you that it’s always performed by the same script. It might look and behave differently based on a number of different reasons, such as ACLs and interface, but the underlying code is always the same.

Second, we can build as many different frontends as we need. At one point or another, we’ve had a website, iPhone app, iPhone website, various conferences websites and our Flex-based management console all running from the same service-layer codebase. We have even built specialty services for some of our partners who need (for example) to sign PDF files—and, in all cases, not a single line of wasted code was written for the backend.

Third, our code is safer. This is not because we are necessarily better at writing code, but because we have a single system to keep secure and because any problem only ever needs to be fixed in one place.

APIs should be platform agnostic

Developers seem to confuse APIs with the protocol through which they are exposed. If you tie your API to a particular protocol—be it REST, SOAP or whatever else, you are needlessly limiting your options. The API is simply the interface between your application (the backend in this case) and whatever frontend happens to be using it. In many ways, if you think of your backend as its own application, the API is essentially the controller and the protocol through which it is accessed is the view.

If you keep API and access layer separate, you can easily provide support for multiple entry points, which means that whoever needs to develop against your code will have the option of choosing the best solution for their needs. For example, you can implement a RESTful interface based on JSON for AJAX, a SOAP interface for web applications and, say, an AMF interface for Flash/Flex clients.

Control is the key

Obviously, multiple entry points mean multiple potentially vulnerable points as well. That’s why the best API implementations ensure that access control resides with the API, and not the entry point. If you delegate that task to the entry points themselves, then you will always have to make sure that their support for security is always in sync.

For example, AMFPHP supports authentication and ACLs in the method table for a given service—a great way to take advantage of Flash’s built-in access management and error reporting. On the other hand, it pays to build your own ACL system and then integrate AMFPHP’s with it, because you will then be able to support different entry points without having to rewrite the access layer, too

At the end of the day, whatever the approach you take, building API-centric systems is a clear winner—particularly if you ever want third parties to connect to and use your data. Even if you ever only build for your internal use, an API layer comes with many advantages that will make your life easier in the long run.

The include() include_once() performance debate

From SeeIt Consulting:

The conventional wisdom always said that PHP’s include()/require() was quicker than include_once()/require_once(), but recently I came across an interesting post by Arin Sarkissian which suggests otherwise.

I really wish the conventional wisdom said that we need to stop worrying about these senseless micro-optimizations. There are so many things that you need to worry about before having to deal with something at this level that the vast majority of sites will never draw any real benefit from it—and those that can probably already have.

YouTube – Google I/O 2010 – Go Programming

Rob Pike (who could really use someone behind his back holding his legs steady—he was making me nauseous) and Russ Cox showing the Go language at Google IO:

This session will illustrate how programming in Go differs from other languages through a set of examples demonstrating features particular to Go. These include concurrency, embedded types, methods on any type, and program construction using interfaces.

I really don’t know what to make of it. On the surface, it looks like a solution looking for a problem—today’s languages are a relatively unimportant part of the platforms they are part of; developers look for richness of functionality and rapidity of development more than the nuances of the language itself, which is why PHP is so popular despite being as amorphous as glass.

On the other hand, there is something to be said for elegant languages, though I’m not sold on the type handling.