As a software engineer of many decades, and a Ph.D. graduate in computer science, I find the lack of understanding of APIs disturbing. An API is an interface, just like the shape of the holes in a power socket, or the size and shape of a bolt connecting a car's engine to its wheels. It's a means to an end. It's generally not an enormously expressive and creative piece of work. Rather, it's a necessarily functional interconnection which enables a machine to be plugged together.
Elsewhere some programmers have mentioned "int round(float)" as an API. That is an API for rounding a fractional number, and it's a trivial case of someone writing down in a computer language a mathematical function that mathematicians have been writing or describing for centuries, using various words and symbols. Should the mere act of writing it in a computer language as opposed to a spoken language cause that line to gain or hold copyright? To me that's like saying a verbal description of a hex bolt, written years ago, holds no copyright, but a CAD drawing of a hex bolt does, or that the physical item does. For the sake of interoperability, I believe such physical items have traditionally not held any copyright. They're functional parts of a machine, despite any creativity involved in their design. Furthermore, such single API lines are often so trivial that it's hard to see how any copyright could exist in them.
As far as I remember, Oracle wasn't so much claiming that a single line of an API on its own should hold copyright, but rather that the "collection and organisation" of several such lines should hold copyright. APIs are often grouped into modules or classes, so that, for instance, several mathematical functions such as rounding and truncating fractions, square roots and exponentiation and logarithms, etc would all be placed into a Math module or class, while reading and writing files would be placed in a File module or class, and so on. The particular arrangement is somewhat arbitrary, but it may be necessary for a competitor to duplicate that arrangement exactly for interoperability. I believe this is what Oracle was claiming involved some creativity and was therefore due some copyright protection. To me, that's like arguing that putting the carburettor on the left side of the engine and affixing it with hex bolts is a creative choice that no competitor should be allowed to replicate. Yes, the particular arrangement had to be creatively arranged and functionally designed, but for the sake of interoperability with competing manufacturers, copyright should not extend to such interface designs. If it's truly innovative, that's what patents are for. If not, it's just plumbing.
From the point of view of a software engineer, APIs should clearly not hold copyright, any more than a hex bolt should, or an electrical wall socket specification should. I wonder how lawyers, arguing from a dry set of rules, can justify that their pronouncements are valid when they seem so divorced from industry practice. Ultimately, their motivations need to be understood to see why they're pushing the particular interpretations they're asserting. I think this sentence speaks loudly to the CAFC's concerns: "allowing this one factor to dictate a conclusion of fair use in all cases involving copying of software could effectively negate Congress’s express declaration... that software is copyrightable." I can see how the inability to perceive the differences between interface and implementation could lead someone to worry that allowing copying of APIs could unravel the whole copyrightability of software. But there's a clear difference! The implementation specifies what work actually is done, whereas the API is just a way to interconnect that implementation with the rest of the program, and does not itself do the work. As far as I can see, Google did exactly the right thing that has been done many times in the computer industry: a clean room implementation. Copy the APIs, but not the rest of the code, then write your own code implementations which match that API. Either that long-used practice is allowed (good for competition and interoperability), or it is not (protectionism means preventing customers from shopping around). The CAFC seems to be coming down on the wrong side here, and should instead be focussing on defining that distinction between interface and implementation.
I note that Europe explicitly went the other way at the time of the first trial and decided that APIs are not copyrightable. This seems like the only sane solution. At this point CAFC has steered the argument into nonsensical territory and is busily arguing about fair use, whereas APIs on their own should not be copyrightable (and aren't in other parts of the world). In a juridiction where APIs hold copyright, fair use must be the end result. The alternative is that every car and tractor manufacturer can design their own specially shaped bolts and creatively designed APIs to lock out competitors and prevent owners and users from shopping around for after-market parts or using independent repairers or doing self-repair. That's a land-grab from manufacturers attempting to use software as a way to extend monopolies indefinitely. If the law fails to adequately specify the limits of copyright as it applies to machines (and software ultimately is a functional part of a machine, or it has no purpose), then fair use rulings must be the result, to protect competition and the established practice of clean room reimplementations.
On the post: Insanity Wins As Appeals Court Overturns Google's Fair Use Victory For Java APIs
APIs are plumbing
Elsewhere some programmers have mentioned "int round(float)" as an API. That is an API for rounding a fractional number, and it's a trivial case of someone writing down in a computer language a mathematical function that mathematicians have been writing or describing for centuries, using various words and symbols. Should the mere act of writing it in a computer language as opposed to a spoken language cause that line to gain or hold copyright? To me that's like saying a verbal description of a hex bolt, written years ago, holds no copyright, but a CAD drawing of a hex bolt does, or that the physical item does. For the sake of interoperability, I believe such physical items have traditionally not held any copyright. They're functional parts of a machine, despite any creativity involved in their design. Furthermore, such single API lines are often so trivial that it's hard to see how any copyright could exist in them.
As far as I remember, Oracle wasn't so much claiming that a single line of an API on its own should hold copyright, but rather that the "collection and organisation" of several such lines should hold copyright. APIs are often grouped into modules or classes, so that, for instance, several mathematical functions such as rounding and truncating fractions, square roots and exponentiation and logarithms, etc would all be placed into a Math module or class, while reading and writing files would be placed in a File module or class, and so on. The particular arrangement is somewhat arbitrary, but it may be necessary for a competitor to duplicate that arrangement exactly for interoperability. I believe this is what Oracle was claiming involved some creativity and was therefore due some copyright protection. To me, that's like arguing that putting the carburettor on the left side of the engine and affixing it with hex bolts is a creative choice that no competitor should be allowed to replicate. Yes, the particular arrangement had to be creatively arranged and functionally designed, but for the sake of interoperability with competing manufacturers, copyright should not extend to such interface designs. If it's truly innovative, that's what patents are for. If not, it's just plumbing.
From the point of view of a software engineer, APIs should clearly not hold copyright, any more than a hex bolt should, or an electrical wall socket specification should. I wonder how lawyers, arguing from a dry set of rules, can justify that their pronouncements are valid when they seem so divorced from industry practice. Ultimately, their motivations need to be understood to see why they're pushing the particular interpretations they're asserting. I think this sentence speaks loudly to the CAFC's concerns: "allowing this one factor to dictate a conclusion of fair use in all cases involving copying of software could effectively negate Congress’s express declaration... that software is copyrightable." I can see how the inability to perceive the differences between interface and implementation could lead someone to worry that allowing copying of APIs could unravel the whole copyrightability of software. But there's a clear difference! The implementation specifies what work actually is done, whereas the API is just a way to interconnect that implementation with the rest of the program, and does not itself do the work. As far as I can see, Google did exactly the right thing that has been done many times in the computer industry: a clean room implementation. Copy the APIs, but not the rest of the code, then write your own code implementations which match that API. Either that long-used practice is allowed (good for competition and interoperability), or it is not (protectionism means preventing customers from shopping around). The CAFC seems to be coming down on the wrong side here, and should instead be focussing on defining that distinction between interface and implementation.
I note that Europe explicitly went the other way at the time of the first trial and decided that APIs are not copyrightable. This seems like the only sane solution. At this point CAFC has steered the argument into nonsensical territory and is busily arguing about fair use, whereas APIs on their own should not be copyrightable (and aren't in other parts of the world). In a juridiction where APIs hold copyright, fair use must be the end result. The alternative is that every car and tractor manufacturer can design their own specially shaped bolts and creatively designed APIs to lock out competitors and prevent owners and users from shopping around for after-market parts or using independent repairers or doing self-repair. That's a land-grab from manufacturers attempting to use software as a way to extend monopolies indefinitely. If the law fails to adequately specify the limits of copyright as it applies to machines (and software ultimately is a functional part of a machine, or it has no purpose), then fair use rulings must be the result, to protect competition and the established practice of clean room reimplementations.
Next >>