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?

Disqus for Ken Fox's Blog