Software Patents Explained to my Grandfather

This article is a write up of the talk I gave at OggCamp10, and some of the discussions thereafter. It’s not a reiteration of the talk, however. There’s a video that I’ll link to once it’s uploaded.

My idea started when someone suggested to my that I should apply for a patent if I wanted to market a piece of my software. I thought this was a terrible idea – software patents are destructive to software innovation. But not having a succinct way to explain why to someone who’s not an open source programmer, I just shrugged off the issue.

Then, at the first OggCamp, I saw an excellent talk by Bruno Bord on explaining programming and open source to non-techies. He used an analogy of Jam making to show how he explained programming to his grandmother. This seemed like a good method of explaining software patents, if I could think of the right analogy.

There are 2 reasons I wished to give this talk at OggCamp. Firstly, to see if my analogy worked, and secondly to see if my arguments held water. Let’s face it, if I couldn’t convince a bunch of Open Source Geeks that I was along the right lines with a criticism of software patents, I certainly couldn’t convince anyone else!

The analogy I settled on was chess. In a chess set, you have a board and pieces, which are analogous to a the computer hardware. You also have a book if defined rules which are analogous to a computer’s instruction set, the basic operations that can be performed by a processor. By combining these rules with the board and pieces you can create games of chess, just like you use the computer’s instruction set to write programs. Whatever language you write, whatever you do with the data, they all boil down to a sequence of the same instructions executing on the processor in the same way.

There are 3 conditions any invention must satisfy to be granted a patent: It must be new, it must have an industrial application, and it must represent an inventive step. Now, there’s no denying that software has an industrial application, and some of it is certainly new, but does it represent an inventive step? I’d say not.
As a programmer, when I get asked to solve a problem with software, I certainly never have to invent anything to do so. I may need to write a lot of code, I may have to rewrite it to work a bit differently to how I have before. But would other programmers in my field, given the same problem, have ended up with a solution that fundamentally does the same thing in the same way? Almost certainly. If it’s as obvious to them as it is to me, it’s not an inventive step.

One of the counter-arguments presented to my viewpoint was that if all inventions are merely the sum of their parts, then surely nothing represents an inventive step?
This put me in my place for a moment or two. Had I known when I was writing the talk that I’d be delivering it on the main stage, I’d certainly have prepared better for this sort of question. However, while it’s true that physical patented inventions do use the same processes that have come before, those processes aren’t the end product like they are with software. A Dyson vacuum cleaner may be made with conventional plastic molding techniques, but the end result is a fundamentally different way of moving air within the device to extract dirt without the need for a bag. When a piece of software is written, the end result is always that of moving data around the hardware. You can’t change how the processor manipulates electrons with code.

Other arguments were raised about how best to protect your inventions. The example of SQL’s invention, a completely new way of querying databases at the time, was cited. Had it been protected, IBM could have prevented companies like Oracle from even have existing, yet they didn’t. It was suggested that the best way to protect your interests is to “be first to market and shut up,” the very behaviour that real-world patents were created to discourage. However, in the open source world, we’ve seen that sharing ideas and technologies isn’t incompatible with commercial interest. Red Hat releases all it’s code as open source, yet it still makes money. There’s even CentOS who give away exactly the same product for free that Red Hat sell, and yet their stocks are on a recession-defying rise.

The final point that was raised was that of copyright. Do I think that copyright needs to be strengthened, or that the terms of open source licences be more restrictive to provide us with the protection we lose out on by rejecting patents? No, I don’t. Copyright is already effective immediately, and it’s effective for longer than any technology created today will still be useful for. As far as licencing goes, we even have licences that enforce sharing if we want to, which is what patents were for in the first place.

In conclusion, I think that my analogy works quite well. My argument as a whole needed work, but now I’ve seen the counter arguments, I think that the modern, open software industry has moved beyond patents to a place where we don’t need to sue the competition into submission in order to protect our interests.

SVG: Your new graphics format for the web

This post is a write-up of the talk I gave at OggCamp10 over the weekend.

It’s been announced that IE9 will finally support SVG rendering, bringing it up to speed (in this area at least) with the other modern browsers. This has some potentially huge implications for web designers and developers, as it gives us a fundamentally different way of displaying content on the web.

What’s SVG?

SVG stands for “Scalable Vector Graphics”. It’s a W3C Standard format which, surprisingly enough, defines a vector graphics. What’s different about that? Well, the graphics in use on the web until now have been bitmap formats such as JPEG, PNG and GIF. A bitmap requires that the colour, position and (where supported) opacity of each pixel in the image is stored. Compression can be used, but in general this means that a lot of data is stored and transferred for each image, which increases exponentially as the image becomes larger or more complex.
Vector Graphics take a fundamentally different approach. Rather than storing individual pixels, they store data about shapes. Each shape in the image has properties such as it’s height, width, position and colors stored. When the image is displayed, these properties are used to dynamically render the image. This provides 2 advantages. Firstly, the file size is, generally speaking, a lot smaller for a vector image than for a bitmap image since less data has to be stored. Also, it allows the image to be scaled and stretched up or down in size, without losing resolution and becoming pixelated.
SVG is also an XML format, so is pretty easy to learn for anyone used to XHTML or other XML formats. It even supports CSS styling, including pseudo-classes like :hover!

What’s so good about that then?

One of the great advantages that vector graphics offers on the web is screen resolution-agnostic images. All too often images are a constraint on the width of a web page where they’re required for a hea graphic or an important layout element. With SVG, you can have a design which scales to fit the user’s screen, rather than the other way around. Furthermore, SVG already has solutions for many of the problems that CSS 3 has been trying to solve, such as rounded corners (all SVG rectangles can have a corner radius defined) and custom fonts (fonts are just vectors after all, so they can be easily embedded in an SVG).

Another cool thing that SVG’s good for is data visualization. As SVG is an XML format, there’s various ways of dynamically generating graphs from raw data.

For me, the real selling point of SVG is it’s potential to provide a realistic, open alternative to the proprietary Flash format for multimedia in the browser.
SVG can be manipulated through Javascript just like HTML can (albeit currently with a standard XML DOM). This combination of vectors and scripting is remarkably similar to Flash’s use of vector graphics in conjunction with ActionScript. In fact, ActionScript and JavaScript are both based on the ECMAScript standard, so moving from one to the other certainly isn’t a huge paradigm shift.
And video, I hear you ask? Well, SVG also supports a tag called “foreignobject”, allowing you to easily include elements from another XML spec inside an SVG image. This can be used very effectively in conjunction with HTML5’s video tag to display video, with the added advantage that you’re not limited to a rectangular player.
There’s still work to be done in this area. While this is all *possible* at present, there’s nothing with the ease of Adobe Flash for producing SVG with animation or embedded video/audio.

How do I produce SVG?

There’s 3 main options at the moment:

  1. Hand-Code it

    Like any other XML format, you can produce an SVG document quickly and easily with a text editor. The following line is all that’s needed to display a simple rectangle.
    <svg width="100" height="100"><rect width="100" height="100" /></svg>

  2. Dynamically Generate it

    As an XML format, it’s possible to transform any other XML data into an SVG graphic using XSLT. You can also use javascript libraries like Raphael and gRaphael to do the hard work for you!

  3. Draw it

    There are a few packages that support SVG, but the best by far is Inkscape. With full support for all SVG elements, layers, and even a raw XML editor if you want, you can’t do a lot better if you want to produce an SVG quickly. Inkscape’s native format is SVG with some extra metadata, but you can also save to “Plain SVG” which is web-ready.

This material is just a preview if what’s going to be available. We are going to have to wait and see exactly how good IE9’s SVG support is and how long it takes people to switch over, but with SVG as a reliably-supported format to complement not only existing image formats, but HTML itself, I can see exciting things in the next few years of the web.