undefined | Better HN

0 pointsandrewjl5y ago0 comments

Apologies, I didn't express myself well when writing that. I meant that all API code is embodied practice. Thus API code itself is in no way different from ledger templates at issue in Baker.

Reproduction of an API in its entirety is no different from reproduction of an embedded practice. Any arguments I've seen so far that argued for parts of API code not being embedded practice were not taking into account how API code is used by software engineers.

0 comments

2 comments · 1 top-level

nodamage5y ago· 1 in thread

The ledger templates in Baker are the result of following the instructions from the book. Isn't the correct analogue to the API code the instruction book rather than the resulting ledger templates?

Baker says that if you write a book that contains instructions on how to do something, you might own the copyright to that book, but your copyright doesn't extend to the results of other people following your instructions and creating their own versions of that thing. In the actual case it happened to be ledger templates, but it could have been anything else.

For example, if you write a book that describes in detail how to draw an owl, you own the copyright to that book. If I buy your book and then follow your instructions to draw my own owl, I own the copyright to that drawing, not you. Your copyright over your book doesn't also grant you the copyright to my owl drawing just because I followed your instructions.

If Oracle was only alleging that Google's implementation of Java (their version of the ledger templates/owl drawing) infringed on Oracle's copyright of its Java API (the instruction book), I could see how the reasoning in Baker might apply. But here they're alleging something further: that the API (instruction book) itself has been copied.

andrewjlOP5y ago

> Isn't the correct analogue to the API code the instruction book rather than the resulting ledger templates?

I would say it's the latter and not the former. APIs aren't instructions in and of themselves, they are instruction identifiers. And the instructions they identify correspond to interactions in a working system. If one wanted to recreate the working system, they'd be hard pressed to do so without recreating instruction identifiers. This isn't just an interoperability issue, but also because experienced practitioners have certain expectations re instructions semantics. Those semantics are often unexpressed directly and come from for example their organization into a given module.

> But here they're alleging something further: that the API (instruction book) itself has been copied.

This is where I'm really puzzled. The API is not the instruction book. The API is a method of interacting with an invented system. You cannot use the API in isolation from the system, by itself it's largely useless. You can't take the API, read it, and then be able to use the system. You need the API to use the system as well, by definition it cannot be used without an API. You could say that the instructions and the ledger templates are fused and inseparable here, but that's only in cases where no other documentation exists which is not the case for the majority of system on the level of Java.

j / k navigate · click thread line to collapse