On 11/05/14 17:14, Fernando Cassia wrote:
On Sat, May 10, 2014 at 8:55 AM, TJ<[email protected]> wrote:
>If in creating an interoperable project - let us imagine something akin to
>the Samba developers re-implementing the Microsoft SMB/CIFS and related
>protocols, or the WINE project's reimplementation of the Win32 APIs, or the
>OpenJDK project re-implementing the Java APIs - then the very fact that the
>law assumes that the APIs are copyrighted and a trial on fair-use is the
>only way to determine whether or not there is copyright infringement will
>have the effect of stopping most interoperability projects in their tracks.
When writing about things, it's generally a good idea to first know what
one is talking about.
The key phrase is "...let us imagine something akin to..."; I was giving
examples of the type of project that (re)implements
a significant de-facto industry standard API to achieve interoperability. The
same could apply to cloud services APIs being
re-implemented for cross-service portability as in, for example, Eucalyptus,
OpenStack and CloudStack.
The appeals court decided that the trial court erred in pinpointing the time at
which the creative expression occurred (the merger doctrine).
Until now it has been generally accepted in the development community that this
would be the time at which the interoperable
alternative was created and this was the interpretation the trial court adopted.
The appeals court determined that is incorrect; the correct point in time is when the original expression occurred - in this case, when the Java developers at Sun designed the API. The upshot of that
interpretation means that an interoperability project could not legally create an alternative implementation (in the U.S.A.) on the assumption that the API was not subject to copyright; the only way
to determine legality would be for a trial and the fair-use defence before a Jury.
"Oracle also argues that the district court erred in invoking interoperability
in its copyrightability analysis.
Specifically, Oracle argues that Google’s interoperability arguments are only
relevant, if at all, to fair use
— not to the question of whether the API packages are copyrightable. We agree."
The appeal court further affirmed the trial court's 'scenes a fair' decision in respect of the specific defence Google raised using that doctrine. The EFF (and others) also raised this issue in their
Amici Curiae briefs to the appeals court.
"On appeal, Google refers to scenes a faire concepts briefly, as do some amici,
apparently contending that,
because programmers have become accustomed to and comfortable using the
groupings in the Java API packages,
those groupings are so common place as to be indispensable to the expression of
an acceptable programming
platform. As such, the argument goes, they are so associated with the “idea” of
what the packages are
accomplishing that they should be treated as ideas rather than expression. See
Br. of Amici Curiae Rackspace US, Inc.,
et al. at 19-22."
...
"Finally, Google’s reliance on the doctrine below and the amici reference to it here are premised on a fundamental misunderstanding of the doctrine. Like merger, the focus of the scenes a faire
doctrine is on the circumstances
presented to the creator, not the copier. See Mitel, 124 F.3d at 1375 (finding error to the extent the trial court discussed “whether external factors such as market forces and efficiency
considerations justified Iqtel’s copying of the command codes”). The court’s analytical focus must be upon the external factors that dictated Sun’s selection of classes, methods, and code
— not upon what Google encountered at the time it chose to copy those groupings and
that code."
I see no reason why, on a literal reading of the appeal court's decision, the
same reasoning will not be
applied to, for example, the command-line arguments of discrete binaries,
network protocols in respect of the data structure
symbols and ordering, or 'standards' along the lines of POSIX/SUS.
It seems to impact reverse engineering too, since most black-box reverse engineering techniques aim to observe the external interactions of an executing binary and then write an interface
specification (API) from which a compatible implementation is written in a clean-room environment.
Because copyright terms are so long it seems to me to have the potential to be
far more disruptive than the U.S.A.'s Software Patent problems.
Even for interoperability developers outside the U.S.A. this has major
implications if their software is likely to be imported into the U.S.A.; both
for them and their users.
