Especially in higher-level languages that have design-by-contract concepts built into them, an API is often literally just a programmatic contract. You code against a special type of object called an “interface” which contains a list of methods that must be implemented by an object that implements the interface. This is a basic guarantee that certain functionality will be there.

In Java, there is an interface called “Runnable” that is a bit similar to this sort of thing. Runnable contains one method: void run();. run() by itself is nothing. It is a placeholder for functionality that is defined in a new class. I can write a class named ThreadedWindow that implements Runnable and its run() method will work completely differently from someone else’s ThreadedWindow implementation, but the Java APIs will be able to interact with ThreadedWindow because it is marked as an implementer of Runnable and contains a (presumably) correct run().

The short and sweet summary for those who don’t do any programming is that it is entirely legally and technically possible to have two implementations of the same API that work almost completely differently internally, yet expose the same functionality. You can use two totally separate designs to arrive at the same conclusion.

If you think that this is a violation of IP rights, then think again. A hardware equivalent would be Microsoft writing an emulator for the PS2 that runs on the XBox 360. The emulator exposes the instruction set of the PS2′s “emotion engine” processor, but goes about it differently from the PS2. Still, a developer could target code to the PS2, then deploy onto the XBox 360 and it would work. An instruction set is, after all, nothing more than the electrical engineering equivalent of a software API.

Especially in higher-level languages that have design-by-contract concepts built into them, an API is often literally just a programmatic contract. You code against a special type of object called an “interface” which contains a list of methods that must be implemented by an object that implements the interface. This is a basic guarantee that certain functionality will be there.

In Java, there is an interface called “Runnable” that is a bit similar to this sort of thing. Runnable contains one method: void run();. run() by itself is nothing. It is a placeholder for functionality that is defined in a new class. I can write a class named ThreadedWindow that implements Runnable and its run() method will work completely differently from someone else’s ThreadedWindow implementation, but the Java APIs will be able to interact with ThreadedWindow because it is marked as an implementer of Runnable and contains a (presumably) correct run().

The short and sweet summary for those who don’t do any programming is that it is entirely legally and technically possible to have two implementations of the same API that work almost completely differently internally, yet expose the same functionality. You can use two totally separate designs to arrive at the same conclusion.

If you think that this is a violation of IP rights, then think again. A hardware equivalent would be Microsoft writing an emulator for the PS2 that runs on the XBox 360. The emulator exposes the instruction set of the PS2′s “emotion engine” processor, but goes about it differently from the PS2. Still, a developer could target code to the PS2, then deploy onto the XBox 360 and it would work. An instruction set is, after all, nothing more than the electrical engineering equivalent of a software API.