There is one place where sequence does matter: within the
signatures of methods that take 2 or more homogeneous parameters. For instance,
a method that looks like this: Object o getObjectFromInts(int i1, int i2), the
output could depend on whether a value is in the first or second position. In
order to implement the method, so that it replicates how someone else
implemented it, I need to see their documentation.
As a practical
concern, the method name of a well designed library will hint to the programmer
the actual order of parameters. After all, a language shouldn't ask a programmer
to look up the documentation every single time a method is used.
I take
it that SSO is not a case where two out of three ain't bad. Well, maybe it ain't
bad, but I suspect it isn't good enough.
Considering your last
point, any copying of protectable creative expression is enough for damages.
It's not like a patent thing where all of the claims have to be infringed.
The
issue then becomes, how much of the creative expression in the whole work was
copied.
I have searched for the appropriate comment without success, but this
anon comment gets me there:Structure, sequence, and organisation.
It's been a concept in copyright of software (not APIs) in the U.S. since Whelan
v. Jaslow in 1986.
Hardmath pointed out that:So far
he's gotten Oracle to box in their claims as regarding the "structure,
arrangement, and selection" of these APIs qua "works of
compilation".
Mark Webbink pointed out that this was the
protection offered to compilations. The bit that I could not find was where
someone pointed out that the three terms were synonymous in the case of
compilations.
However, it does not really matter because the question
is whether the law protects the order of the parameters. Who's to know if the
law calls the order of parameters an arrangement?
The judge has ruled
that functionality, names and short phrases are unprotectable. Oracle gave the
following comments about what the jury should be asked:In this case,
the SSO of the 37 API packages is manifested, in part, in a hierarchy of named
packages, classes, methods, and other elements such as interfaces and fields.
Dr. Reinhold, Chief Java Architect at Oracle, provided the following example
showing the hierarchy of some of the classes in the “java.nio.channels”
package:
java.nio.channels
- Object
- Channels
--
FileLock
-- Pipe
-- SelectionKey
-- Selection
--
AbstractInterruptibleChannel
- FileChannel
-- SelectableChannel
-
AbstractSelectableChannel
- DatagramChannel
--
ServerSocketChannel
-- SocketChannel
To meaningfully evaluate the
SSO of the API packages, the jury will need to consider the named elements as
part of the structure. Without the named elements, the upper portions of the
hierarchy (everything above the method declarations) would be
incomprehensible:
comprehend
v 1: get the meaning
of something; "Do you comprehend the meaning of this letter?"
Your use
of the word 'hint' is relevant. It is not possible to hint at creative
expression fixed in a medium. It is either expressed or it is not. Oracle point
out that the jury need to have this example of the meaning of the API SSO. This
diagram can be found, IIRC, in both a page of the Java API Specification and the
Android help pages.
It is, as I understand it, a diagram produced to
express the meaning implied by lines of text in the source code files, the
actual directory in which class implementation files are put, and the full
inheritance tree that can be derived by understanding the ideas in the
Specification and the organisation of files in directories.
Mark made
the comment that 'Compilations are generally afforded only a thin layer of
protection by copyright'. Oracle point out that the API is not some trivial
thing: it is a highly complex structure with threads of meaning woven
throughout. Does a 'thin layer of protection' truly protect the complex
structure of 37, 164ths of the whole API?
If you make even the
slightest change to the SSO in one tiny part, will the result in that tiny area
stop being functional? If it does, then any and all of Google's SSO copying by
using Harmony code is locked firmly into the functional requirements.
Also, the elements of SSO are not fixed in a media. They have to be
derived by reading the API Specification or the source code of thousands of
files. Oracle cannot point to the collective work or compilation of
java.nio.channels and show the SSO fixed therein. The SSO is in the meanings of
the individual components. It is in the ideas expressed and not in creative
expression fixed in a medium.
Oracle need to prove that the SSO of
java.nil.channels that they expressed in the above diagram could be replaced
with another SSO and that functionality would not be changed in any way. I think
they have not done that and nor do I think it is possible to do
that.
Oh yes, and I Googled your title. Oracle is, indeed, a shining
light of good faith, clarity and honesty when the Invocation process is
applied.
br ---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid! [ Reply to This | Parent | # ]
|
