|
|
|
| Authored by: Ian Al on Monday, May 28 2012 @ 02:14 PM EDT |
I was using what seems to be the generally accepted definition of a programming
interface as an interface between two programs.
Allowing pedantry to rule, the Application Programming Interface would seem to
be between the application source code and the compiler. I used that as the
foundation of my point that the labelled code is actually looked for at the back
of the compiler and the source code deals directly with the front door of the
compiler.
A professional pedant would assert that the interface is between one executing
program and another. This is a highly inconvenient truth because that interface
only exists after a number of compilation stages or a range of interpretation
stages. The compiler and interpreter stages have figuratively screwed up and
disposed of the paper on which the computer language source code accessing the
'API' or the 'ABI' was written.
The truth is that neither API nor ABI exist at the stage when two executing
programs are communicating. Although a programming language might have an ABI
made available to it, I suspect that the overt appearance of an 'interface' is
lost once the compiler has generated the executable file format required by the
OS.
The closest word that I can find to describe APIs and ABIs is a metaphor. There
are no programming interfaces, only program interfaces. APIs and ABIs are
written methods of gaining inter-program communication supported by dedicated
programming tools like compilers and run-time environments.
However, the law is the law. If API or ABI are protected by copyright, that
gives the originator a monopoly on communications between those programs using
the interface or part of it. Copyright law does not permit functionality to be
protected or monopolised in this way.
All of which revealed another facet of Oracle's aspirations to me. Your
description of the Java way of doing things helps me detail the point.
As I understand it, the 51 API packages copied by Google are broadly the
functions that java programmers expect to have made available to their programs
on a standard Java language platform. They expect to see them organised in the
manner set by the Java SE API Specification. Many start with java.* and I seem
to remember that some start with javax.*. All of the writings in the
Specification, or rather, the function implementation source code files, are
gone after the first pass through the compiler. Of course, the evidence that
some elements of the 'API' were employed by the source code are still visible in
the class files.
Oracle are saying that they don't want a Java language compiler to have access
to those 51 packages of functions unless it is to write programs running on
their platform. They are saying that they want the functions barred even if the
code eventually linked in by the classloader was never written by them. They
want as many of those thousands of functions as possible prohibited to Java
programmers unless the program is run in the JRE or a licensed JME
implementation.
Copyright is the only legal tool at their disposal to achieve this. That limits
them to 37 packages. They are using copyright to disrupt the foundations of what
Java programmers expect to be made available to them on a standard Java language
platform unless Oracle own the platform implementation. The SSO argument is
Oracle's last ditch legal attempt to create a monopoly on Java language
platforms.
It is all that is left after other aspiring monopolists had their legal
arguments crushed by the courts. I wonder if Judge Alsup is preparing to open a
new door for aspiring monopolists. Or, perhaps he is about to say that there is
no creative expression in the SSO of the API that does not have to be made
freely available to programmers in order to prevent a monopoly being created by
copyright abuse.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | Parent | # ]
|
- Pedantry! - Authored by: Anonymous on Monday, May 28 2012 @ 02:25 PM EDT
|
|
|
|
