Oracle lawyers attempt to stress creative value of Java

Oracle lawyers attempt to stress creative value of Java

Summary: Technical intricacies are important in Oracle's legal battle against Google over intellectual property, but conveying a creative value resonate more with the jury.


SAN FRANCISCO -- Oracle's legal team is doing is hardest to prove the value of specifically Java APIs in its ongoing intellectual property trial against Google.

Oracle started off proceedings on Thursday morning at the U.S. District Court in San Francisco by bringing Mark Reinhold, chief architect of the Java platform group at Oracle, back to the stand to explain the complexities and relationships between Java APIs, class libraries and the Java language.

See also: APIs take center stage at Oracle-Google trial

While the technical intricacies are vital to this case, much of it could have easily gone over the heads of the jury and anyone else in the courtroom who is not a professional Java programmer.

To really strike a chord with the jury, Oracle might have better luck going after a concept that most people understand: creative value.

Oracle lawyers called up current Google software engineer Joshua Bloch to attempt to solidify this argument.

Bloch served as a senior staff engineer and a distinguished engineer at Sun from 1996 to 2004. Considered to be one of the architects of the Java platform, Bloch published a book about the technology, Effective Java, in 2001.

Bloch was hired by Google in July 2004, with the "courtesy title" of chief Java architect. Asked by Oracle attorney Michael Jacobs if he has been called a "Java guru," Bloch affirmed this, but clarified that this is not just by Google employees but rather "many people have called" him that.

When he arrived at Google, Bloch initially worked on Java infrastructure within Google, writing APIs and implementations for those APIs. He then joined the Android team around late 2008.

Prior to joining the Android team, Bloch asserted that he had no involvement with Android.

When asked by Jacobs if he "wrote APIs for many Java class libraries" while at Sun, Bloch affirmed this to some extent, replying "many but not most." Instead, Bloch said that he assisted a junior engineer and helped proof them.

Jacobs brought up a presentation that Bloch has offered at the JavaPolis conference in Belgium in 2005 called, How to Design a Good API and Why It Matters.

Essentially, Jacobs walked through Bloch's presentation, highlighting points that defend the creative (and therefore, monetary) value behind APIs.

The title slide declared that "APIs can be among a company's greatest assets," followed by adding that APIs "can also be among company's greatest liabilities."

"Writing a program is very much a creative process," Bloch said on the stand, explaining that if you have and use really good words, the program will read like English text.

"If you get the name right, all of a sudden it will suggest things that should and shouldn't be in the API," Bloch added. He also warned that if an API is designed badly, it can be impossible to build a good program around it.

Yet, Bloch pointed out that, at that time at least, typically only people who considered themselves to be API designers really cared about APIs.

Finally, Jacobs highlighted the conclusion on the final slide, reading "API design is a noble and rewarding craft" and that it "improves the lot of programmers, end-users, companies."

Bloch asserted without hesitation, "Yes, I certainly believe that."

This is where Jacobs led Bloch down a slightly hazy path for Bloch, calling into question his priorities regarding creative value and copyrights.

Jacobs asked if Bloch was accessing codes from Sun while working at Google -- specifically in reference to designing Timsort code, an algorithm used to sort arrays in both Java and Android.

On the stand, Bloch said he couldn't recall. But when Jacobs brought up a video of Bloch's deposition in July 2011, he did say he wasn't sure, but he added that he was "perfectly willing to believe that I did."

Bloch replied on the stand that he didn't write Timsort for Google, but rather wrote it while he was at Google, which Bloch described as "an important distinction."

Nevertheless, Jacobs questioned Bloch about whether or not he had copied signature codes from the time he worked at Sun to later at Google. Bloch affirmed that he could have.

Bloch also affirmed that he knew that Sun copyrighted code during the time when he worked there.

Nevertheless, when cross-examined by Google's counsel, Bruce Baber, Bloch explained that there is also room for creativity when reimplementing an existing API, and that the API does not limit nor does it tell the engineer how to write that code.

