Monday, June 11, 2012

There's a great article at Groklaw on software patents. What's different this time is that the author, Professor Michael Risch, suggests ways to improve the existing system while preserving the patentability of software.

I like the suggestions, but I'm still worried about the economics. Here are my thoughts that I posted in the comments:

There's a large community of software developers that invents and distributes software at extremely low cost: Open Source software is usually free and mobile apps cost less than a coffee. This community creates enormous social value.

These developers do not benefit from the patent system incentivizing disclosure of inventions, but they are harmed by patent suits because they do not have the resources to defend. Software patents form an existential threat to them.

Professor Risch, if there was a way to remove or protect this community from the rich man's game of patents, I think your suggestions would fix software patents. Otherwise, your suggestions still form an existential threat. Are software patents worth the social cost?

Sunday, April 29, 2012

Oracle v Google

Oracle is suing Google for copyright violation because Google created a compatible implementation of Java in Google's Android operating system. Very little actual copying has been shown, so the case hinges on whether the structure, sequence and organization of the Java APIs can be copyrighted. What?! That decision would cripple competition in the software industry and create problems for all software engineers.

APIs are how software applications interface with other systems. It's a very loosely defined word and includes everything from Java-style packages to hardware BIOS to network services. The only purpose of an API is to provide the method of operation for an application to use the features of another system. Methods of operation are not copyrightable! Everyone in the software industry has assumed that APIs are not copyrightable. There have also been high profile legal cases such as Lotus v Borland that have reinforced the understanding that APIs are not copyrightable.

Testimony in Oracle v Google has told us that developing an API is hard, creative work. This is untrue. It conflates a system's API with the ideas embodied in the system. Developing those ideas can be extremely hard, creative work, but once the ideas exist, an API can be generated mechanically by simply following engineering practice. For example, the Unix operating system implemented a completely novel process management system. The API for process management comes directly from that idea combined with engineering conventions such as using numbers for error codes. Unix uses the words "fork" and "exec" to help make the API easier for people to understand. The words are not meaningful to a computer, so "clone" and "load" would have functioned equally well as an API. Frequently the words to use are obvious because the ideas are well known outside the system. Mathematics, cryptography, databases and networking all have standard terminology that show up in APIs. In rare cases, such as the Unix example, the choices of words are creative and establish new vocabulary for software engineers. I don't think any of the contested Java APIs fall into this category, but what if some do? Is it worth protecting this?

An API is built once and then used many, many times by application software engineers. Applications are so dependent on APIs that lock-in is a commonly discussed problem. If just one API becomes unavailable, unsupported or unstable, it can cripple an entire application. There are currently three common approaches to this problem:

  1. accept the risk;
  2. only use APIs available from multiple sources;
  3. write wrapper APIs to insulate the application from other APIs.

In the first case, copyrights on APIs have no effect. (Of course if an application is composed of systems with custom APIs, copyright infringement could now apply to those custom APIs, so "no effect" only applies to small, simple applications.)

In the second case, copyrights on APIs would restrict competition to provide only incompatible APIs. If multiple systems provide competing functionality, an application programmer could not switch without rewriting portions of the application. Application programmers are also hurt because the first API to market can grab the most common words for an idea and force others to use poorer choices. It's unclear whether anyone can write "lang.math.max" anymore if "java.lang.math.max" is copyrighted, so competition may be restricted even across language and system domains.

In the third case, copyrights on APIs would create patent-like minefields for software engineers because they would have to show cleanroom conditions if a wrapper API has similar structure, sequence and organization as someone else's API. The current common approach of re-implementing an API already in use for another system will definitely not fly. Willful infringement for patents is easily prevented by not reading patents. Cleanroom conditions forces software engineers to not read software!

Wouldn't it be strange if Oracle won a decision that means the original Oracle database infringed IBM's System R database API? Or if Oracle Linux infringed Novell's Unix API? Or if Sun's WABI infringed Microsoft's Win32 API? Or if Sun's NeWS infringed Adobe's Display PostScript API?

As a software engineer, this case is impossible to accept. The world has gone crazy. Mathematicians must have felt similarly in 1897 when Indiana's legislature was debating pi. Unlike that circus, Oracle v Google will have a decision. Tune in next week to find out if software competition still exists. Crazy.

Wednesday, February 1, 2012

Reading List, Part 1

Jiri Novotny recently published his list of 30 books everyone in the software business should read. A friend linked it on Facebook and asked us what we thought.

