5 ms·

I started reading this article today thinking that the case was clear-cut - Oracle's wrong and Google is right. As I read the article and the comments I'm now n

I started reading this article today thinking that the case was clear-cut - Oracle's wrong and Google is right. As I read the article and the comments I'm now not at all sure. We all are trying to come up with a good analogy to explain why APIs are distinct from implementations, why it's 'obvious' to a programmer how they're distinct, and how their rules should be distinct. But the more I think about it, and read feeble attempts to relate software to other industries, I am starting to think I was wrong. In my experience, especially where good design is encouraged and respected, I can spend far more time designing the API than implementing it! If I create a proprietary API shouldn't it be protected? Or am I misunderstanding the nature of the debate?

orev 6y ago
This could be easily explained using an analogy like a pipe. If you need to connect a hose to your house, the connector (interface) needs to match the spigot size and threads. The API is simply the information about the size and thread measurement, along with the knowledge that you can get water out of it when you turn the handle. Having this knowledge and building compatible hoses or spigots doesn’t mean you have stolen anything from the company who made the original spigot. I could easily come up with dozens of analogies that explain this concept in terms understandable by senior citizens, and it’s inexcusable that this lawyer can’t do the same.
- babesh 6y ago
  That is a terrible analogy since the potential conceptual range of APIs is so wide and because it does disservice to the conceptual power of APIs. Good APIs embody the key architectural and conceptual decisions. They define the key concepts and how they interact. But at the level of a programming language, this is of immense scope and power. Java defines an imperative language with built in garbage collection with abstraction from physical hardware. Furthermore, the real distinction between API and implementation is that API are that which needs to be exposed to the world. Programming languages are more akin to defining the fundamental laws of a universe. Physics to chemistry. It is true that other APIs are of much smaller scope but the point is that the range is so wide.
  - ummonk 6y ago
    It's actually a great analogy in that respect, as there are substantial tradeoffs involved in the design of pipe connector types, and the design of a particular connection / thread standard embodies key architectural and conceptual decisions.
    - babesh 6y ago
      The post only commented on size and thread. There is far, far more than that. Also some connectors are patented for what it is worth.
cmiles74 6y ago
I agree; a big part of the problem is that the whole concept of what an API is and what it does has really grown in the last 40 years. The original IBM PC BIOS exposed an API but it was far simpler than the Java API. When we draw an analogy between a large industrial machine and all of it's levers and switches and buttons and the interrupt calls on an IBM PC BIOS, the analogy seems somewhat reasonable. It certainly feels like we're straining that analogy when we apply it to the Java API. Even so, the Java API is clearly documented and publicly available and anyone can look it over. It's clear that it provides a contract to the software developer saying things like "if you give me this data when you call this method, I will give you data that looks like this in return". The idea that an API is a contract, I think is sound and the analogy holds water, in my opinion. Is there really nothing creative about writing an API? Well, I think that's an arguable point. When you drive a car you steer a wheel and when you type you press buttons; it's arguable that these are simply obvious implementations that many people might independently develop on their own. It's mechanical and, perhaps, lacking in creativity. But the Java API? Some portions, for sure, are obvious: any collection of things has a "length" method. But someone did come up with a plan for managing the namespaces and the package names and some packages have APIs that are pretty clever and, perhaps, reveal true creativity. Still I'm against protecting APIs from third-party re-implementation. I did not find Oracle's arguments at all compelling and, in my view, that was really their job here. Instead they pretended that this idea of an API as a contract anyone could re-implement was totally alien to them and that struck me as a bit dishonest. I'd like to see a more compelling argument before we upend how we thought APIs worked for the past forty years.
- sergeykish 6y ago
  Great example with IBM PC BIOS, there was source code, there was infringement suit, yet clean reimplementation won [1]. [1] https://retrocomputing.stackexchange.com/questions/12018/why-did-ibm-make-the-pc-bios-source-code-public https://retrocomputing.stackexchange.com/questions/12018/why...
sergeykish 6y ago
I does not matter if your API design is good, all we need is compatibility. Microsoft Word .doc format claimed to be awful [1] and yet there are a lot of clients. [1] https://www.joelonsoftware.com/2008/02/19/why-are-the-microsoft-office-file-formats-so-complicated-and-some-workarounds/ https://www.joelonsoftware.com/2008/02/19/why-are-the-micros...

orev 6y ago

This could be easily explained using an analogy like a pipe. If you need to connect a hose to your house, the connector (interface) needs to match the spigot size and threads. The API is simply the information about the size and thread measurement, along with the knowledge that you can get water out of it when you turn the handle. Having this knowledge and building compatible hoses or spigots doesn’t mean you have stolen anything from the company who made the original spigot. I could easily come up with dozens of analogies that explain this concept in terms understandable by senior citizens, and it’s inexcusable that this lawyer can’t do the same.

babesh 6y ago
That is a terrible analogy since the potential conceptual range of APIs is so wide and because it does disservice to the conceptual power of APIs. Good APIs embody the key architectural and conceptual decisions. They define the key concepts and how they interact. But at the level of a programming language, this is of immense scope and power. Java defines an imperative language with built in garbage collection with abstraction from physical hardware. Furthermore, the real distinction between API and implementation is that API are that which needs to be exposed to the world. Programming languages are more akin to defining the fundamental laws of a universe. Physics to chemistry. It is true that other APIs are of much smaller scope but the point is that the range is so wide.
- ummonk 6y ago
  It's actually a great analogy in that respect, as there are substantial tradeoffs involved in the design of pipe connector types, and the design of a particular connection / thread standard embodies key architectural and conceptual decisions.
  - babesh 6y ago
    The post only commented on size and thread. There is far, far more than that. Also some connectors are patented for what it is worth.

cmiles74 6y ago

I agree; a big part of the problem is that the whole concept of what an API is and what it does has really grown in the last 40 years. The original IBM PC BIOS exposed an API but it was far simpler than the Java API. When we draw an analogy between a large industrial machine and all of it's levers and switches and buttons and the interrupt calls on an IBM PC BIOS, the analogy seems somewhat reasonable. It certainly feels like we're straining that analogy when we apply it to the Java API. Even so, the Java API is clearly documented and publicly available and anyone can look it over. It's clear that it provides a contract to the software developer saying things like "if you give me this data when you call this method, I will give you data that looks like this in return". The idea that an API is a contract, I think is sound and the analogy holds water, in my opinion. Is there really nothing creative about writing an API? Well, I think that's an arguable point. When you drive a car you steer a wheel and when you type you press buttons; it's arguable that these are simply obvious implementations that many people might independently develop on their own. It's mechanical and, perhaps, lacking in creativity. But the Java API? Some portions, for sure, are obvious: any collection of things has a "length" method. But someone did come up with a plan for managing the namespaces and the package names and some packages have APIs that are pretty clever and, perhaps, reveal true creativity. Still I'm against protecting APIs from third-party re-implementation. I did not find Oracle's arguments at all compelling and, in my view, that was really their job here. Instead they pretended that this idea of an API as a contract anyone could re-implement was totally alien to them and that struck me as a bit dishonest. I'd like to see a more compelling argument before we upend how we thought APIs worked for the past forty years.

sergeykish 6y ago
Great example with IBM PC BIOS, there was source code, there was infringement suit, yet clean reimplementation won [1]. [1] https://retrocomputing.stackexchange.com/questions/12018/why-did-ibm-make-the-pc-bios-source-code-public https://retrocomputing.stackexchange.com/questions/12018/why...

sergeykish 6y ago

I does not matter if your API design is good, all we need is compatibility. Microsoft Word .doc format claimed to be awful [1] and yet there are a lot of clients. [1] https://www.joelonsoftware.com/2008/02/19/why-are-the-microsoft-office-file-formats-so-complicated-and-some-workarounds/ https://www.joelonsoftware.com/2008/02/19/why-are-the-micros...