That last part possibly helps out Google's argument in the case that Google engineers had a fair use case when using Java technology when building Android, being creative and effectively repurposing the original products.


Topics: Google, Android, Mobile OS, Oracle, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • again, Oracle is trying to redefine what copyright is

    in order to milk money out of innovators from Google.
    The Linux Geek
    • Or...

      What about getting money back because of the first innovators at Sun?
  • Copyright law

    There is currently no law that allows for copyright of APIs. Oracle is asking for new law. The APIs in question were taken from Harmony. Why is that never mentioned in these articles though it has been mentioned several times in the courtroom?
  • The API itself is worthless...

    And can/should not be copyrightable.

    The IMPLEMENTATION of an API can be valuable, and can be copyrighted.

    The SPECIFICATION of an API can be copyrighted... But that does not prevent an independent reimplementation from being created, and does not infringe the original API implementation.
  • APIs should be copyrightable

    I have built software libraries before and deciding what to expose in my library, how to name classes/methods, arguments, takes a lot of creative effort. The APIs determines the purpose of the library itself. When you have the API, you're just filling in the blanks, the method basically writes itself.

    With an analogy, we can possibly demonstrate why APIs should be copyrightable. With a book analogy, the DLL would be the book, the API would be the story outline. The story outline tells you the contents of the book without telling the story itself. Now for books, copying the story outline is copyright infringement , whether it is the same for APIs, may be determined by this case. If this analogy is flawed, please tell me how because it has me convinced.
    • so

      So people should be prevented from creating something similrt to your libraries? If you were the first person to design bar charts for computers no one else should be allowed?
      • If you copyrighted the bar chart concept..

        Very possibly, some company already has a patent on the bar chart technology.

        Of course, in most countries, you can only patent an concept AND a method.

        With regards to APIs, the API describes the concept. Yu can have an copyright on the concept, of course. This does not prevent anyone else from using your idea and create their own concept that is very similar (but not identical) and thus have an derivative of your library. It all then depends upon the license under which the original work is published.
    • Code never writes itself!

      [quote]When you have the API, you're just filling in the blanks, the method basically writes itself.[/quote]
      Then your API must have been for something trivial. I [b][i]defy[/i][/b] you to implement the Java APIs yourself. Or perhaps you'd care to try implementing a version of the Win32 API instead? Surely the code just "writes itself"...?

      Your book analogy is a straw-man argument, but even books have unprotectable elements. Ideas cannot be copyrighted.

      For example, consider this plot idea:

      [quote]Boy learns magic to fight Evil Wizard who murdered his family.[/quote]
      This is not copyrightable. If it were then George Lucas would have sued J.K. Rowling for infringing the plot of "Star Wars: A New Hope" with her "Harry Potter" books.
      • I may have oversimplified

        I'm just pointing out that the name, inputs and results of a function are dictated by the API. Its just getting from point A to point B. Getting from point A to point B might not be as trivial as you characterize me as saying, but there only so many ways to sort a list for example. I've worked in places before where in one, I had to create my own specification, and in another, where the specification is already provided for me. It's faster to work with a specification. But if I had to create it on my own, I tend to get creative, and there would be refactorings, all of which takes it longer to complete the task.

        Your example, as was mentioned in my link, is an example of an idea that cannot be copyrighted because it is too generic and I agree with that. However, if the boy in your story is named "Harry Potter" and the evil wizard is named "Voldemort" all set in "Hogwarts", you will run into legal issues (I realize those names may be trademarked but assume they aren't for the purposes of this argument). In this case, Google copied the names of classes, functions, packages in their Android API.
      • A function name, arguments and return type are "bare bones" information.

        The name, arguments and return type are the information you need to invoke the function, and yes, a well-defined API should specify the output properly as well. But this doesn't tell you how to implement the function, and some implementations will always be better than others.

        [quote]But if I had to create it on my own, I tend to get creative, and there would be refactorings, all of which takes it longer to complete the task.[/quote]
        Your refactored code would be part of the implementation. It would therefore be independent of the API definition and also covered by existing copyright law.

        In my experience, programmers tend to pattern APIs after other APIs. This makes them easier to understand and use by other programmers. Unless everyone were suddenly forced to make their APIs as different from each other as possible for fear of being sued for breach of copyright, of course.
  • If Oracle wins, everyone has to pay?

    So correct me if I am wrong, if Oracle wins, all people that create and execute code using the system libraries had to pay royalties to Oracle?
    • You are wrong :)

      Of course, nothing changes for anyone with regards to Java, except for Google. Google will have to admit they have done wrong, they will also admit, that Android indeed may be "stolen product". This is why they don't want to admit anything. Because, if they start with Java now, there will be many more lawsuits that highlight other Google "don't be evil" (as in "don't shoot us if you see we rob you") cases.

      Java is free for anyone to program and use (developers and end users). You don't need any kind of license for this.
      Java has an SE (desktop, server) version, that is licensed under LGPL and is therefore free for anyone to bundle with their (closed source) software.
      Java has an embedded version, that is licensed under GPL. What this means is, that if you modify it or bundle it with your code, the result (Java AND your code) must be licensed under GPL. This is something Google could have done with Android, but they decided to keep Android closed source and proprietary. In this case, Java is still free.
      Google could also opted to license the Java APIs, and build their own implementation. This is again FREE (as in, no money involved). They would only have to certify their code that it conforms to specifications. Google didn't chose to d this either. Perhaps, because the certification will require them to call the result "Java" and that it would have had to be binary compatible with Java.

      About the only case when you need commercial license, is when you want to take Java and embed it with your non-GPL code for use on non-desktop and non-server environments. Then, you have to pay Sun/Oracle perhaps for every device where this code is used. Google didn't chose this path either.

      What Google did was to "borrow" (as they do with everything) the Java language, APIs, class libraries and development tools, rename all this to "Dalvik" and modify the compiler to generate incompatible byte code. It escapes me why they believed this can go unpunished... perhaps they expected Sun to die an quiet death...
  • What Oracle leaves out

    What Oracle leaves out is like UNIX, JAVA was enhanced by people outside of the people who "owned" java. It is to the point where if all the public domain coding was stripped from java, it would be useless.
    • Why would they?

      The outside contributions are to the GPL Java implementations. These continue to be GPL and there is not going to be any stripping of "public domain" code. Besides, GPL is far from public domain.

      If Java was in the public domain, then Google would not be in trouble. But.. it it not. Never has been.
  • If API's were cars...

    Oracle would claim that no one lese could develop a car that used four wheels and an automatic transmission.

    That is the essence of the argument over the API's
  • The only thing creative about java is the marketing hype

    The cross platform virus, buggy, memory hogging, and ineffective at everything except impressing dumb accountants wanting a cheap project.
    Reality Bites
  • This is just ridiculous

    Sun, who no longer exists, combined C++ and a variety of class libraries (the graphical part appears to be taken from the Zinc Application Framework) into an pre-compiled interpreted platform (like Datapoint's Databus/DataShare). Sun did this to try and unify platforms. If they could convince programmers to write their Windows programs in Java, then those programs would also run on Sun's Unix based hardware without needing modification.

    But of course Microsoft violated the licensing agreement by making their Java implementation have features so that Java written for Windows wouldn't run on Sun. Then Sun got taken over, so the whole goal of compatibility was discarded for greed. Java is dead.
  • That is because the primary reason oracle

    That is because the primary reason oracle has taken legal action is to force google to implement a fully compatible implementation of java. That is what this case is about, not money. Java will probably cease to exist is the long term if companies can create incompatible implementations like google has done. [url=]brain injury attorney[/url]