<story><title>Google&apos;s opening slides in the trial v. Oracle</title><url>http://www.groklaw.net/pdf3/OraGoogle-Trial-GoogleOpeningStills.pdf</url><text></text></story><parent_chain></parent_chain><comment><author>ChuckMcM</author><text>Ok a couple of disclaimers first, one I was one of the original Java folks and two, I&apos;ve done expert witness work but not in this case.&lt;p&gt;When Java was still &apos;Oak&apos; there was an interesting, on-going, low level debate about where the &apos;language&apos; stopped and the &apos;system&apos; started. There is a very common analogy in C where C pretty much assumes that there is a &apos;libc&apos; and in libc are functions for doing things like printf().&lt;p&gt;So it was with Java, with the wart/exception that there was no &apos;main&apos; as Java was designed to be the entire environment, not something you wrote in and then passed a binary to a different environment. Sort of like Python in interactive mode all the time. And that lead to the question of &quot;what can a programmer assume is true about the environment?&quot; and the answer was eventually some packages were &apos;core&apos; and had to be present and some where &apos;optional&apos; and might not me. Frank Yellin and James Gosling&apos;s book on the topic was the definitive reference of what was core and what wasn&apos;t.&lt;p&gt;When I was at NetApp (which also used Java (licensed) in their filers) there was an interesting debate with Sun about whether or not one had to pass the compatibility suite to be compliant with the license. Since it wasn&apos;t an exported language (customers couldn&apos;t write Java code to run on the filer) NetApp argued that insuring it could run NetBeans compatibly was unnecessary. Worse (for NetApp) was that they had their own OS and so the port had taken a while and the newer JDK had a lot of changes (none of which were needed) and it became clear the Sun was just operating on a script. Eventually it escalated up to Scott McNealy who quite reasonably understood that if they insisted on that much effort, NetApp would just move to Python or something like it (equivalent internal effort to porting the newest JDK) and voted for &apos;money&apos; rather than &apos;no money&apos;. That the question even came up though really brought home how far Java had moved from its roots of the team arguing to release source, to &apos;the most profitable on a per-unit basis&apos; that Sun was selling in the end times.&lt;p&gt;Looking at the approaches, I think Oracle is going to lose. And I think they are going to lose for the same reason the font guys lost. My fuzzy memory has it as a Letraset vs Apple suit but it may have been Xerox (sad how stuff from 30 yrs ago is so hard to find) which basically concluded you could copyright the &lt;i&gt;name&lt;/i&gt; of a font but you could not copyright how it looked. Hence font names like &quot;Chicago&quot; which look like other more well known fonts. And it is also why you get 250 &apos;free&apos; fonts where the &apos;i&apos; character has the dot hinted slightly higher but is otherwise identical to some Bitstream font. Historically copyright has been offered on the &apos;end&apos; product, not on the &apos;intermediate&apos; product. So you can copyright a game that is written in language X, but not language X. For the language you can only copyright the name, and the implementation. If the new implementation is different (or derived cleanly) you don&apos;t have an recourse.&lt;p&gt;This defense of a &apos;clean&apos; implementation of a specification severing rights to the original has been litigated extensively in the 80&apos;s BIOS wars where IBM published the source code to its BIOS in their technical manuals and then started trying to sue clone makers who re-used the source. Once the BIOS was implemented in a &apos;clean room&apos; where team A (who had the BIOS code) provided specifications to team B who didn&apos;t, then you could completely sever the rights to the code from IBM.</text></comment>
<story><title>Google&apos;s opening slides in the trial v. Oracle</title><url>http://www.groklaw.net/pdf3/OraGoogle-Trial-GoogleOpeningStills.pdf</url><text></text></story><parent_chain></parent_chain><comment><author>psychotik</author><text>The file cabinet analogy is great to explain packages/namespace. Smart.&lt;p&gt;After looking through both opening slides, I have to say Oracle&apos;s seemed to make better/stronger arguments. This case is fascinating, I&apos;m glad that resources are being made available.&lt;p&gt;Also, gotta love &quot;Very limited internal expertise to make smart decisions&quot; on slide 69. I wonder if the slide number being that was just coincidence.</text></comment>