Post by lkcl .let's look for example at the microsoft NT Domains and Exchange 5.5
network traffic that i reverse-engineered (for zero monetary reward)
over a three year period in 1997-1999 and in 2001/2005 respectively.
I don't understand why you're bringing up reverse-engineering. Google
never claimed to have reverse-engineered anything in this trial. Where,
and I mean this sincerely, do you get the idea that reverse engineering
is at all applicable?
Please reference:
'As the former Register of Copyrights of the United States pointed out
in his brief amicus curiae, “[h]ad Google reverse engineered the
programming packages to figure out the ideas and functionality of the
original, and then created its own structure and its own literal code,
Oracle would have no remedy under copyright whatsoever.”'
Which is directly from the appeals court. This has nothing at all to do
with reverse-engineering, except that, as noted, Google didn't reverse
engineer anything. Nor, in any filing, and I include the appeal to the
SCOTUS, does Google claim to have reverse engineered anything. If I'm
incorrect, please point me to a document. I might be right, I might be
wrong.
I'm baffled as to why you believe this is related to reverse engineering
-- the former Register of Copyrights is very clear that it's unrelated
to reverse-engineering. Do you disagree with that assessment by the
former Register? If so, what's your basis for such an assessment?
Where does this notion come from, that this case hinges on reverse
engineering an API?
Post by lkcl .a) the modifications (and significant and *necessary* technical
improvements) that microsoft had made to DCE/RPC.
b) the implementation of NetBIOS over TCP and UDP
c) the implementation of NetBIOS *services* over TCP and UDP (yes
there are such services: NetBIOS has the concept of "ports" just like
UDP and TCP, so there are several - undocumented - NetBIOS services).
d) their extensions to the SMB protocol (which have a long and
chequered history going through IBM, Xenix, SCO and many other
contributors)
e) their extensions to the LANMAN protocol (originally i believe by IBM)
f) their implementations of around 15 to 20 *separate and distinct*
MSRPC services (such as winreg, lsass, NETLOGON, spoolss, srvsvc and
so on) each of which may be considered to be an API in their own right
(MSRPC aka DCE/RPC basically provides networked access to future-proof
extensible c style functions *as if* they were local APIs. note the
key word "APIs" here)
yes, API, ok. These were reverse engineered? If so, how is that at all
relevant?
Post by lkcl .g) their implementation of MAPI which had its own special RPC format
(it came from a 3rd party company that MS bought a long time ago, and
was originally sent over TCP/IP. later it was proxied over an MSRPC
stream so gained authentication, encryption and so on. kinda cool).
all of these things can - and are - considered to be APIs. they are
basically Remote Procedure Calls (APIs) where the data over-the-wire
is merely a marshalled format of the API.
And anyone could, and still can, reverse engineer any API. The appeals
court, as clearly as is possible, explains how to work-around copyright
of an API: reverse engineer it.
Post by lkcl .the implementation of such RPC services comprises both an RPC layer
(a means to translate the APIs into a network stream) *AND* an actual
implementation of the APIs themselves. the RPC "layer" merely divides
the API so that its caller is in one process (potentially even on
another computer over a network) and the calle is in another process.
in fact, a case could be made that even JSONRPC services, XMPRPC
services, SOAP services (the basis of .NET inter-process
communication) - *ALL* of these would now become copyrightable APIs.
world-wide that's ENORMOUS.
Ok..."copyrightable API's", I'm with you. For these API's, have they
been reverse engineered? I ask because that work-around exists.
Post by lkcl .just for the microsoft reverse-engineering alone, under the new
ruling, all the efforts made by many people for *years* in pursuing
both the U.S. Dept of Justice and the EU Monopolies and Mergers
Commission, would be completely and utterly wasted.
You mean that the API's weren't reverse-engineered? or that that the
already were? It's not clear, when you write "for the microsoft
reverse-engineering" whether you mean for future or past
reverse-engineering.
Because, again, if they were already reverse-engineered, and please do
let me know whether you agree or not, the appeals court clearly states
that it's ok to reverse engineer.
Post by lkcl .you would no longer be permitted to work on or use Wine, because Wine
also contains implementations of the IDL files (the MSRPC services)
and nor of MSRPC.itself.
Why? Wine is reverse-engineered, at least according to Wikipedia. You
assert this, but offer no logic. Reverse engineer is allowed under the
decision by the appeals court, and Wine is reverse engineered. What's
the problem?
Post by lkcl .you would no longer be permitted to work on or use Samba or any of
its services.
While wikipedia doesn't state that Samba was reverse engineered, the
description fits more with:
'As the former Register of Copyrights of the United States pointed out
in his brief amicus curiae, “[h]ad Google reverse engineered the
programming packages to figure out the ideas and functionality of the
original, and then created its own structure and its own literal code,
Oracle would have no remedy under copyright whatsoever.”'
than:
'Instead, Google chose to copy both the declaring code and the overall
SSO of the 37 Java API packages at issue.'
and
'The compatibility Google sought to foster was not with Oracle’s Java
platform or with the JVM central to that platform. Instead, Google
wanted to capitalize on the fact that software developers were already
trained and experienced in using the Java API packages at issue.'
I'm neither a lawyer nor an engineer, but those seem very different to
this layman. Do they seem the same to you? One is for the **purpose**
of interoperability, and involves figuring out ideas and functionality,
while the other is, at best, of a weak sort of interoperability:
"And so all these Android phones are going to be incompatible." -James
Gosling
and the intention is more to capitalize, literally, monetarily, on a
popular API, rather than compatability.
Surely you see a difference?
Post by lkcl .you would no longer be permitted to utilise or work on the Firefox
Web Browser, because it has implemented a near-identical copy of the
Microsoft COM protocol named XPCOM (badly, it has to be said. they
stupidly left out co-classes and this has caused a *severe* amount of
trouble for over a decade both internally as well as in the c++
community where gecko / xulrunner are used in 3rd party products). to
implement a near-identical copy of XPCOM they *also* needed to
implement a similar system to DCE/RPC (MSRPC) but they left out the
networking, and many of the implementation details are different
***BUT*** the point is that at the ****API***** level they have
*EXACTLY* the same functions as COM (minus, stupidly, co-classes).
they even implemented a Registry (because COM requires a registry, so
XPCOM also has one).
so DO YOU UNDERSTAND. you would NO LONGER BE PERMITTED TO USE ANY OF
THIS SOFTWARE BECAUSE THE APIs WOULD BE COPYRIGHTED.
the fact that the API's are copyrighted isn't any different than now,
correct me if I'm wrong. What's the actual, literal, exact difference?
While you write that it's not possible to work on those API's, that's
just an incorrect reading of the actual decision by the appeals court.
Where do they write or imply that? To the contrary, they take the time
to spell out exactly how to work on such a copyrighted API.
Post by lkcl .in the case of firefox that is hundreds of millions of people
suddenly hit. the mozilla foundation and the mozilla corporation
would be open to huge liability overnight for distributing
illegally-licensed software via its downloads section.
You haven't supported this idea, at least not in a way I understand.
Did mozilla try for non-compatability? That's what the appeals court
says Google did:
'Indeed, given the record evidence that Google designed Android so that
it would not be compatible with the Java platform, or the JVM
specifically, we find Google’s interoperability argument confusing.'
I don't think so. I think both in intent and methodology, what Mozilla
did was very different from what Google did.
If you think that the methodology, or intentions, were the same, please
do be specific -- I'm interested in the details.
Post by lkcl .in the case of samba that is millions of businesses impacted with
demands for API license extortion fees.
While wikipedia doesn't go so far as to say that Samba was reverse
engineered, it certainly wasn't copied like this:
'Instead, Google chose to copy both the declaring code and the overall
SSO of the 37 Java API packages at issue.'
and the intentions were very different from Google's:
'Instead, Google chose to copy both the declaring code and the overall
SSO of the 37 Java API packages at issue.'
The methods and intentions are very different...right?
Post by lkcl .in the case of wine that is... i don't honestly know what the reach
of wine is, but it has to be millions of people who would be exposed
to extortionate API "license" fees, and they would have to consider
terminating the use of the thousands of programs that work under the
GNU/Linux Operating System and consider turning to proprietary
Operating Systems.
No. I mean, just, plain, no. Wine is reverse engineered, and, in very
clear language, the appeals court wrote that it's permissible to
reverse-engineer software, including API's.
Post by lkcl .they might even consider turning to qemu in order to run those
proprietary Operating Systems (such as Windows) in order to run that
Operating System (which they of course would have to pay for). but,
there could potentially be a case made that the emulated execution of
the machine code instructions could be considered to be an *API* by
the original copyright holders of those machine code instruction sets,
leaving them AGAIN liable to potential demands for extortionate
"license" fees - just for using qemu or other virtual machine
execution software.
Might Qemu fall in the neighborhood of:
"...reverse engineered the programming packages to figure out the ideas
and functionality of the original..."
because, based on the website, it sounds alot closer to that than
something along these lines:
"...Google chose to copy both the declaring code and the overall SSO of
the 37 Java API packages at issue."
The appeals court distinguishes between these types of activities,
that's mainly what they seem to write about in their decision -- it
makes an interesting read.
Post by lkcl .which also reminds me that other virtual machine interfaces such as
XEN, VMware - all those and their associated tools - would also be
considered to have "APIs" that would also be now "copyrighted".
I ask because I don't know -- are these reverse engineered?
Post by lkcl .in the case of Microsoft .NET services (because they use SOAP) or in
the case of direct SOAP services millions of businesses world-wide
would need to suddenly deal with the massive burden of worrying about
whether their SOAP interoperability layer is properly legally licensed
because it is an implementation of an API.
It's totally permissible to implement an API for the purpose of
compatability:
'...permitted to reverse-engineer and circumvent its protection if this
is necessary in order to achieve "interoperability"...'
that's right from wikipedia. So, it's just incorrect to say that it's
not possible to interact with SOAP or some other protocol, in fact,
there's, as near as I can tell, an explicit exemption. All that the
appeals court does is seem to start from that point, that there's such
an exemption, and then consider whether Google complied or not.
Do you see the situation differently?
Post by lkcl .in the case of JSONRPC, XMLRPC and other web-based RPC services,
millions of businesses world-wide and *every* software libre developer
in the world who has ever developed a web-based RPC service,
interoperable client or server, would suddenly now need to be
concerned that the API that they have implemented is properly legally
licensed.
Yes, and, for the purposes of compatability, see above, it's still
allowed...also, see wikipedia on reverse engineering -- which is
compatible with the appeals court decision.
Post by lkcl .one other thing: software libre developers would also be burdened with
the additional task of issuing a LICENSE to use their API! by
default, copyright law DEMANDS that you, the copyright holder, issue a
license. if you do not issue a license then the default is that
nobody may use the copyrighted work *without permission*. you KNOW
this.
No, that's not the case at all. I know that's your assertion, but it's
not backed up by anything actually written in the decision by the
appeals court. Nor, I hazard to guess, is such an interpretation to be
found on a blog by a lawyer. if so, please do let me know.
The GPL specifically allows the use of an API, and, what your describing
sounds like what I understand to be the LGPL; that to use a
library/API/SSO/etc is allowed. Now, if you start copying that API,
don't make a compatible version, don't try to "...figure out the ideas
and functionality of the original...", then, I would say, hey, don't
copy it. Would you disagree and say, sure, go ahead, copy/paste the
API, write your own implementation, and, while you're at it, change it
from GPL to a proprietary license?
Because that's the clear implication:
'Though the trial court did add the caveat that it “does not hold that
the structure, sequence and organization of all computer programs may be
stolen,”'
To make that statement concrete, that means take a GPL'ed API and,
literally, just copy the signatures, and make it proprietary. In fact,
you can copy some or all, and don't even need to worry about
interoperability. Wow.
Post by lkcl .but... because APIs would now be *added* to that, the simplest way to
cover it would be to create a new version of the GPL that explicitly
covers APIs, and have everyone in the world upgrade all software to
the GPLv4.
even microsoft is not exempt from altering the agreement that they
made the IDL files of the MSRPC services available under, because
their license will (i surmise) cover the use of the *IDL FILES
THEMSELVES*, *NOT* the underlying *API* that the functions *WITHIN*
the IDL files represent.
even facebook and any other company providing developer access to
their services would be put to enormous trouble because they have an
RPC layer on top of which access to their **APIs** are provided.
yes, I get where you're going. Again, this goes back to the purpose of
compatibility, the intentions of Google, as well as whether or not they
simply copied or tried to figure out the "...ideas and functionality of
the original..." or not. Those are some important distinctions you
don't discuss.
Post by lkcl .oh. and, not least: because all of the GNU/Linux software libre
distributions would suddenly be distributing binary implementations of
unlicensed APIs (both networked, dynamic and statically-bound), they
would *ALL* be liable for knowingly-infringing of copyrighted material
(APIs), and could be subjected to DMCA cease and desist notices as
well as being required to pay huge extortionate compensation costs to
the "poor old creator of the API'.
I would say not, because, and I'll just go out an a limb here, that
those API's weren't copied in the way Google copied Java, that intention
wasn't incompatibility, and that there was an attempt to understand the
original.
Three points, all important, all discussed at length by the appeals court.
Post by lkcl .likewise any business or individual running a mirror (public or
otherwise) of any GNU/Linux software distribution would also be
liable. i know of several busineses that have legitimate and
important business reasons for keeping an internal mirror of GNU/Linux
distributions as they maintain remote auto-upgrading systems for
hundreds of clients where they need to "pre-vet" the upgrades before
they are rolled out. their business would - apart from now needing to
license the actual APIs being used - be *severely* adversely impacted
if they had to add additional extortion costs just for running
mirrors.
let alone the burden of going through what... 30,000 packages, just
to check if they have APIs???
You're jumping ahead to a hypothetical. There's a big if. You're ignoring:
1.) intentions
2.) compatibility
3.) copy versus understanding
all three points are well documented in the actual decision by the
appeals court.
Post by lkcl .the irony is that this would be so incredibly disruptive - world-wide
- that *oracle themselves* would actually be significantly and
massively adversely impacted. their greed in pursuing this matter is
just... quite literally insane.
Oracle's greed, and whether or not Ellison is a jerk or not, are
irrelevant, wouldn't you say? This is about the wider implications.
Whether Google or Oracle win $ -- well, who cares? Obviously the owners
and employees of the companies, but it has nothing to do with this
discussion.
Post by lkcl .is that of sufficient importance and magnitude for you to comprehend
the significance here, and how incredibly disastrous it would be for
APIs to become copyrighted. not just for software libre but for *ALL*
software users and businesses.
if there is anything above which is unclear *please ask*. this is *important*.
l.
I agree, it's important. That's why I asked.
Now, I must point out, in that huge e-mail of yours, not once did you
quote the decision by the appeals court. Did you at least glance at the
decision by the appeals court?
-Thufir