Your mashup is probably legal.
Your mashup is probably sound.
Your mashup is probably legal,
So pass all that data around!

Stuff here
Stuff there
And something mashed up in between (be-tween!)
Stuff here
Stuff there
And something mashed up in between

Your mashup is probably legal;
You could monetize it as well!
But though I contend it’s all legal,
Remember I-A-N-A-L!

[Repeat chorus]

Drupal.org have produced a Licensing FAQ to explain some of the subtler aspects of licensing under the GPL. The questions themselves are Drupal-oriented, but the FAQ itself has been prepared by the SFLC, an independent body, so the answers are broader than that.

I’ve noticed from the slightly confused sidelines that Drupalers have been niggling away at these issues for ages. Their heated exchanges and occasional quarrels are the fuel that has kept this wagon moving, and they’ve finally rolled it into town with a GPL-in-practice primer that’s worth reading, whatever you’re working on, and especially if you’re integrating with web services or third-party libraries. Well done to all involved.

A few banks now ask you for the same three digits, if you guess wrongly. Their idea is that to do otherwise, and just ask for a different three random digits, would make the site look like a phishing site, which is debatable. But by asking repeatedly for the same digits, the banks immediately provide keyloggers with a method of cracking into your account. Every time you get your login wrong once, keylogging software can attempt an automated login to your account in between your two attempts, making a note of the HTML which gives them the position of your numbers. It can then wait for you to get the code right, and it immediately has three of your numbers and their positions.

After around four or five iterations of incorrect-login/keylogger-login/correct-login, the software has pretty much your entire code and can siphon everything out of your accounts. The iterations may be picked up by stochastic anti-fraud technologies at the bank; they might not, of course.

More detail is available in a paper recently published in Computers & Security (preprint). From the URL of the preprint, the customers of one particular bank might want check it out.

(Hat tip to my father-in-law.)

When I interact with a typical web service, my computer moves through a certain set of steps in response to a piece of proprietary software. As an example, consider me proceeding through the checkout at Amazon: there is a set of steps that my browser must perform in order for me to access this service. There’s some subtle, ephemeral, proprietary “workflow” which Amazon instructs my browser, over time, to follow.

It doesn’t consist so much of a set of zeroes and ones on my hard drive, but as a sum total of the configuration of my computer, the content of a set of HTML and scripting files that are sent to me, my input and that all-important server-side black box.

However briefly, there is a proprietary component to my experience with the tool (this “workflow” that’s distributed across client, network and server). I can’t access this component, yet it dictates in part what my computer does for its duration. I can’t copy this component without Amazon’s say so (if I open a browser on another machine then that machine is in a similar thrall to the workflow). I can’t modify this workflow, and approve the contents of my basket before submitting my credit-card details, unless Amazon specifically permits that. I can’t modify it to accept payments from a new credit-card company, even if I knew how.

If Amazon introduced a bug in their proprietary software, which dynamically generated Javascript (however open-source the resultant file) that took down my browser (and maybe even my computer depending on my OS), whenever I tried to buy a copy of “Free as in Freedom”, then how is that not restricting me? What if Amazon were the only stockists of Stallman’s books—I appreciate that might be stretching the bounds of credibility somewhat!—how can I get a copy if my only buying mechanism is disabled by a component I can’t change? How is this not restricting my freedom?

O’Reilly quotes Stallman as saying in a rebuttal to the very existence of the problem posed by proprietary web services:

“If the program is running on somebody else’s computer, the issue doesn’t arise. Am I allowed to copy the program that Amazon has on it’s computer? Well, I can’t, I don’t have that program at all, so it doesn’t put me in a morally compromised position.”

Yet some of the program is running, somehow, insidiously via a contextual combination of technologies, in a virtual machine, on my computer. There is a copy of a facet of it on my machine, and I can’t touch that copy. Here is software which is dictating what my machine does in response to my input. The quintessence of this software is proprietary and closed. Whether the cable separating it from my CPU is ethernet or IDE might once have been a good rule of thumb, but it is surely no longer the point these days.

Not being immediately aware of any such alternative (microformats having evolved from a number of web practitioners’ frustrated wishes to add extra semantics to their XHTML), I was a bit surprised to read:

The only reason I can imagine you might choose a microformat over a macroformat is because macroformats are invalid XHTML, but so what? XML doesn’t have to be valid! That’s a deliberate design decision in XML. Some say invalidity is the real revolution in XML. It’s what XML brings to the table that SGML never had.

Well. This is true, in a sense, but not really pertinent to the actual problem that microformats are intended to solve. SGML didn’t “have” to be valid, if we’re talking pragmata (you say prag-may-ta). Millions of webpages out there had the most godawful pseudo-HTML on them, and browsers muddled along reasonably well. But that wasn’t enough. Our data didn’t soar. Our browsers didn’t leap, nor did they bound.

There were a number of motivations behind establishing DTDs for HTML, let alone for XHTML, and one important one was being able to hand a webpage to someone who wants or needs to be able to maintain it in good HTML, and give them an editor that could enforce the standards, either by beeping at them (Sean McGrath might turn in his blog at that one) or by quietly fudging good HTML in the background without telling them. If you start putting arbitrary tags in, you break the silent checks that mean non-technical people can actually write webpages.

Many of the clients I work with have government or charitable funding, and a proviso of this funding is that their pages be accessible to web users with special needs, and to be strongly future-proofed in the light of past mistakes. In part for the reasons above, but generally because it’s safest to enforce as strongly as possible without affecting the primary goal of the medium, accessibility standards and funding bodies’ definitions of “future-proofing” tend to require pages to be valid XHTML1.0 . It’s fine for someone technical to say to themselves “this is valid XHTML1.0, except for the bit I’m putting in now”, but there’s no guarantee that the next person to touch that page will understand or care. Or the next person. Or the next person. Didn’t we… didn’t we tackle the problem of markup rot once already?

Adding your own tags to XHTML is something that Elliotte Rusty Harold can do with aplomb, and probably ought to because he knows what he’s doing. And if he’s got the spare time to maintain every site on the web on their owners’ behalf, to ensure we don’t return to the tag soup of HTML that one couldn’t even begin to validate, then he’s welcome to give it a go. In the mean time you might want to campaign for an exception to current UK disability law, or at any rate almost every organisation’s interpretation of it, in the case of sites maintained by Elliotte Rusty Harold—I’ll even sign the petition if there’s one passed round—but I can’t see it gaining much traction.

There’s a pragmatic solution to the validation problem, though. We could reprogram our XHTML validation engines to ignore specific blocks of markup based on particular criteria, say a reserved attribute on particular elements that means the content is checked for well-formedness—CDATA elements won’t do, because they can contain absolutely anything, and you lose the power of XML—but ignored by DTD and schema validation. Might I suggest <div class=”xhtml-ignore”/>…? It’s funny, but that particular method rings a bell.