decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Indeed, "they all suck" | 388 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Do not conflate source code with byte/object code
Authored by: PJ on Sunday, May 06 2012 @ 04:22 PM EDT
I got it into my head to take a look at UNIX APIs. And I bumped into another package, jdk117, and the release notes include javaRN.text, and here is what I find -- would this not indicate an answer to the judge's question of what is core:
Packages

SCO JDK 1.1.7B is distributed in the following packages:

* jdk117 (size: about 14MB)
* jdk117pls (size: about 39MB)
Package jdk117 includes the essential execution engine of Java, that is, what you need to run Java applications:
* java, the Java virtual machine (JVM)
* appletviewer, the Java Applet Viewer
* basic API libraries
  • language support
  • I/O
  • AWT
  • networking
  • utilities
  • images, media
  • math
  • compression
  • security
* the just-in-time (JIT) compiler

Package jdk117 also includes some Java development tools:

* javac, the Java Compiler
* jdb, the command-line Java debugger
* javah, the C Header and Stub File Generator for native methods
* javap, the Java Class File Disassembler
* javadoc, the JAVA API Documentation Generator
* jar, the Java Archive (JAR) tool
Finally, package jdk117 also includes additional components to support distributed applications and database access:
* Remote Method Invocation (RMI)
* Java Beans (component object model)
* JDBC (database access)
Package jdk117pls is an optional supplement to jdk117 that includes several kinds of additional materials useful in Java development work:
* The Sun documentation which contains a full description of the different parts of the JDK (this documentation is in stand-alone format and is not integrated into documentation browsers);
* Many interesting Java demo applets and applications including some native method demos;
* Debugging versions (_g-suffixed) of many of the commands and libraries.
In addition to Sun's documentation in the jdk117pls package, SCO JDK 1.1.7B provides UnixWare 7 users with documentation integrated with SCOhelp in these packages:
* jdkdoc: Includes JDK API documentation, JDK guide to new features, Sun's release notes, and links to other information, all tailored to the UnixWare 7 platform.

* jdkman: Includes manual pages for the JDK commands; these manual pages are available from the command line as well as SCOhelp.

The JRE Package

Not included with the SCO JDK 1.1.7B distribution material, but available separately from SCO if required, is the SCO JDK 1.1.7B JRE package jre117 (size about 7MB).

This package matches Sun's product configuration of the Java Runtime Environment (JRE). The JRE is the minimum standard Java platform for running Java programs. It contains the Java virtual machine, Java core classes, and supporting files. The JRE does not contain any of the development tools (such as appletviewer or javac) or classes that pertain only to a development environment. It also contains a different configuration, with different file names, of the Java core classes. In addition, it uses the jre command rather than java to execute the Java virtual machine. See Sun documentation for full details or browse jre.html in the JRE installed directory.

The purpose of the JRE package is so that independent software vendors (ISVs) and others can bundle it with their Java application, if desired. That way, the application and the Java version it has been tested on, can be installed together on customer machines, rather than relying on whatever Java version is currently installed on those machines.

This document is copyright SCO 1999, for a time frame, since the judge asked about 1996.

[ Reply to This | Parent | # ]

Indeed, "they all suck"
Authored by: Anonymous on Sunday, May 06 2012 @ 06:41 PM EDT
(I hope that we've agreed Google "could" have eliminated the SSO)

Once you've taken the decision that there is a way to enable your platform to
attract a huge number of developers, Java is the only answer and anything else
does suck (Either in hindsight when you've been sued, or when you're trying to
negotiate a license)

Java (with it's VM) has built in platform security (sandboxing) whereas with the
NDK (I imagine, I've never used it, they advise against it), sure you can code
for android in C/C++, but like all of these 'to the metal' languages the
potential for disaster from coding mistakes is enormous.

Apple manages that problem by being the gatekeeper, Google chose not to adopt
that role, to 'open' the platform, going with a VM minimizes the risks (from
programming errors, not necessarily from malware), as Schwartz(?) said
Microsoft(.net) was the only alternative or roll your own.

Most of the (programming) world speaks Java or at least can understand it even
if they've never seen it before, much as most of the world (can) speaks
English.


The Founding Fathers could have chosen to write the Declaration of Independence
in a brand new language suitable for a new nation, they did not do so.
(Setting aside the usual difference such as color/colour. +disclaimer I am not
a USAian).


Ditto Google, Android/Java.

The 'APIs' in question are little more than new words for the language, their
implementation is expressed using existing words.
('Internet' did not exist when the Declaration was written, 'XML' did not matter
when Java was first developed)

As the story grows the language develops to express new concepts.

An API is only a concept (what does that make a bunch of APIs grouped together)

Everything under java.* is a new word for the language
Everything under javax.* is a new word that is being tried out, or that might
break something if it got put in java.* so it needs to be kept apart (The N
word, java.nio)
Everything outside that is not Java. (as indeed et cetera is not actually
English though frequently used)

Not using the SSO would be like writing the Declaration in Klingon.


Possible, but also extremely stupid.

[ Reply to This | Parent | # ]

Judge Alsup laying a minefield...?
Authored by: Anonymous on Sunday, May 06 2012 @ 08:41 PM EDT
continuing while I'm in a de-constructive mood

Q13, How many questions?
Is there another bomb/trap in here....

A: When discussing use of the SSO in the 37 API packages in Android to achieve
“compatibility,” what exactly are the parties referring to?

B: Is it “compatibility” with programmers who write in the Java programming
language?

C: Or compatibility with pre-existing programs?

D: If so, approximately what percent of pre-existing programs written for the
Java platform are compatible with Android?

E: Is it compatibility with the TCK?

F: Or Java virtual machine?

G: Or java compiler?



For Google?
A: answer B
B: Yes
C->G: don't really care, doesn't matter, not applicable to android

For Oracle?
Yes *all* of the above! none, they destroyed it, they don't have a license, none
of the programs work, they're not compatible with TCK/javac/JVM


Is E: a submarine License minefield?


That's the only time you need a license to use the ideas in the Specification
(if you want access to the IP, which you don't need if your implementation is
independent and not Java)

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )