View Single Post
Old 04-09-21, 05:40 PM
Keepin it Wheel
RubeRad's Avatar
Join Date: Aug 2011
Location: San Diego
Posts: 9,849

Bikes: Surly CrossCheck, Krampus

Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 20 Post(s)
Liked 2,053 Times in 1,495 Posts
OK I skimmed the article, not completely thoroughly, but found some good stuff. From Breyer's majority opinion:

The second, less obvious, function is to reflect the way in which Java’s creators have divided the potential world of different tasks into an actual world, i.e., precisely which set of potentially millions of different tasks we want to have our Java-based computer systems perform and how we want those tasks arranged and grouped. In this sense, the declaring code performs an organizational function. It determines the structure of the task library that Java’s creators have decided to build.

This is a great point, and actually one in Oracle's column. Once a great interface is designed, the implementation written to fulfill the guts behind that interface has a much better chance of being great. If the interface sucks, the whole enterprise is doomed. So a quality, usable, robust, well-architected API is a thing of craft and value, even though it's not the implementation itself. Much as a Frank Lloyd Wright blueprint is a purer representation of his creative genius (intellectual property?) than the resulting constructed house itself.

Here, the 'declaring code' is the API, vs the ''innovative implementing code" is what happens inside/behind the API when users invoke API functions

The declaring code (inseparable from the programmer’s method calls) embodies a different kind of creativity. Sun Java’s creators, for example, tried to find declaring code names that would prove intuitively easy to remember. Id., at 211. They wanted to attract programmers who would learn the system, help to develop it further, and prove reluctant to use another. See post, at 10 (“Declaring code . . . is user facing. It must be designed and organized in a way that is intuitive and understandable to developers so that they can invoke it”). Sun’s business strategy originally emphasized the importance of using the API to attract programmers. It sought to make the API “open” and “then . . . compete on implementations.” App. 124–125. The testimony at trial was replete with examples of witnesses drawing this critical line between the user-centered declaratory code and the innovative implementing code....

These features mean that, as part of a user interface, the declaring code differs to some degree from the mine run of computer programs. Like other computer programs, it is functional in nature. But unlike many other programs, its use is inherently bound together with uncopyrightable ideas (general task division and organization) and new creative expression (Android’s implementing code). Unlike many other programs, its value in significant part derives from the value that those who do not hold copyrights, namely, computer programmers, invest of their own time and effort to learn the API’s system. And unlike many other programs, its value lies in its efforts to encourage programmers to learn and to use that system so that they will use (and continue to use) Sun-related implementing programs that Google did not copy.
More about 'attracting programmers':

Google copied those lines not because of their creativity, their beauty, or even (in a sense) because of their purpose. It copied them because programmers had already learned to work with the Sun Java API’s system, and it would have been difficult, perhaps prohibitively so, to attract programmers to build its Android smartphone system without them.
Not sure that's the strongest point there, it basically reduces to 'Google stole it because it was too hard to make something new itself'.

Interesting though that Breyer seems to have understood the heart of the issue so well. "Not a bad description for an 82-year-old Supreme Court Justice (kudos to his clerks and the various parties and amici that briefed this)"
RubeRad is offline