Alastair’s Place

Software development, Cocoa, Objective-C, life. Stuff like that.

San Francisco

For the past week, I’ve been in San Francisco, attending Apple’s World-Wide Developer Conference. The first thing I’d say is that if you’re an Apple developer, WWDC is well worth the fee (and, indeed, the air fare). But more importantly, San Francisco is great. The city is well worth a visit; there is plenty to see during the day, and the restaurants and night-life are brilliant.

If you’re after good restaurants, of those I’ve visted on this trip, Cortez and Ponzu are easily the best. Indeed, our waitress in Ponzu, Jill, deserves a special mention, as the service was excellent. Plus Jill is very pretty :–)

Why DNS E-mail Blacklists Are Bad

I used to think that the DNS e-mail blacklists were a good idea. After all, on the face of it, they seem like they might actually offer a way to combat spam. Certainly, they can reduce the amount of spam you receive—I don't think anyone would disagree with that.

So what don't I like about them? Well, since I started trying to run my own company, to be perfectly honest, DNS blacklists are the bane of my life. Why? Well, small companies tend not to own their own equipment on the 'Net… rather, they tend to use the services of web hosting companies. Coriolis Systems Limited (as well as this website) are using the services of 1 and 1, aka Schlund, who offer cheap and flexible hosting.

Why is this a problem? Well, here’s the rub. Whenever anyone buys anything from the Coriolis Systems website, they are sent an e-mail (actually, in most cases, two e-mails). This e-mail goes via 1&1’s mailservers before going out onto the Internet. But, because 1&1 are a hosting company, and anyone can sign-up to use their equipment, inevitably one or two of those most hateful animals—I am, of course, referring to Internet spammers—signs up with 1&1 every so often. The upshot of this is that some bright spark somewhere adds 1&1’s mailserver to one (or more often several) DNS blacklists, the result being that our customers don’t get their e-mails. What do our customers do? Well, usually, they blame us—after all, they assume that their e-mail system is reliable and that they should receive messages if we send them, not realising that their ISPs have thrown a spanner in the works by making use of DNS blacklists.

OK, you might say, most blacklists let you ask to be removed, and if 1&1 aren’t spam-friendly, then it should be easy enough to get this done, because they’ll kick the spammers off. All of this is true, except that by the time we know that there is a problem, it’s already too late… we already have an irate customer (ironically, it is usually American customers who become most annoyed—I say ironically, as it is largely their brethren that are responsible for the spam problem in the first place).

Anyway, all of this is very irritating. Is it really too much to ask for the maintainers of spam blacklists to adopt a more sensible approach towards shared infrastructure companies like 1&1? At the very least, you might reasonably expect them to use a notify-first policy for such people… that way, blacklist maintainers avoid inconveniencing large numbers of people whose perfectly legitimate e-mail goes missing because of the activities of the occasional spammer (who will be kicked off anyway, once the web hosting service is informed).

Oh, and before anyone goes hunting around and decides that the problem is anything whatsoever to do with open mail relays, you should note that 1&1 use authenticated SMTP, so you do at least know that any mail you get from their servers really came from one of their customers.

Notice: Mis-use of Trackback Pings on This Site for Advertising Is Now Chargeable

I’m fed up with trackback pings linking to sites I don’t care for, so, as of the date of this post:

  1. By sending trackback pings to this weblog, you are agreeing to these terms and conditions.
  2. You acknowledge that this site makes use of resources owned or paid for by Alastair Houghton.
  3. You acknowledge that the facility to accept trackback pings has been provided for the benefit of readers of this weblog and for the benefit of authors of other weblogs making legitimate comment on the content of this blog.
  4. You further acknowledge that this facility is not provided for the benefit of commercial operations, and it is specifically prohibited to use the facility for advertising purposes.
  5. You agree that if you act in breach of item 4, above, you will pay a fee of GBP£1,000 for each and every trackback ping that contains unwanted links and/or text.
  6. Furthermore, you agree that, should any trackback ping contain or link to material of an illegal or pornographic nature, or to an Internet gambling site, you will pay an additional fee of GBP£1,000 for each instance.
  7. Additionally, you agree that you will bear the full cost of recovery of any fees should you default on payment, including but not limited to fees associated with obtaining your legal identity, court fees and associated costs.
  8. Payment is to be made within 30 days. You agree to take sole responsibility for any bank charges payable. Payment details provided upon request. Overdue payments incur interest payable at 10% per calendar month.
  9. Governing law for the purposes of this agreement is the law of England. Conflict of law rules of any jurisdiction shall not apply. Any dispute will be held in an English court as determined by Alastair Houghton and/or his legal representatives.

