There was another way to do it: Google could have designed its own API from scratch for Android, rather than reimplementing the Java standard library. Of cours

There was another way to do it: Google could have designed its own API from scratch for Android, rather than reimplementing the Java standard library. Of course, this would have sacrificed two things: compatibility with existing Java code, and familiarity for existing Java developers. However, thanks to the typical game of telephone seen when lawyers and judges discuss technical subjects they're not deeply familiar with, the fact that Android was compatible with large bodies of existing Java code went essentially unrecognized; the courts focused solely on the fact that Android was not compatible with existing Java apps (in their entirety). Therefore the case was decided as if designing an API from scratch would have only sacrificed developer familiarity, not compatibility. Luckily, the Supreme Court decided that even developer familiarity alone is enough to justify reimplementing an API as a type of fair use. (And that is now precedent.) On the other hand, if you're using an API rather than reimplementing it, and it's very clear that compatibility is at issue (i.e. your code would not be compatible with the library you're trying to use if you wrote it any other way), I'd say the case for fair use is much clearer. That said, if some snippet isn't literally the only way to do something, be careful before declaring it too trivial to be copyrightable. In a different part of the same case, a trivial 9-line helper function [1] called rangeCheck, which Google had copied verbatim by mistake, was held to be an infringement. [1] https://majadhondt.wordpress.com/2012/05/16/googles-9-lines/ https://majadhondt.wordpress.com/2012/05/16/googles-9-lines/