More on Green Hills v. Express Logic

by on July 21, 2006 · 2 comments

DSO.com has an in-depth look at a dispute I first mentioned last week between Green Hills and Express Logic over whether Green Hills can reverse-engineer Express Logic’s API in order to build compatible products. I’m pleased to see that Jason Schultz’s take on the subject is about the same as mine:

On June 12 Express Logic accused Green Hills Software, Santa Barbara, Calif., a licensed reseller of Express Logic’s software, of illegally copying its ThreadX API. The API is a piece of the RTOS that defines the interface between the OS and the programs a customer will build on top of it.

Express Logic also claims that Green Hills then used the illegal copy to create an API in its micro-velOSity RTOS. Green Hills has publicly denied all of Express Logic’s charges. The dispute will be adjudicated by a professional arbitrator .

“What’s at stake here,” says Jason Schultz , a staff attorney at the Electronic Frontier Foundation (EFF) in San Francisco , “is a long-time tradition of computer programming–the tradition of interoperability.”

Express Logic’s position strikes me as rather weak:

“If it turns out we’re wrong and that you can, in fact, copy an API without infringing on a copyholder’s copyright, then that opens the door to a lot of other things,” says John Carbone, vice president of marketing at Express Logic, San Diego, Calif . “For example, what other portions of the source code can you copy? Data structures? The comments? The functions? The user manual? That’s dangerous–it’s a slippery slope. Basically, [such a ruling] would make everybody’s API open source. The API would no longer be a distinguishing factor.”

Well yeah, you don’t want a product’s API to be its “distinguishing factor,” any more than you would want railroads to run their trains on different-guage rails. The courts don’t seem to have had any difficulty drawing the relevant distinctions between a program’s interfaces and its source code. There’s little reason to think this case is different.

  • http://www.blindmindseye.com MikeT

    The API itself is just the exposed code. Hence why the “I” in the acronym stands for “interface.” It is the entry-point that a developer uses to get to the functionality in a library. There isn’t really a comparison to other areas of endeavor, though.

    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.

  • http://www.blindmindseye.com MikeT

    The API itself is just the exposed code. Hence why the “I” in the acronym stands for “interface.” It is the entry-point that a developer uses to get to the functionality in a library. There isn’t really a comparison to other areas of endeavor, though.

    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.

Previous post:

Next post: