4 ms·

> From a purely technical point of view, The technical point of view needs to be combined with the legal one here, and — > At the same time, Oracle’s characte

> From a purely technical point of view, The technical point of view needs to be combined with the legal one here, and — > At the same time, Oracle’s characterization of their API as “original software” is not entirely off base, as anyone who has spent time and energy creating and API would know. The amount of design and work required to create an elegant and useful API is huge, and while it would irreparably harm software as a field to call it copyrightable, calling it anything other than an “original” work is a weak position. just because something takes a lot of work, that doesn't automatically mean it is copyrightable. An API doesn't implement anything, it describes a function. Even if it describes a lot of functions and they mesh together really well, there's a distinction between "what" a program does and "how" a program does something. To compare with literature copyright, there are a ton of romance novels out there — pretty sure you can find a lot of common patterns on "what" story they tell. However, only the "how" is copyrighted, you can't prevent anyone from writing a story with the same outline as an existing one. (For literature, the problem becomes really tricky since the crossing over from "what" to "how" is kinda fluid; e.g. you can't just swap out character names. Software is actually easier there.)

marcoseliziario 7y ago
Exactly. An implementation of an API is copyrightable. Not the API itself. With a lot of goodwill, with some very generous interpretation, an API could be patentable, but copyrightable seems absurd to me.
smadurange 7y ago
I don't think the comparison with literature makes sense. API is what defines a software. For instance, if someone copies Microsoft suite full public interface (including the UI which is part of the interface it would be a problem even if the implementation was different). API signature is the UI equivalent for a library/programming interface software. So, I agree with the original commentors concerns here. Oracle's got a point too.
- eqvinox 7y ago
  > API signature is the UI equivalent for a library/programming interface software. It isn't. "A main window with toolbars and an edit area." is the equivalent of the API signature. The layout, icons, ordering, etc. is artistic work of the "how" and copyrightable. (FWIW by your logic, LibreOffice would be violating Microsoft's copyright already and we could only ever have one office suite in the world.)
  - wbillingsley 7y ago
    No, that's not a reasonable interpretation of his comment. Other OO VMs (e.g. dot NET) exist and do not have the Java API. Google's argument is that the API is required to maintain compatibility with Java programs, not bytecode-based VM programs in general.
incompatible 7y ago
The API description of a single function seems too trivial to be copyrightable. All the functions combined could perhaps be covered by a database copyright, but I believe those aren't recognised in the U.S. Thus phone books or listings of television programs are not copyrightable.
- jhanschoo 7y ago
  What Oracle has won on is in the Structure, Sequence, and Organization in the API. The analogy with phone books is if someone else published a competing phone book, with the same positions for adverts and paid listings, and same distinctions between adverts and paid listings. The courts would find that such a phone book infringes as well. To make the analogy more accurate, many consumers have since come to be used to the layout of the old phone book, and do not want to switch because they have to retrain their habits to use the competitor book. Competitor book argues that the old phone book layout has merged with the idea of a phone book, or that the old layout is essential to the use of a phone book. The circuit court disagrees.
  - zucker42 7y ago
    I think the phone book analogy still falls short; two phone books can be organized different and have different adverts, styles, etc., but still fulfill the same function (allowing a reader to look up the phone number associated with a person or business). On the other hand, two APIs with different SSO do not fulfill the same purpose, since programs must be written to use one API or another. It's much more similar to recipes. Recipes, like programs, are functional; they exist to produce useful output. Two different recipes calling for different ingredients/proportions can be used to bake similar cakes. However, the two cakes are fundamentally different, and copying the ingredients/proportions/steps of a recipe might be the only way to produce a cake quite as tasty as the one from the recipe. Recipes themselves are not copyrightable because of the idea-expression divide. Authors can express the recipe using different words/formatting, and that expression is copyrightable. Likewise, an API, including the SSO, is merely an idea and so can't be copyrighted, while the implementation is the expression of that idea and so can be copyrighted. I think if we take the phone book analogy to it's logic conclusion, it must be okay for Google to use the API only if they change it to make it sufficiently non-interoperable, which seems highly unintuitive.
wbillingsley 7y ago
> An API doesn't implement anything, it describes a function. Unfortunately, that is also a definition for the whole of programming: describing functions. In Java, the method signature gives only a very incomplete definition, but that is a factor of the programming language itself. For example, you might wish to imagine a hypothetical language that has a type system so refined that the behaviour of any function is completely described by its type (1). In such a case there would be no difference between its description and its implementation. (1) We'll leave aside the question of whether this is strictly possible. It would be possible to have more powerful type systems than Java's, and program designs that use such small and clear function definitions, that if you have the type signatures then filling in the code for them is more straightforward than designing the function definitions was in the first place.

marcoseliziario 7y ago

Exactly. An implementation of an API is copyrightable. Not the API itself. With a lot of goodwill, with some very generous interpretation, an API could be patentable, but copyrightable seems absurd to me.

smadurange 7y ago

I don't think the comparison with literature makes sense. API is what defines a software. For instance, if someone copies Microsoft suite full public interface (including the UI which is part of the interface it would be a problem even if the implementation was different). API signature is the UI equivalent for a library/programming interface software. So, I agree with the original commentors concerns here. Oracle's got a point too.

eqvinox 7y ago
> API signature is the UI equivalent for a library/programming interface software. It isn't. "A main window with toolbars and an edit area." is the equivalent of the API signature. The layout, icons, ordering, etc. is artistic work of the "how" and copyrightable. (FWIW by your logic, LibreOffice would be violating Microsoft's copyright already and we could only ever have one office suite in the world.)
- wbillingsley 7y ago
  No, that's not a reasonable interpretation of his comment. Other OO VMs (e.g. dot NET) exist and do not have the Java API. Google's argument is that the API is required to maintain compatibility with Java programs, not bytecode-based VM programs in general.

incompatible 7y ago

The API description of a single function seems too trivial to be copyrightable. All the functions combined could perhaps be covered by a database copyright, but I believe those aren't recognised in the U.S. Thus phone books or listings of television programs are not copyrightable.

jhanschoo 7y ago
What Oracle has won on is in the Structure, Sequence, and Organization in the API. The analogy with phone books is if someone else published a competing phone book, with the same positions for adverts and paid listings, and same distinctions between adverts and paid listings. The courts would find that such a phone book infringes as well. To make the analogy more accurate, many consumers have since come to be used to the layout of the old phone book, and do not want to switch because they have to retrain their habits to use the competitor book. Competitor book argues that the old phone book layout has merged with the idea of a phone book, or that the old layout is essential to the use of a phone book. The circuit court disagrees.
- zucker42 7y ago
  I think the phone book analogy still falls short; two phone books can be organized different and have different adverts, styles, etc., but still fulfill the same function (allowing a reader to look up the phone number associated with a person or business). On the other hand, two APIs with different SSO do not fulfill the same purpose, since programs must be written to use one API or another. It's much more similar to recipes. Recipes, like programs, are functional; they exist to produce useful output. Two different recipes calling for different ingredients/proportions can be used to bake similar cakes. However, the two cakes are fundamentally different, and copying the ingredients/proportions/steps of a recipe might be the only way to produce a cake quite as tasty as the one from the recipe. Recipes themselves are not copyrightable because of the idea-expression divide. Authors can express the recipe using different words/formatting, and that expression is copyrightable. Likewise, an API, including the SSO, is merely an idea and so can't be copyrighted, while the implementation is the expression of that idea and so can be copyrighted. I think if we take the phone book analogy to it's logic conclusion, it must be okay for Google to use the API only if they change it to make it sufficiently non-interoperable, which seems highly unintuitive.

wbillingsley 7y ago

> An API doesn't implement anything, it describes a function. Unfortunately, that is also a definition for the whole of programming: describing functions. In Java, the method signature gives only a very incomplete definition, but that is a factor of the programming language itself. For example, you might wish to imagine a hypothetical language that has a type system so refined that the behaviour of any function is completely described by its type (1). In such a case there would be no difference between its description and its implementation. (1) We'll leave aside the question of whether this is strictly possible. It would be possible to have more powerful type systems than Java's, and program designs that use such small and clear function definitions, that if you have the type signatures then filling in the code for them is more straightforward than designing the function definitions was in the first place.