I wasn't impressed because there aren't enough software books in the list and some of the books seem trendy or interchangeable with better titles. Jiri lists some excellent books, and I have many of them, but it seems wrong to call out these 30 as special. (My bias towards technical founders surely doesn't help my opinion.) So now I'm on the hook to come up with a top 30 list of my own. Oops.

Tuesday, January 31, 2012

Another Short Story

After reposting that paper airplane story, I thought I'd share one of my favorites. This blog was intended for serious business—concentrating interests for an audience and all that. Whatever. (Which happens to be the name of a fantastic blog by John Scalzi.)

The Value of a Convincing Lie in Discovering the Truth

or How to outsmart a seven year old

I'd been suspecting that Andy wasn't eating his lunches for some time. However, whenever I asked him, he would always say he ate it. One day, just after Halloween, I made a very nice tuna sandwich on home-made bread. I also put in half a carmel apple, carrots and two pieces of Halloween candy. How could he possibly not like this?

Friday, October 7, 2011

Cognitive reboot

My three year old has been playing with Sifteos for a couple hours (in 30 minute sessions). There aren't many games for him yet; all the games he plays are recommended for 4-7 year olds. One simple game of navigating a gopher through a maze looking for a turnip gives him equal amounts of fun and frustration. I think it breaks his concept of object permanence.

The game works by creating a secret, virtual maze that you reveal one block at a time by placing a block adjacent to the block displaying the gopher. Clicking on a block will move the gopher to that part of the maze. The gopher is always visible, but other blocks turn off as soon as they stop touching the gopher. They are kind of bizarre as physical objects go:

  • Blocks look different and have stable displays. There aren't any animations on the blocks, so it looks like the blocks are printed with pictures. This is an illusion!
  • The blocks are actually fungible. It doesn't matter which block is placed adjacent to the gopher since they all just reveal the same section of the maze.
  • Orientation doesn't matter. Spinning the block doesn't matter because the picture of the maze shown on the block isn't part of the block--it's just revealed by the block.
  • Position on the table doesn't matter. The maze revealed is relative to the gopher even though it looks like the block is revealing a maze drawn in hidden ink on the table. Moving the gopher block changes all the other blocks. Moving all the blocks together doesn't change any block.

My son kept trying to build a maze instead of reveal a maze. When he set a block next to the gopher and revealed a path, he associated that path with that block and remembered it even after setting it aside. When he was in a section of maze where he wanted the gopher to turn, he'd pick up a remembered "turn block" and place it. The old block instantly morphed into a different piece though and then he'd shoot me this wtf expression as if the game cheated.

He has made progress understanding the game, but doesn't quite have the correct mental model. His current strategy is to never move the gopher block. This makes the hidden maze act as if it is drawn on the table. All the blocks become simple secret decoders revealing the table's maze.

All the concept games I've made don't break players' mental models of the world. This gopher maze seems to have done it accidentally--at least for three year olds. I wonder how far this idea can go if a game really exploited it?

Monday, October 3, 2011

Woot! My Sifteos arrived!

These have been in the news for a while. Ars technica wrote a detailed review. I found them after seeing David Merill's TED talk on his Siftables research. I bought the basic set plus three extra cubes. Here's what it looks like in practice with the six cubes, charging dock, and USB wireless link plugged into my laptop:

The SDK uses C# to build a program that runs on the laptop. The program talks over wireless to the individual cubes which report back events such as cube shake and tilt, cube touch and button push. The drawing API seems spartan--mainly drawing images onto individual cubes--so I think none of the game play happens on the cubes. Loading programs onto the cubes takes a while (15 to 30 seconds for what I've tried) so all the images are local to each cube and drawing is smooth. Once I get going with the SDK I'll know a lot more. (It's possible that the Sifteo wireless creates a lot of traffic that interferes with my laptop wireless network--shutting down Sifteo sped things up considerably.)

My three year old son played with them and there's a lot of potential. It was fun watching him learn how these work--more on that tomorrow.

Sunday, October 2, 2011

Scrolling: document up or viewport down?

My first graphical user interface was a Sun 3 running SunView. That's a classic WIMP interface bordering on antique. I was already a programmer so it's hard for me to separate the machine from the user interface. The machine's model of scrolling consists of a viewport window, a scrollbar and data to display (frequently another window). This is the model-view-controller paradigm invented for Smalltalk. It's easy to see the scrollbar thumb as being the position of the viewport over the data, so scrolling down means moving the thumb and viewport down the data and holding the data still.

My three year old son using a touch interface has a completely different mental model. The machine still uses the same model-view-controller paradigm, except the UI consists of dragging the document up rather than moving a scrollbar thumb down. What I call scrolling down, my son calls up. His model is more intuitive and simpler in every way.

This is really exciting! After 30 years of stagnation, user interfaces are finally changing.

Disqus for Ken Fox's Blog