On Thu, Oct 16, 2014 at 7:16 AM, thufir <[email protected]> wrote: > On Sat, 10 May 2014 12:55:29 +0100, TJ wrote: > >> What are the potential ramifications of the U.S.A. appeals court >> decision in Oracle Vs Google, that APIs are copyrightable and the only >> question now is whether such use is fair-use? >> >> I'm wondering about the specific affect on a GPL licensed project that >> re-implements an API, distributes their code under the GPL, and the >> developers and downstream users exposure to a claim of copyright >> infringement (of the API) for developing and using the F/OSS >> implementation by the original API copyright holder? > > > '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,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard > to see how its method of operation analysis could lead to any other > conclusion.' > > the appeals court seems to have hit the nail on the head. > > I cannot fathom why the FSF is on the side of letting API's get copied, I > mean stolen. Do they not see the result this would have on the GPL? Or, > do they see a larger issue? Or, do they just think that it's not > stealing? It's remarkable that the trial judge and the appeal judge use > a word like stolen, and not "infringe" or other legal mumbo jumbo.
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. the reverse-engineering was at several different levels: 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) 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. 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. 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 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. you would no longer be permitted to work on or use Samba or any of its services. 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. 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. in the case of samba that is millions of businesses impacted with demands for API license extortion fees. 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. 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. 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". 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. 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. 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. 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. 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'. 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??? 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. 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.
