> This mixes up the functional aspects of designing methods with the stylistic aspects of API design. Yes, it does mix them up. That's exactly what the merger

> This mixes up the functional aspects of designing methods with the stylistic aspects of API design. Yes, it does mix them up. That's exactly what the merger doctrine is intended to do: the expressive character "merges" with the functional character. From an abstract standpoint it seems that it gives short shrift to the purpose of copyright. But it's necessary if you want to maintain an effective distinction between ideas (including systems and processes) and creative expressions in determining copyrightable subject matter. In practice, if you look hard enough there's almost always some amount of creative originality in any piece of work, no matter how utilitarian it is; originality that by necessity must be copied. (Though Google didn't do itself any favors by stipulating to literally copy+pasting the Java API.) The whole point of the merger doctrine (at least an assertive application of it) is to prevent a court from looking too closely at certain classes of works which, through custom and experience, should be considered as having a principally functional character. And that's why Google was bound to lose on this particular argument, because the experience and wisdom that begat the merger doctrine--that without a robust merger doctrine the distinction between idea and expression cannot be sustained in practice--has been forgotten. As time marches on earlier precedent has receded into the darkness and Feist becomes the first word on the matter; and all Feist really cares about is creative originality. The entire software industry, AFAICT, universally supports the notion that APIs, per se, shouldn't be copyrightable. (Contrast with software patents, where a substantial fraction do disagree.) But show me an actual implementation or API specification where you could with any degree of confidence [in litigation] separate the expressive from the functional character in a way that preserves the principle and allows you to reimplement the API with minimal risk. Ultimately it's really only viable if you have a special rule for APIs. Of course, we still have Fair Use, similarity, and other defenses. But those are far more subjective, involve a substantial amount of litigation, and are generally high risk defenses. Without a bright line rule then as a practical matter people should and will be risk averse. Even if a court might judge a particular work functional, it'll never get the chance to say so. The whole expression-idea dichotomy is a complete fiction. It's certainly not a law of nature. The idea of copyright is rather artificial as well. So it shouldn't be surprising that we will often face such dilemmas and inconsistencies where theory and practice meet. The purpose of the merger doctrine is to give "idea" its due when otherwise "expression" would almost always win out, despite what would be optimal for the promotion of new works. Theoretically the legislature could carve out exceptions, but legislatures suck at that sort of thing, despite what they often teach in law school. More often its the courts, who wrestle first-hand with the ugly technical details and the real-life interests at stake of applying (over years, decades, and even centuries) the abstract concepts, who are best positioned to carve out exclusions or to subtly put their thumbs on the scales to further the ultimate purpose of the law. But, again, this role of the courts is frowned upon today, at least in an area such as this.