Reenigne blog

Patents are an enormous problem for the software industry. Software development organizations can never be sure that the software they develop doesn't infringe on somebody else's patent, so the only defence against being sued for patent infringement is to build up an arsenal of your own patents on methods as trivial as you can get away with in the hope that if someone sues you can counter-sue them for infringing on your patents and end up cross licensing. This doesn't protect against patent trolls, though (who produce no products and therefore don't need to worry about infringing someone else's patents). Also, it favours large software development organizations over smaller ones - patents are very expensive to obtain.

The usual answer to this is that we should get rid of software patents altogether. Perhaps this will happen, if enough powerful companies are burnt by patent trolls. On the other hand, perhaps some software patents are actually useful for progress - perhaps there are areas of software development where patents make much more sense than copyright - where simply examining the end product would allow somebody to (without infringing copyright) copy the part that took hard work to discover (i.e. an idea rather than the implementation). Perhaps there are ideas could not have been had without the investment that a promise of patentability would bring. Perhaps the additional secrecy that would have to be put in place without patents would cripple the industry.

Here's a proposal for a different sort of patent reform, which aims to solve these problems:

First, get rid of all the patent examiners. They're doing a lousy job anyway, granting all sorts of patents on things which have been done before and which are perfectly obvious to a person skilled in the art. Many of these patents don't stand up in court, but it's still expensive to defend against attacks from bogus patents. Instead, the patenting process should be a simple rubber stamp - anyone can send in a description of their idea (preferably not written in patent-ese), have it published on the USPTO (or equivalent) website and hey presto, that concept is now patented.

Of course, that doesn't get rid of the problem of bogus patents - it just moves the workload from the patent office to the court, which seems like it would make things worse. So the next stage is to set up a special patent court. If A wants to sue B for infringing on A's patent, it all gets sorted out in this court. The court needs to find a person skilled in the art (PSITA) who is not affiliated with A or B, and also to determine if B referred to A's product or patent. If the patent is bogus, or if B is determined to have invented the same thing independently, then the patent is thrown out and A has to pay the costs of the entire proceeding. If the patent stands up and B is found to have based their product on A's product or patent, then B must suffer the usual consequences, including having to pay for the proceedings. So (assuming the system works justly) all B needs to do to say safe is not to read unexpired patents and not to refer to competitors products - there should be no cost to them for accidental infringement or bogus patents (which really amount to the same thing - if it's possible to accidentally infringe on a patent it's a bogus patent by definition).

The third element we need is a way for a B to be sure that the product they want to release doesn't infringe on any patents (or to find out which patents it does infringe on). In practice it isn't possible to avoid seeing all competing products, so this step is necessary. The costs of this step must be borne by B, since otherwise B could cost A a lot of money by frivolously requesting repeated patent checks. The benefit is that (assuming the report comes back clean) there is then no risk of B losing a patent court battle. This sounds like it would be a very expensive exercise since it's essentially the cost of a patent trial multiplied by the number of active patents - however, a properly indexed patent database should make it reasonable.

One other element I'd like to see is a "use or it lose it" rule for patents, like those for trademark infringement. If you hold a patent, become aware of someone infringing that patent, and not choose to sue them immediately, you lose that patent altogether. This avoids problems with "submarine" patents.

I saw this interesting visualization of Atari 2600 binaries. It makes me want to do something similar, but arrange the instructions according to the position of the raster beam when the instruction is executed rather than the position in the ROM. The 2600 is a unique platform in that it lacks a frame buffer, so to produce coherent images, the code must be synchronized with the raster beam. If we make an image that has 4 horizontal pixels per color carrier cycle, that gives an 912 pixel wide image. There are 76 CPU clock cycles per raster line and instructions take 2-7 cycles giving us 24-84 horizontal pixels per instruction, which (with a bit of squishing) ought to be enough. A raster line would have to correspond to a line of text so we probably wouldn't want to show a full frame (field). However, a typical game will only have a few different "line sequences" so a full frame image would be very repetitive anyway.

As CodeSourcery employees work from home, we get together for a week-long meeting once a year in order to better understand each other. CodeSourcery was bought by Mentor Graphics last year, but the tradition continues for the division.

One of my favorite parts of the annual meeting is getting together with extremely talented people and having fascinating discussions about all sorts of technical things. Sometimes these are work related and sometimes we show each other our personal programming projects (the same sorts of things I talk about in this blog).

I often think it would be great to be able to have these kinds of in-person discussions more often than once a year. I've thought about setting up some kind of regular meetup in Seattle for just this kind of thing. I found Hack and Tell which seems to be exactly what I'm looking for except for the fact that it's in New York, so perhaps I should try to set up a Seattle chapter.

I also found a few things in Seattle which are similar but weren't quite what I was looking for one way or another:

• Dorkbot seems be more "electronic art" centric (although I haven't been to one of their meetings).
• Ignite Seattle seems to have a more formal format - 5 minute talks.
• Saturday House and Meet at the Pig seem to be inactive.
• Seattle Wireless HackNight at Metrix Create:Space - I actually went to this for a couple of months earlier this year. It's a very cool space and the people there seemed interesting, but the focus seemed to be more on having a set place and time to do some hacking and less on showing off personal projects to each other. I stopped going after a while partly because it didn't seem to be quite what I was looking for but mostly because it was in the evening which is problematic when you have two children who wake up you up at 7am sharp (at the latest) every day - if I don't go to bed at a sensible time I tend to be a bit of a zombie the next day.

There is a general principle in computing called the Robustness principle or Postel's law, which says that you should be conservative in what you send but liberal in what you accept.

This seems like a no-brainer, but adhering to the principle does have some disadvantages. Being liberal in what you accept introduces extra complexity into software. More problematically, being liberal in what you accept allows others to be less conservative in what they send. Nowhere is this more noticable than HTML. The first web browsers were extremely liberal in what they accepted - allowing HTML that is broken in all sorts of different ways. Many people wrote HTML by hand, tested it on just one browser and then uploaded it. Other browsers would often mis-render the broken HTML, leading people to put little buttons with slogans like "best viewed in Netscape 4" on their pages. As HTML evolved, continuing to accept all this misformed HTML while adding new features became a big headache for browser developers.

Lately, the best practices involve marking your HTML in such a way that browsers will only accept it if it's correct - that way you find out quickly about any mistakes and fix them early.

In general, I think that new protocols should now be designed to have a very simple canonical form and that only data that adheres to this form should be accepted - other data should be rejected as early as possible.

Inputs directly from users can still be interpreted liberally just because it makes computers easier to use, but that data should be transformed as early as possible into canonical form.

Here is a debugger feature that I think I would find really useful: avoid stopping at any given location more than once. This would be particularly useful when finding my around an unfamiliar bit of code - it would step into a function that I hadn't stepped into before, and then step over it the next time it was called, for example. In fact, I often find myself trying to do exactly this, just remembering which functions I've stepped into before (and often getting it wrong).

The other use case for this feature would be doing a sanity test once some new code has been written - the debugger would just stop on the new/changed lines of code so that you can make sure that they're working as expected.

One difficult part about this feature (especially for the second use case) would be keeping track of which locations have been stopped at even across recompiles (so the instruction pointer location won't necessarily be the same) and across source changes (so the source line location won't necessarily be the same either). So really to implement this properly we need to completely overhaul the entire compilation system so that it takes as input the deltas from the last compilation and performs the corresponding modifications to the output files (including both the binary and the list of which locations have been visited).

Such an overhaul would be extremely difficult, but would be useful for other reasons as well - in particular, it has the potential to make builds much faster, which shortens the edit/recompile/test sequence and makes programming much more pleasant. Also, it could integrate with editor syntax highlighting and code completion features, so that these always reflect the current state of the program.