Computer Implemented Inventions Meeting at the DTI

On Tuesday (the 14th), I attended the meeting on Computer Implemented Inventions set-up by Lord Sainsbury and the Patent Office as a result of the large number of letters they received regarding the new European Directive on the Patentability of Computer Implemented Inventions. The meeting was chaired by Peter Lawrence, the Director of Policy at the Patent Office; also present were Lord Sainsbury, Minister for Science & Innovation; Peter Hayward, a Divisional Director of Patents at the Patent Office; and Steve Probert, a Deputy Director at the Patent Office (who was involved in an interesting and topical discussion on the IEE site).

I wanted to post a summary here of the meeting from my perspective as someone involved in running a small business, particularly in light of the fact that most other such summaries are likely to come from people whose reporting of the issues is not always as accurate as one might wish and has tended at times towards scaremongering (actually, I just read ZDNet UK's article, which is a pretty terrible piece of journalism as it is inaccurate as well as coming across as biased; The Register did somewhat better, although their claim that the current position is based on U.K. case law is not entirely correct—it is based on a combination of EPO and U.K. case law).

The Patent Office also said that they were going to publish a transcript of the meeting on their website, which should be valuable material, provided it isn't taken out of context. As soon as I find it on their site, I'll put a link here. I think two things stick out in my mind from that meeting. The first was that there were sadly (as I expected) a few people who really hadn't thought very hard about the actual issues and came across as ranting—particularly the guy who started by explaining that he was involved in high energy physics and had to be asked four times to get to the point. I also felt that a number of people would have done well to read the text of the Patent Act 1977 from the Patent Office Manual of Patent Practice before attending the meeting, because it outlines the current legal situation and summarises all the relevant case law, which might have helped people to better express what they felt were the difficulties with the law, both as it stands and in the proposed directive.

Second, I think it became apparent that the U.K. Patent Office is actually adopting a fairly sensible position; now, I don't necessarily 100% agree with the position they take (under which some operating system software and other low-level software may be patentable, in effect at least), but at least they are determined to avoid the sort of trivial patents that the FFII and others have been digging up from the archives of the European Patent Office. Actually, given the amount of research that FFII has put in finding patents they don't agree with, I was surprised that I was the only person attending the meeting that had thought to bring some specific, printed, examples with me (or at least, I was the only person that spoke that did so).

The Patent Office representatives also indicated that the stance of the examiners responsible for the EPO's drift towards U.S.-style patentability was not sanctioned by the EPO and that those examiners had been instructed to tighten up their interpretation of the existing law, although they said that they (and indeed the EPO) do not have the power to revoke patents that have already been issued, so any patents that slipped through would need to be challenged in a court.

One other issue that I think is worth clearing up is that of the meaning of “Computer Implemented Invention”. According to Peter Hayward, a patent can only be filed for an invention as a whole, and will not be granted (at least in the U.K.) for pure software. So, for instance, you could file a patent for a computer-controlled jackhammer that would prevent the operator from drilling through their foot, but the patent would only cover the jackhammer as a whole, and not the software within it—a position that I think most sensible people would agree with.

“a patent can only be filed for an invention as a whole, and will not be granted (at least in the U.K.) for pure software”

Now, plainly there are still issues—for instance, under this type of rule it is possible to patent a novel processor cache system involving software for some purpose (even if the main novelty is in the software), and since the software technique involved may be applicable to other similar hardware, the patent may effectively cover the software even if the letter and spirit of the law say that it does not, which I and others don't really agree with, but I must admit that it is difficult to come up with any simple rule for such cases.

Similarly, this is the reason it is possible to patent data compression algorithms and the like—although the patent still covers an invention, for something like data compression the invention might be quite broad and could be held to be applicable in many cases. I don't, incidentally, agree with the EPO view (from the Vicom case, which is where the “technical contribution” criterion originated) that image compression should be patentable because it concerns “the technical quality” of an image, nor would I (personally) be inclined to allow patents claiming a storage or data transmission device with built-in compression (where the major innovation was in the compression technique) because it would seem to preclude all useful applications of the compression algorithm and doesn't really contribute much to the state of the art in either data storage or data transmission. I get the impression that current U.K. Patent Office policy lies somewhere between these two positions; certainly they are not as permissive as the EPO has been in the past.

As for “program claims”, Peter Hayward made the point that a program claim is still subject to the rule that the patent is for an entire invention and not just for a piece of software. So (to use his example), you might be able to patent a process for mass-produced yet individually decorated mugs that relies on software as an integral component of the process. However, assume that you are a company that came up with the idea but just produces the software; in this case, a “program claim” would be appropriate, as it would protect your idea (mass-production of individually decorated mugs which happens to use your software) without requiring you to sue potential customers if they (for instance) bought software overseas to enable the same process.

“a program claim is still subject to the rule that the patent is for an entire invention and not just for a piece of software”

Importantly, this is quite different from the understanding many people seem to have of program claims, which is that they patent the computer software—they don't, they still patent the whole invention, but they change who you can sue for infringement… instead of suing your customers, you can now sue your competitors (remember, patents are supposed to grant monopoly rights, so this makes some sense). I should also say that, like other members of the audience, I don't think the individually decorated mug example is a very good one, except that it is quite easy to understand, which I suspect is why it was chosen.

Other than my feeling somewhat reassured that despite some of the rhetoric from FFII and others, the Patent Office is in fact not engaged in some sort of backdoor legitimisation of software patents, I think four main useful points were raised at the meeting:

  1. We (the developer community) would like to see some sort of definition, or at the very least clear guidance as to what patent examiners should understand by the words “technical contribution” in the context of patents for Computer Implemented Inventions. In particular, our major concern is that the bar has at times been set far too low (especially by the EPO) and that the fact that the criterion still isn't defined by the current draft of the Directive provides significant opportunity for the patent system to again drift towards the American position.

  2. There is considerable concern from the standardization community about the availability of patents in areas such as data compression, encryption and the like. In particular, I.T. standards—and by that, I am not referring to products that come out of Redmond, but the work of the IETF, JPEG, MPEG, W3C and others—are usually licensed free of charge to all comers, which is even less restrictive than the “reasonable and non-discriminatory” rules under which the telecoms industry (for instance) operates. This, it seems, is quite a thorny issue, because telecoms companies already hold and make use of patents in these areas, and I think the Patent Office and the Government are understandibly reluctant to make any changes that might harm the patent-driven innovation that does go on in the telecoms arena.

  3. Another issue that is worrying the software development community at present is interoperability. We are told that competition law can be used to enforce interoperability requirements already where necessary, a point made again by Peter Lawrence, although he did concede that it was difficult to enforce competition law in some cases—but also commented that the maximum fine (10% of turnover) was a hefty incentive for companies to comply. As I am currently running a company myself, I have to agree, and also think it is worth highlighting the fact that the penalty is a percentage of turnover rather than profit—that is, being fined like this could easily turn a profitable year into a significant loss for many companies.

    The reason that the Government and the Patent Office are reluctant to see text in the Directive to enforce interoperability is again that it has an impact on other sectors—in particular telecoms—where patents do seem to be working the way that they were supposed to, and an interoperability clause in the Directive could result in damage to the telecoms industry (where a lot of work is actually directly concerned with interoperating between different signalling protocols—something which, as someone who used to work for a telecoms firm, I can certainly understand).

  4. Finally, there was a question from one member of the audience about the status of software developed for charities and whether it was right that such software should be subject to the patent system even where a “technical contribution” was held to exist. Frankly, I think it is unlikely that this would be a problem in practice, given the explanation of Peter Hayward on exactly what was and was not supposed to be patentable, but it is nevertheless an interesting point and perhaps some thought should be given to protecting charities from patent infringement claims (although how this could be done without damaging the value of legitimate patents I am not sure).

Anyway, I think the conclusion that I drew from the meeting was that the Government, the Patent Office and the majority of us are really all on the same side, contrary to the FFII propaganda, and that although some fine-tuning may be necessary to ensure that we are properly protected from the type of drift towards U.S.-style patentability that previously occurred in the EPO, a lot of the actual issues that have been raised are really due to people misunderstanding the law as it stands today.

Finally, I'd like to publicly thank Peter Lawrence, Lord Sainsbury, Peter Hayward and Steve Probert for organising, attending and speaking at the meeting, and for listening to the concerns of those present.

Tel:/sip: URL Handler for Snom SIP Phones

I was thinking the other day that it’d be great if you could click on a link to a tel: or sip: and have your phone dial the number. In my office, I have a snom VOIP telephone, which has an integrated web server that you can use to, amongst other things, dial numbers… which started me thinking.

URL handlers have received a lot of (adverse) publicity recently on Mac OS X, because they have been the subject of a number of security flaws, but they are absolutely perfect for this sort of application. It turns-out that it’s quite easy to write one, too.

Anyway, I thought the results might be useful to more than just me, so please feel free to download my snomURLHandler application, which is a Status Item (that is, one of those icons at the top right of your screen). It’s very basic, but quite useful I think, and also allows you to dial a number from AppleScript by writing something like

tell application snomURLHandler
  dial "<some phone number>"
end tell

Company Website Update

I’ve just finished a marathon site update on my company web site. It’s probably quite hard to see what has changed, but here’s a short list:

  • Automatic(!) localised pricing (U.S., Europe and U.K.)
  • VAT support (although the company isn’t VAT registered yet…), including support for both physical and downloadable products, with correct allocation of VAT, including E.U. distance selling thresholds. That doesn’t mean it’s fully automated, of course, because it isn’t possible to do that at present.
  • Invoicing, including both text-based invoices sent by e-mail and, in parallel, the same information presented on the web.
  • Integration with a proper credit-card handler (i.e., not PayPal). PayPal’s great, especially in Europe where it’s properly regulated, but a lot of people don’t like it—plus you have to sign-up for an account in order to use it. Well, OK, if you’re a U.S. merchant, then you can make sign-up optional, but those of us in the rest of the world don’t have that option.
  • Finally, the beginnings of a usable back-end… still not really finished, but it’ll save me from at least some command line SQL. It’s even got some SVG-based graphs, which I’m quite pleased with (although as a customer, you wouldn’t be able to see them).
  • Re-vamped customer area, including the ability for customers to view and edit their own details, download software, generate licence keys, and view past purchases.
  • Support for account customers.
  • “Shopping Cart” support, which makes it easier for people to purchase more than once licence at a time.
  • (Hopefully) even better support for accented and other non-ASCII characters. The entire site is now UTF-8 based (previously only the My Keys area used UTF-8).
  • Built-in support for e-mail announcements, which means that customers only have to keep a single address updated, and also means that it isn’t necessary to copy their addresses across periodically to keep a separate bit of list software up to date.

There are still plenty of things to come, including a new product, which should be available for beta test late this month.

VAT and the EU

Over the past few days, I’ve become more and more annoyed by the number of American companies on the ’Net complaining about the “complexity” of accounting for VAT and the fact that they have to identify their customers’ country of residence, although those of us inside the EU (according to them) don’t.

To set the record straight, the moment you start thinking about physical goods, VAT is even more complicated to account for if you are inside the EU! In particular, non-EU businesses can register under a simplified scheme that means they only have to register in a single member state and must pay all VAT due (at rates appropriate to the customer) to that member state. Whilst intra-EU trade is simpler in the case where the company is providing a service over the Internet (because they are only required to charge VAT in their member state in that situation), if any physical goods change hands, then it balloons into a monster! To trade physical goods within the EU, you must:

  1. Identify the country of residence of your customer.
  2. If the total sold into that country is over the distance selling threshold for that country (which isn’t necessarily in the same currency as the sale, and may not even be in the same currency as the VAT you must charge!), then:
    1. If you aren’t registered for VAT in the customer’s member state, you must do so.
    2. If that member state happens to be Finland, then you can’t sell your goods, because Finland requires registration prior to trading.
    3. You have to charge VAT at the prevailing rate for the customer’s member state—but be careful, because some products attract different rates of VAT than others.
    4. This VAT may not be in the same currency as the sale. It may also have to be calculated according to complex and often arbitrary rounding rules, all different depending on which country you are talking about.
    5. You may have to pay the VAT up-front, or in arrears, depending on the member state’s regulations.
    6. You may have to pay the VAT after invoicing the customer, rather than when the customer pays you.
    7. Depending on the regulations in force in the customer’s country, you may have to appoint a VAT representative.
    8. You may have to comply with other onerous regulations (for instance, in Greece, some documentation must be handed over in person)!
  3. If the total sold into the customer’s country is below the distance selling threshold, then you can charge VAT in your member state instead. This usually means that you have to quote VAT in your currency on their invoice, even if you have decided to bill the customer in their own currency. Plus, the customer will probably be expecting to pay VAT at their local rate. All of which adds up to a certain amount of confusion.
  4. Additionally, you need to remember that if you have (for instance) downloadable software and a CD-ROM on the same invoice, you may need to comply with two different VAT regimes (which may have contradictory rules) on the same invoice, and you’ll have to quote two separate amounts of VAT.

You can’t even (necessarily) get around the VAT complexity by outsourcing, because of the rules over “triangular transactions”, which are explicitly designed to prevent such things.

What this means in practice is that it’s impossible for an EU company to trade properly over the Internet, because you won’t be able to tell when the distance selling threshold has been exceeded when quoting a price to your customer. Of course, you are allowed to register for VAT individually in every member state of the EU, but that’s 25 sets of complicated, contradictory and often obtuse sets of rules that you must comply with (potentially more than one set at once, even on a single invoice), and what’s more, it means filling-out up to 25 separate VAT returns every month, many in a foreign language—and I don’t know about you, but I certainly can’t speak a word of Dutch, Italian, Greek, German or Spanish, let alone any of the less well known languages. Oh, and just to top it off, a lot of it has to be done on paper because of countries that don’t allow electronic VAT returns, or (like Germany) still require a paper return even if an electronic one has been provided. And as I mentioned above, you actually have to go to Greece! Aaaargh!

Obviously, all of this is fine for large companies, because they can just register everywhere and employ enough people to handle it. But for smaller companies, it’s a real nightmare.

Basically, what I’m trying to say is that the majority of American organisations that have complained about how complicated it is for them don’t even know that they’re born! The rules within the EU are frankly diabolical, and still provide a considerable advantage for companies selling into the EU from outside, especially for smaller organisations.

Disclaimer: I should just add that I’m not a qualified accountant and that the above shouldn’t be used as tax advice. If you have a question about VAT, then EU member states often have VAT helplines that businesses can use to get definitive answers, or, failing that, you should either consult a professional adviser or obtain copies of the relevant laws from the appropriate authorities.

Phew… That Was Painless

Movable Type really is an excellent piece of software; the upgrade to version 3 went (almost) totally without a hitch, the only problem being that commenting broke temporarily whilst I sorted-out how to enable TypeKey authentication.

Anyway, hopefully that will put an end to the flood of comment spam that I’ve been experiencing over the last day or so (oddly enough, I don’t want links on my site to pornography, places to purchase drugs or financial scams). If only the U.S. Government would take the poor behaviour of some of its citizens on the ’Net as seriously as it takes things like obvious jokes about bombs at airports… ;–)

I realise, by the way, that it isn’t just Americans that are responsible for spam, but it is certainly mostly Americans, both from personal experience and according to people like Spamhaus. Indeed, MessageLabs claim that:

…more than 80 per cent of global spam originates from fewer than 200 known spammers in the U.S.A.. Many are based in the small town of Boca Raton in Florida…

It’s a shame that those 200 people—or others like them—are still being allowed to give the United States a bad name, although at least the FTC is finally cracking-down on some of the spammers who were flouting the rather weak CAN-SPAM Act.