IBM, Microsoft, a medley of others sing support for Google against Oracle in Supremes' Java API copyright case With America's Supreme Court expected to hear arguments in Google v. Oracle over the copyrightability of software application programming interfaces come March, the search biz's ideological allies have rushed to support the company with a flurry of filings. A week after Google handed its petitioner's brief to the court on …
A win for Oracle here just hastens Java's demise, and any other API definitions not liberally licensed.
When people (and organisations) show you who they are, believe them. A vendor willing to publish an API but not licence it on FRAND terms deserves the reputational hit and neglect that entails.
On the other hand, there may be some utility in being able to control via licensing access to an API. A copyright free-for-all removes that possibility. For example, couldn't the OpenZFS devs could copy the GPL'd kernel API code they need for performance so as get around the GPL? Copyright protections cut both ways, surely.
As I understand it, Google copied and shipped copyrighted source code to implement the Java API, not merely referenced it/included it in order to consume it, the typical use-case most devs would be concerned with.
You don't seem to understand just how damaging this is with 120+ year US-style copyright.
Every single computer interface, even those dating back to punch cards, would be copyrighted.
One or two companies would effectively own all of computing until some time in the 22nd century. And that's a best case outcome. Open source would simply not exist. Portable files would not exist, save perhaps in cases where compatibility was negotiated for a hefty fee and under restrictions that make current DRM look tame.
This entire case is bordering on the absurd, it's almost like copyrighting the dictionary of a language. Sure, you can go make up a new language, but no one will speak it. You've lost before you even started.
If, and only if, the world had embraced 10 or 20 year copyright (to match patent) would your proposal even possibly be an option.
Well, the original source files would be, if the API were published in the form of source code. You could still do a clean-room reimplementation, or choose one of the many that are freely licenced. Or write your own. The APIs that are locked up get ignored. Or, like the Win32 API, flourish anyway.
Or if you're Google, you could buy a license.
I agree copyright terms are far too long (thanks, Disney!), but I don't think that affects the principles at stake here.
The problem is that if you have a compatible API, it's infringing according to how copyright law was interpreted in the last ruling. Even such examples as "round(int)" were brought up in these cases as infringing; that's why I say it's far more like copyrighting a language than copyrighting a work using the language.
And unfortunately the clean room defense lies partly on the previous interpretation of copyright law; i.e. before this last decision. With this decision even that won't hold any more, and if it had been decided that way before the PC revolution we very well might be typing these comments into a green screen terminal on a mainframe somewhere (as IT folk, naturally -- the masses wouldn't have had PCs, let alone network connected ones, in the first place).
In general I can't go watch a movie or read a book, "clean room" write the plot, and have a new book written or movie made with that same plot. It's still considered infringement. That's part of the problem here; if something is similar enough it's still considered "infringing" and the economic costs of this when applied to items that are specifically not copyrightable (interfaces, methods, recipes, etc.) would be staggering. It could make the US a third world country nearly overnight.
And if you're Oracle, and want a monopoly, you simply decide you won't license the software for any sum of money. That's the other problem with copyright, there's no ability to force a rights holder to license anything. For over 120 years.
The only possible silver lining of this kind of disastrous ruling is, if upheld, it would force copyright back down to patent like lengths. Hollywood doesn't hold a candle against the likes of Google, Microsoft, IBM, etc. and they'd probably see copyright upended and thrown out very rapidly (if they even stayed in the US in the first place after a ruling like that).
Icon 'cause extreme hazard ahead, hopefully the court will get it right this time for all our sakes. We all know the US will try to export whatever decision they make worldwide.
This seems to hinge on whether a "clean-room" re-implementation would, by necessity, be a derivative work in order to be compatible, even if not an actual copy. Then the question of 'fair use' for the purposes of interoperability apply. Congress could make the law explicit on this point.
I thought Google (or the co it bought Android to obtain) admitted copying the files, so the clean-room factor not directly at play in this case?
If companies want monopolies on proprietary APIs, we can all switch elsewhere if we don't want to pay or they don't want to charge (although why publish an API if you're not looking for others to use it?); I don't see any legal problems with the standard C++ library (or Boost).
Oracle's point of view is that everything to do with the API is copyrightable, including the function names and the parameters they take. Whether you copy their header files and reimplement or look at the page and write a header too, they consider you equally culpable for infringement. If they win, that means the following:
"clean-room reimplementation": Have you seen the originals? And yours is similar (let alone compatible)? You infringe. Pay up.
"choose one of the many that are freely licenced": Did they copy? Did they see ours before they made theirs? They infringe. They need to pay up, and you need to stop using it or you will infringe shortly.
. "write your own": Is it similar? Do you use the same names and function contracts? Any of them? You infringe. Etc.
If that happens, I'm afraid it doesn't work quite as you specify. You've suggested that "The APIs that are locked up get ignored." That's possible, but what will happen is what happened with Java. It will get released under something that makes it look open until people use it. Then, the hidden loophole allowing changing the terms gets activated.
The only way to avoid it is to only ever use something that is and always was under a very clearly open license. We can do this now, and that's a great thing. But the only reason we can do that is because interfaces weren't copyrighted earlier. We have open implementations of C because AT&T didn't get to charge us. We have most of our OS and more complex language APIs because we had C. It didn't have to be C, but it did have to be something we could use freely. Without that, we wouldn't have very much, as each group trying to innovate would have to stay stubbornly in their own company or research group and not look at or use anyone else's stuff.
A win for Oracle in this case doesn't mean their point-of-view about CRIs or fair-use interop prevails. The precedent value would relate to Google's (Android, Inc.'s) conduct in re-implementing an API without a license.
There are plenty of orgs (W3C, ECMA, ISO, etc.) doing standards work providing for platforms. It's not the end of the world as we know it if either party wins.
Interface code has shipped with copyright notices from earliest days of shared source. Just ask AT&T or the Regents of the University of California. If everyone 'knew' APIs were uncopyrightable, we'd be living in a different world.
The blast radius of that determination would never be limited just to Google Java implementation even if the "in this case" penalty would only apply to Java.
The term here is "it sets a precedent". It is this precedent that then makes any other defined API fall into copyright. It would turn Amazon's API offering into a nest of vipers and they would then, like youtube become liable for promoting copyright violation, and so on.
Don't underestimate the downstream damage, regardless of the specifics in this case.
You are completely ignoring the fact that for more than ten years Sun (the prior owner who was bought out by Oracle) _encouraged_ exactly what Google did: they wanted third parties to use it, in order to increase the range and demand for their Java product.
I certainly don't agree with a whole lot of Google's behavior, but they're in the right on this one.
Yes, and they acknowledged as such. Clearly Oracle waited until they had a big fish wriggling on the hook and they've been trying to reel Google in ever since. But in turn Google can argue some bad faith, since they offered to license and were turned down.
I didn't ignore it; unlike trademarks, a failure to enforce rights under copyright doesn't invalidate them if later asserted. 'Squatters' rights' don't apply.
It's a stretch of imagination for some, but it's possible to believe that one party to a case should win on the particular merits while thinking they should lose on legal principle.
<cite>Interface code has shipped with copyright notices from earliest days of shared source. Just ask AT&T or the Regents of the University of California. If everyone 'knew' APIs were uncopyrightable, we'd be living in a different world.</cite>
You do know there are several types of copyright, don't you? There's the copyright of individual creation; then there's the copyright of lumping a pile of other peoples' stuff together. The second sort is much, much weaker. It's the sort of copyright the likes of Hal Leonard claim over their music score anthologies, most of which were written by somebody else.
Interface copyright, as something concerned with interfaces, which allow others to combine their work with yours, would appear to be of the second variety.
I wonder just how serious Oracle is on this matter, and this case. Oracle are after all, primarily a relational database company. IBM was the first relational database company, and IBM wrote most commonly used database language, namely SQL.
Does Oracle really want to hand the keys to their moneybox to IBM?
Someone should ask the judge that question.
In general I can't go watch a movie or read a book, "clean room" write the plot, and have a new book written or movie made with that same plot. It's still considered infringement.
I was struck between the similarity between teh contents of HolyBlood , Holy Grail, and the DaVinci code when I read it, and was not surprised when Dan Brown was sued by Michael Baigent and Richard Leigh for ripping off the fundamental idea for the DaVinci Code from their Holy Blood, Holy Grail. Dan Brown won.
And since copyright isn't in ideas, but their expression, that's according to how copyright works. Some may argue that creative ideas should be protected like patents for inventions or designs, but originally it was created to provide the necessary but not overly generous incentives to invent or create, without eliminating the public domain.
According to Oracle, APIs do not need to be published in the form of source code. They have a court ruling that makes a clean room implementation copyright infringement unless it is somehow shown to be fair use. Fair use is not a global concept and even where it does exist it has limitations like no commercial distribution or uses less than vaguely 10% of the source material. The boundaries of fair use are sufficiently fuzzy that you can expect nuisance litigation from trolls even when fair use is clear.
... that makes a clean room implementation copyright infringement unless it is somehow shown to be fair use.
Not in this case, surely? The lower courts ruled/juries dismissed Google's fair use claim based on their admission to copying for convenience, not that they'd done a CRI. If you're referring to another case with judgement for Oracle, please cite.
If 'fair use' even with copying for interop turns out to be legally cloudy/high risk after this case, there's a longer term win all 'round, where open standards set by foundations/industry bodies/standards orgs are in the ascendant due to cost / risk factors, rather than vendor proprietary, monopoly solutions (even if freely provided, for now).
Sorry, yes I mixed that up. It was the appeals process that knocked out copying as fair use. It still wasn't a win for Oracle against clean-room re-implementation, the essence of my question. That's why I asked if Flocke Kroes was referring to another Oracle win.
The clean room implementation still has to be an implementation of the API and it's the copyrightability of the API that's the issue.
Why is it an issue? Well, look at a C program. At the top you'll see a lot of #include statements. They're copying various files into your program. What are those files? They're parts of the system's API. The same thing is apt to apply in other languages.
Any program being compiled incorporates at least parts of the API(s) it's written against. To raise any form of copyright issue against those is very worrying for the way in which the entire software industry works which is why pretty well the entire set of big players in the software industry apart from the principles have weighted in with amicus briefs. You should at least consider the possibility that they know what they're doing in spending money on lawyers to do that.
Yes, you need a copy of the header files to compile. You don't need to distribute them, to use the API. Any files you do get a copy of can be copyrighted and licensed to you for the purposes of compilation. There doesn't need to be a blanket exclusion on API copyrights for this system to work. As I said elsewhere, people have been placing copyright notices on header files from the earliest days of C, with no ill effects. This is because licensing is generally liberal, or vendors of libraries by necessity have to allow you to #include if they want you to buy their code.
This is not what Google/Android, Inc. was doing. They copied files to create their own product, and distributed them.
Call me cynical if you want, but I'd say one amici, Microsoft, might be looking for ruling to help them avoid future claims like the one they were forced to settle for similar behaviour with JVM.
Worth noting that the settlement of that case didn't bring software development to a grinding halt. It was almost 20 years ago.
Sun vs Microsoft was around attempting to coerce Java to Microsoft's standard - Microsoft were sued by Sun for failing to implement the standard correctly while still using Java trademarks and Microsoft were fined as a result and discontinued the MS JVM.
I would dispute that the Sun vs Microsoft case mirrors the Oracle vs Google Java case outside of both being based around Java - drawing parallels with the effects on software development for the two cases isn't valid.
If not, the licence would have been un-enforceable. MS could have argued they were free to write their own incompatible implementation of the API and didn't need to comply with Sun's licence. They could have called it something else, I don't know, like "Motlin".
"They could have called it something else, I don't know, like "Motlin"."
This is exactly my point - if MS had called it something else AND not licensed Java from Sun, the lawsuit would have gone in a completely different direction (or Sun may not have found grounds for a case).
Instead the case was about failing to uphold licence requirements for Java as required by the Java licence - it was purely contractual and MS had not complied with those contracts.
Google vs Oracle is the parallel Java universe where Microsoft did the opposite of what they did in this Java universe.
Consider what the basis for the licence was; no API copyright, no license enforceability. I excluded the trademark question by hypothesising 'Motlin'. As MS were writing their own implementation for their JVM, the APIs were all they needed to reproduce for 'compatibility'. But the license applied, because the copyright applied to what they reproduced, viz. the API. They settled.
What I've been trying to illustrate mentioning the MS vs. Sun case is that the copyright treatment of APIs in the case between Google and Oracle is not some new, revolutionary approach that will bring the sky crashing down. The appeals court upheld copyright protection for the Java SE API based on law and precedent (in the 9th and other circuits). Don't take my word for it; read the judgements.
You might disagree that APIs should get any protection in U.S. copyright law, but changing that will most likely be a job for Congress.
The licence applied because Microsoft signed a contractual agreement with Sun.
Microsoft broke that contractual agreement and lost the case.
Google discussed licensing with Sun (prior to their acquisition by Oracle) but instead choose to implement a "clean room" version - we can argue about whether it was a clean room implementation, but as there is no contractual agreement, Oracle couldn't treat this as a contractual issue (that they would have likely won based on the existing MS vs Sun case).
Pretending the Sun vs Microsoft case is about API's or protections for copyright shows a complete misunderstanding of that case. It was simple contractual law which is why Microsoft could only delay the outcome, not affect the result.
If your analogy doesn't fit you must acquit...
Not really - just drop the pretence that the outcome of MS vs Sun correlates to the outcome of Google vs Oracle or gives some insight into how the law views API's.
"Every single computer interface, even those dating back to punch cards, would be copyrighted."
Exactly. A bonanza for lawyers. Not a huge problem for China which seems to regard copyright as yet another crazy round-eye concept that they must occasionally pretend to respect. An utter disaster for US and probably EU computer companies. Even if the lunacy is eventually resolved rationally, the damage will be deep and long lasting.
(Actually, I think perhaps only stuff copyrighted after 1977 has an effectively eternal copyright. But I could be wrong about that.)
Actually... No. Nothing copyrighted before 1928 is still covered. Current law is life plus 70 years for individuals, 95 years for corporations. Blame the Mouse Kingdom for the extensions that have been pushing those out. 1928 is critical date for "Steamboat Willy".
Actually, it's not _completely_ the Kingdom of Mouse's fault.
When the updated copyright was put before congress, it was to align US copyright with European (or world) copyright.
Although, If I were a betting man, I would also wager that The House of Mouse probably left some incentives behind to encourage the homogenizing of copyright between both sides of the pond (in favor of the longer side).
"Not a huge problem for China which seems to regard copyright as yet another crazy round-eye concept that they must occasionally pretend to respect."
Not really. They're just taking a lesson from the round-eye US of the C19th.
Under such a scenario the world as we know it would evaporate in a cloud of sueballs.
Meanwhile, every court in the nation has to revert to a paper based system with Law Clerks and Interns doing Manual Lookup of all legal citations. Every business would be forced back to manual processing of transactions and there wouldn't be enough people with low level clerking skills available to handle all the paperwork. Credit cards? Fugedabout it! Cash or No Sale.
By the third day of the next Supreme Court Session t[if not before] he "Nine" would realize that they stepped on a sensitive portion of the anatomy with Golf Cleats.
IT departments would be furloughing most of their staffs, and until the sueballs were resolved those people would be advised to "learn double entry bookkeeping".
No. Let me give you an analogy.
Oracle run a dog training school. They teach dogs to sit, come, walk to heel, fetch, and so forth.
Google have set up their own dog training school. They also teach dogs to sit, come, play dead, walk to heel, fetch, offer a paw in expectation of a treat and so forth.
Google have shown that their actual training methods are substantively different from Oracle's, but Oracle are now trying to claim that the words "Sit", "Stay", "Come", "Heel", "Fetch", "Say Please" and so forth, used by owners to communicate with their dogs, belong to Oracle.
If Oracle get their way on this, it potentially means that anybody creating a programming language cannot use the word "print" to send some output to the screen, or a file, or a device, without a licence from Oracle.
This is not analogous to the Java API case. Just as common words and phrases are hard to trademark, copyright doesn't subsist in trivialities. In any case, German dogs aren't trained with "sit", "stay", etc. Other words could be used, but regardless a court wouldn't grant copyrights over "print" in one programming language over another; even a complex set of keywords wouldn't be considered for copyright, as mere compilations or lists generally don't get protection, either. (c.f. phone books).
The API isn't just the keywords; it's the signatures, types and defined constants that make up the whole work. Ironically, Google only needed 170 lines of the 11kloc they copied to provide the compatibility.
> This is not analogous to the Java API case. Just as common words and phrases are hard to trademark, copyright doesn't subsist in trivialities.
You can't say that because we don't know how a decision in favour of Oracle might pan out. For example take "java.util.Scanner". Will "new_java.util.Scanner" be a sufficient change to get around Oracle's future copyright ownership? Will "my_new_lang.utilitites.Scanner" still be infringing because the word "Scanner" is deemed to be the significant factor (since new.Scanner(...) is how it is invoked)?
Even more bizarrely, what if I create a package called Scanner that has completely different functionality? One that operates a flatbed scanner rather than accepting user input, for example. Is that going to be an infringement of Oracle's copyright?
Common sense says no, but I don't want to have to pay to defend myself in court should I mange to produce a product with an API that sells well enough that it attracts the attention of Oracle's lawyers.
Actually it is. You wrote that copyright doesn't exist in trivialities. It also doesn't exist in methods or procedures.
To use your example:
American dogs are trained with American English words that mean the same thing to the dog.
German dogs are trained with German words that mean the same thing to the dog.
Java uses a particular API to call functions that perform math operations.
C uses a particular API to call functions that perform math operations.
Java API == American dog training
C API == German dog training
See?
By trivialities, I was referring to single keywords. It's the originality, arrangement of the words, the similarity of the expression as a whole that forms the test for 'copy' vs. 'derivative work' in copyright law. Google just copied, and they copied not just a list of common and widely used words in technology contexts. They could have made their own API with a similar set of functions and Oracle would have nothing to say, but they didn't. There are already dozens of APIs in different languages all providing the same essential services, but you don't get copyright lawsuits because they're different expressions of the same idea.
German dogs could be trained with a different set of words. But as I said, that's not the point, the copyright wouldn't be in the idea of training dogs, the command words, or even just the list of words, it would be in the training manual, which any number of people could write a version of, describing the same techniques, and still have copyright protection. You don't see the first person who wrote a "hammering nails for dummies" book start legal action against everyone else who describes carpentry techniques.
The dispute here is whether an API definition is just a list of words (no copyright) or the expression of an idea worthy of copyright protection. I think the latter, under current US law. So do the DoJ, apparently.
MS didn't 'cough up cash to Sun in 2001 for the same reason'.
Microsoft violated the license they had signed with Sun. The license they signed said that the version of Java Microsoft wrote would be functionally identical to the one Sun and other Java JVM makers wrote. It wasn't, as Microsoft was trying to make their Java Windows only and leverage their large Windows developer base. Google never signed a license with Oracle. They didn't need to. The old Sun vs. Microsoft case had nothing to do with API's.
As mentioned elsewhere API's are a "method or procedure" and not subject to copyright.
But, but, you said you can't license an API?
If there were no copyrights in APIs, Microsoft could have made their incompatible version without a licence, incompatible or otherwise. They just couldn't have called it Java. That would be a trademark issue.
APIs are not just a method or procedure. Read the judgements on appeal in this case. Oracle has prevailed on the legal question that their Java API code was copyrightable. Google is continuing this fight on the question of fair-use, although the second appeal denied them this defence.
You can't in the sense of an enforceable copyright based license. I can license the right to breath air and you can agree to it, if you are dumb enough.
Sun didn't open source Java until 1.5, The Microsoft/Sun suit was based on 1.2. It also governed the fact that Microsoft was calling their version Java without being fully compatible, something their license with Sun prohibited.
See ( https://www.cnet.com/news/sun-microsoft-settle-java-suit/ ):
"Java is a software technology that allows a program to run on a multitude of computers without having to be rewritten for each one. Sun sued Microsoft for $35 million in 1997, saying Microsoft breached its contract by trying to extend Java so it would work differently, and presumably better, on Windows computers. Consequently, one of Sun's main arguments in the case was that Microsoft wrongfully advertised that its products were Java-compatible because, in Sun's eyes, they were not. Those changes broke the universality of Java, Sun argued."
As noted at the time, it wasn't a copyright issue, but a trademark and license issue. Microsoft settled the case for about $20 million and agreed to stop using their version of Java.
The judgments in this case, written by the appellate court, confused source code and API. The points cited don't apply to APIs. The original judge & jury were correct, and the appellate court misapplied the law and existing precedent to reach their decision. Now the supreme court has agreed to take the case, over Oracle's objection, to hopefully reverse this travesty.
That's why in my hypothetical example, they'd have had to call it something different. I was trying to establish a long term understanding in the software realm that copyright can apply to APIs, because Microsoft *didn't* do what Google did 10+ years later.
But look, since this is just muddying the waters, forget MS.
The opinion of the Solicitor General is no stronger than any other informed opinion. Plenty of people think an API is trivial, as far as copyright is concerned. And the Solicitor General has some incentive to side with CAFC regardless of legal subtleties.
Also, the SG's opinion is not necessarily the opinion of the DoJ as a whole. It's officially the position of the Federal government for cases before SCOTUS and amicus briefs filed by the DoJ; but the SG is not the only lawyer in the DoJ, or even in charge of the department.
And the appeal to Microsoft's actions is irrelevant, even if your summary of the case and assumption of their motives are correct. They might simply have decided it was more cost-effective to pay Sun.
Plenty of people think an API is trivial, as far as copyright is concerned.
Maybe, but not the appeals court in this case. The Supreme court may overturn either leg, but I think Oracle is on safer ground with their 'Java SE has a copyrightable API' win than their 'Google's infringement wasn't fair use' win, because of the legal approach the court took to overturning the jury findings in the 2nd appeal. The first appeal result seems pretty solid.
On the other hand, I think there is more a risk to license integrity (including the GPL 'taint', not that I'm a fan) if APIs are excluded from copyright protection based on a precedent. Where does that leave in-lined function definitions in C++, for example? They're implementation, not interface, but they're in the interface files. Much messier than the current arrangements where source is copyrightable and licenses apply.
To clean up that mess, you'd have to amend the copyright law in order to define what an API is made of.
2To clean up that mess, you'd have to amend the copyright law in order to define what an API is made of."
A win for Oracle would certainly leave us with a mess to be cleaned up.
Ideally it could also leave Oracle's doorstep with a queue of lawyers bearing writs: IBM wanting a word about SQL, whoever now owns Bell Labs' rights to C with a number of bits of the API of which bits of the Java API seem rather reminiscent and doubtless more.
In your analogy, what really happened was that Oracle published a complete dog-training manual.
Google then copied the contents page of that manual, precisely so that they could say that it was just the same thing & 100% compatible.
Um, no, no, and no.
Allowing copyrights on API's would do absolutely nothing in the OpenZFS case. They already have access to the API. Heck, they already have access to all the source code, it's open and public. What the GPL doesn't let them do is distribute the combination of GPLv2 kernel and non GPLv2 OpenZFS. It is perfectly legal for any user to use the two in combination. Many people do. The recent fracas was caused by the fact that the kernel team stopped exporting a kernel symbol that OpenZFS was using. There wasn't any GPL code using it, and so they removed it. If you want the Linux kernel to stay in sync with your non-GPL'd code, that's on you.
The minimal code that Google copied was such a slight amount as to be a rounding error in the overall scheme of things. The rest was licensed under the Apache license as part of the Harmony project. That isn't what's at issue here. You seem to be confusing the API with the source code. The API describes the method (ex: int round(int a), java.Math.floor) and the source code implements it. Oracle is claiming that the API was never licensed under the Apache or any other license and so Google owes them oodles of money. It was never licensed because until this silly case it wasn't protectable by copyright.
I hope that clear things up a bit.
You have confused my argument. I'm suggesting the opposite; that there's a danger to GPL protected code if APIs aren't protected by copyright. For example, the GPL is no stronger than the LGPL in that case, since if copyright doesn't protect the API of a GPL'd library, I can simply copy it into my code base and ship my binaries with dynamic linking. The GPL library authors can't complain. No copyright, no basis for license enforcement. It would be bad faith, but what's to stop OpenZFS shipping a substitute kernel API file that puts the symbol back (for interoperbility!). It was part of the API, wasn't it?
I know the difference between interface and implementation. Google were doing their own implementation. The issue was they copied the interface files en masse.
Sounds like a good thing. FSF insistence that dynamic linking counts as derivative work has never been tested anyway.
But btw linking against a symbol that that no longer exists in the runtime you will be using is just plain stupid (and will crash one way or another).
No, I think I've gotten it right. There is no danger if API's aren't protected by copyright. Quite the contrary. You are still confusing source code and API's. You are, and always were, free to write your own software implementing any API and license it however you like. You can copy the MS DOS API with your own source code and call it DR DOS (it was done). That's how programs written for Microsoft DOS could run under DR DOS.
The OpenZFS authors could ship a substitute kernel that adheres to the previous Linux kernel API (as long as they wrote the software that implements it themselves) and add a symbol, any symbol they want to it. No one is stopping them. It was part of the API, but it isn't anymore, and the kernel developers are under no obligation to keep it around just for the non GPLv2 people to keep using.
You claim to know the difference between the interface and the implementation. Your problem seems to be that you refuse to accept that the interfaces aren't subject to protection (nor should they be) and so it doesn't matter if Google copied a single interface, or all of them. It's still perfectly legal. To argue otherwise is to threaten software development as a field.
the interfaces aren't subject to protection (nor should they be) and so it doesn't matter if Google copied a single interface, or all of them. It's still perfectly legal.
This is flat out wrong. Repeating it does not make it true. Read the judgements in the appeals; the appeal court found Oracle's API worthy of copyright protection as embodying the expression of an idea, not just the idea. The first appeal allowed fair-use might apply and reverted it for re-hearing. The second appeal took the evidence from the re-hearing and overruled the jury that Google could claim fair-use. The copyright ship has sailed.
Copyright has clearly applied to software source and code in the US since at least 1980. This ruling for Oracle threatens little, except the casual ripping off of other people's development efforts. If you want to copy an API, get a licence. Google could have done the right thing from day 1, but they wanted to fragment the Java platform, but not play under the GPL.
Your constant references to the appellate decision doesn't make you right either. If it did, the supreme court wouldn't have accepted this case.
I have read the judgement of the appellate court as well as both of the original judgments that were wrongly overturned. It is my opinion, and that of Google as well as many of the amici, that the appellate court got it wrong. Now Google will have their chance to convince the court that the appellate is wrong again. It's been receiving regular bench slaps from the supreme court for misapplying patent law. Now it will get a chance to be bench slapped for misapplying copyright law.
Copyright applied to source code, it has never applied to an API.
Your final sentence is nonsensical:
"Google could have done the right thing from day 1, but they wanted to fragment the Java platform, but not play under the GPL."
Google didn't want to fragment the Java platform. They wanted developers to be able to use the Java language. They could have gotten a license from Sun to use Java ME, which is what Sun wanted them to do. Google correctly deduced that Java ME wasn't fit for purpose. By that point in time Sun had already released the specs, excepting the TCK. Apache was re-writing Java SE legally under the Harmony project. This was licensed under the Apache license, the GPL has nothing to do with anything. Google used the Java API, code from Apache Harmony, and code that they wrote themselves. This included a new bytecode format and a new run time. They never called their platform Java nor claimed it was compatible.
Your constant references to the appellate decision doesn't make you right either. If it did, the supreme court wouldn't have accepted this case.
The appellate decisions are the status quo. It's worth remembering that Google's petition to the Supreme Court after the first appellate decision found for Oracle on the applicability of copyright issue was denied in 2015. Given that Google offered no new argument at its second appeal on this point (other than, in their words, to "preserv[e] its claim that the declarations/SSO are not protected by copyright law,"), it's unclear what they'll argue on this leg at the Supreme Court, or even how much shrift they'll get given their petition on this was earlier denied.
It is my opinion,...
That's quite a climbdown from your more definitive factual assertions about API copyright earlier. Thanks.
But you're still trying to draw some artificial and universal boundary between an API and source code, where no such clear boundary exists. I doubt the Supreme Court will go so far, in either direction. Considering your view that I don't believe source code should be copyrightable either," why bother to make the distinction?
GPL/Apache makes no difference (the OpenJDK was GPL); the code in dispute wasn't licenced to Google under any licence; they didn't agree one. I don't know why you keep raising Apache/Harmony; Google's claim it had copied from Harmony was whittled down in the early days when ASF denied some of the files were from Harmony, as reported on this very site. At this stage, those early claims don't rate a mention in the case judgements. The district court's first ruling against copyrightability for the 37 included this:
In particular, the Android platform replicated the same package, method and class names, definitions and parameters of the 37 Java API packages from the Java 2SE 5.0 platform.The only specific versioned reference I can find an appeal ruling comes in the second:
By 2008, Java SE included 166 API packages divided into 3,000 classes containing more than 30,000 methods. At issue in this appeal are 37 API packages from Java SE Version 1.4 and Version 5.0. We have already concluded that the declaring code and the SSO of the 37 Java API packages at issue are entitled to copyright protection.
Google may have wanted devs to use the language, but at trial, even Oracle conceded that 3 of the 37 API packages copied were really "core" to the Java language (java.lang, java.io, and java.util). Google choose not to re-frame their defence and focus on these, probably because they'd still be on the hook for 34. They continued to maintain the fair-use argument for all 37, because "Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java." This goes beyond just wanting to support the language, which they were free to do.
In any case, 'compatibility' doesn't create a fair-use defence. The precedents cited in the district court in support of this (relating to video games) were tossed on appeal as not being parallel to Google's conduct. They didn't copy in order to reverse-engineer, they copied to distribute.
The appellate's court ruling doesn't mean anything unless and until it is affirmed by the supreme court. That's what happens when the supreme court agrees to take a case. At this point the appellate decision isn't any more binding than that of the trial courts.
In my opinion isn't any type of a climb down. Just a differentiation of my opinion, vs that of the appellate or of your opinion.
The references to Harmony are important, because excepting the tiny amount of truly copied code, the vast majority of source code in this case was properly licensed. You keep confusing the 37 Java API packages with source code. Your quote: "We have already concluded that the declaring code and the SSO of the 37 Java API packages at issue are entitled to copyright protection." is once again taken from the appellate decision. Which means their validity in the current argument is suspect at best, bordering on worthless.
There was no need for a fair-use defense when Google copied the API. API's were widely understood (as mentioned by many previous cases on point though out this thread) to be beyond the bounds of copyright. They weren't trying to reverse engineer, it was public. They were re-implementing for compatibility.
Your arguments read like a case where your cousin publishes a web site declaring that you are the fastest sprinter alive. Other runners dispute your claim and the Guinness Book of Records says it will look into the matter. While others are quoting recorded track times of Usain Bolt claiming that he is the faster sprinter, referencing the times in the 2008, 2012, & 2016 Olympic medals, you just keep repeating that your cousin's website lists you as the fastest runner as if that settles that.
So what, if any cases can you cite to support your case (not including the appellate decision)?
"The copyright ship has sailed."
Yup. Right into the Supreme Court. And that can turn it round and sail it right back. That's how appeals to a higher court work.
The fact that huge swathes of Google's competitors in the software industry are presenting amicus briefs in support of Google should tell you something about how dangerous they think the Appeal Court decisions were.
As I understand it, Google copied and shipped copyrighted source code to implement the Java API,
You understand wrong.
Google used the same function/procedure/class names with the same parameters. But the code that made the function work was not copied, they wrote their own code to do the work of the function.
This is not about copying source code, it is about copying header files (that define the interfaces, names, parameters, etc., but not the code that implements the interface).
Yes and no.
Yes - Google did copy some Java copyrighted code. Mostly legally from the Apache licensed Harmony project. A wee little bit by mistake.
No - That isn't what this case is about. It's about the unlicensed Java API that Google replicated to be compatible with the Java language so that developers wouldn't have to learn a whole new language to start writing software for Android devices.
This is misleading, if not flat-out wrong. Google and Oracle agreed at trial that the materials copied in dispute were part of the Sun Java SEs (1.4 and 5). That the code was out there under a different licence is irrelevant. Google did not try to claim their use was legit on the basis of Harmony (maybe because that licence didn't suit their purposes, either).
The case was not about the language, which Google was free to use. Again, stipulated by both sides at trial. It concerned only the 37 packages, the rangeCheck function, and the 8 security files.
Read the appeals judgements, in full, before replying, please.
No, the the ranchCheck function and the security files were stipulated to and Google argued for a deminimus ruling. In other words it was such a small part of the code base it shouldn't really matter. If that was all it was, then at worse Google would have owed Oracle a small amount of money and no one would really care.
It's the API that's gotten everyone worked up. The issue is:
"Google’s use of the structure, sequence, and organization of 37 Java APIs."
Originally the court ruled that copyright was inapplicable to the APIs. Then being incorrectly overturned, ruled Googles use was fair. That was also overturned. Now the supreme court is taking a look at it.
The rangeCheck function and security files were still in dispute, since the first jury found infringement for rangeCheck, and the district court found for infringement on the 8 security files "because the trial testimony was that Google's use of the decompiled files was significant — and there was no testimony to the contrary". Google argued for de minimis on appeal, but lost; the copying was not found to be de minimis. In the event, no damages were awarded in respect of the function and security files, but Google appealed anyway.
Sure, the more interesting part concerns the API. But as I've argued elsewhere, Google's particular conduct here is not typical and the rulings in this case against them don't really represent a disaster for software users or makers. It might steer folks away from reimplementing proprietary APIs, and accepting them as de facto standards worthy of re-implementation on other platforms; I think that is a good thing.
Lets get this right.
Google knowingly copied code from Sun Java. Emails clearly mention the risk of litigation. But Google being Google believe they can get away with their cool factor.
And now claim fair usage because it is API
Can we use Google API in violation of the terms set by Google ? No. That would invite litigation.
Yet Google can use Java API in violation of the terms set by Java License.
That is the crux of the whole matter. If API come under unrestricted usage, then Google should stop whining how others use Google Maps and Other google products via API
The precedent risks from this particular case are overstated given the agreed facts of Google's conduct. The other amici like Microsoft are piling in for a win, either in the court of public opinion, or because their model around Embrace, Extend, Extinguish works more easily when they're free to eat a smaller dev's lunch library via API copying regardless of license terms.
Up to the mid 80's, globally over 70% of every dollar spent on IT equipment went to IBM.
In that period, 360/370 series mainframes were top sellers. Several hardware manufacturers like RCA, Memorex,Hitachi, Fijutsu and Amdahl started producing so called plug compatible System-370 compatible mainframes. When upgrading CPU and memory cabinets, customers could connect existing IBM I/O-equipment like 3745 channel controllers, 3330/3380 DASD, tapedrives and printers to the plug compatible units.
This caused IBM to initiate litigation, which they lost in the end. Translating hardware to software, plug compatible is the equivalent of a API.
No, copyright is not in plugs. Patents or registered designs, maybe. APIs fell under copyright by virtue of being published like books. Different jurisdictions have applied fair-use exemptions or compilation exclusions, but it's the applicability or not of copyright law at issue here.
No, API's don't fall under copyright by virtue of being published in books. Here's the relevant section of the law ( https://www.copyright.gov/title17/92chap1.html#102 ):
102. Subject matter of copyright: In general (28)
(a) Copyright protection subsists, in accordance with this title, in original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device. Works of authorship include the following categories:
(1) literary works;
(2) musical works, including any accompanying words;
(3) dramatic works, including any accompanying music;
(4) pantomimes and choreographic works;
(5) pictorial, graphic, and sculptural works;
(6) motion pictures and other audiovisual works;
(7) sound recordings; and
(8) architectural works.
(b) In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work. [emphasis mine].
An API is a "...procedure, process, system, method of operation..." and so categorically excluded from copyright protection regardless of how it was recorded, in a book or in anything else for that matter.
Fair-Use, compilations, none of that applies as a matter of law. It's just that this particular appellate court (with a history of rewriting law and getting smacked down by the supreme court) overrode the correctly descided lower court, twice, to rule otherwise.
By your analysis, copyright protection wouldn't apply to any software source code, since that is clearly procedure, process, etc.
Clearly, that's not the case. You can't use this clause to shave off the API from source code and leave one protected and not the other.
In fact, this clause just says you can't use copyright to protect the idea or process or procedure. That others are free to implement the process or procedure expressed, just not in the same or substantially similar words. It's the same as the test for plagarism. It doesn't exclude the form of words used from protection. Google copied the form of words because they copied the files, not just the idea.
Actually you can and it's not just for API's.
API's are like the legend of a map, the index in a card catalog, the symbols used to create diagrams. None are subject to copyright.
Any particular maps can be protected, but using blue for water, tan for sand, and white for ice with north at the top isn't.
Putting books A-C in one drawer, D-G in another, etc. isn't, But the books themselves maybe.
Using an oval for beginning a process, a rectangle for a step, a diamond for a decision isn't protectable. A particular flowchart created with those symbols might be.
You really need to go back and reread the included text of the law. Nothing says anything about:
"...just not in the same of substantially similar words."
It says that regardless of all those things listed under (a), it doesn't get copyright protection if it's an idea, procedure, process, system, method of operation, concept, principle, or discovery. The API isn't an implantation, it's a standard that you have to adhere to (see previous) to allow various pieces of software to inter-operate.
It's like copyrighting the English language. You can create copyrighted works using the English language, but the language itself, isn't copyrightable, even if you copy the whole thing.
They deal with all the mistakes you make in understanding how copyright applies; what it applies to; how defences to copyright violations are established, and weighed up. Really worthwhile.
Here, I'll even link the appeal judgements for you:
Judgement in the second appeal
Worth a read just for the introductions, alone. These stand, unless the Supremes overrule. I can see them weighing in because they often do when circuits differ on precedent (as applies here). But it's worth pointing out only the 1st circuit favours Google's position here. These rulings are according the 9th's, but a few others conform.
Actually you really do need to brush up on your recent appellate decisions. Back in 2015 the 9th circuit (you know the one who's precedents the appellate court was supposed to be following) ruled ( https://www.eff.org/files/2015/10/09/yoga-copyright-opinion-ca9_0.pdf ):
BIKRAM’S YOGA COLLEGE OF INDIA, L.P.; BIKRAM CHOUDHURY, v. EVOLATION YOGA, LLC; MARK DROST; ZEFEA SAMSON (UNITED STATES DISTRICT COURT OF APPEALS FOR THE NINTH CIRCUIT 2015) ("Because copyright protection is limited to the expression of ideas, and does not extend to the ideas themselves, the Bikram Yoga Sequence is not a proper subject of copyright protection.").
There's no real split in the 9th. And the appellate decisions you reference clearly show that the court had no idea how an API differed from source code. This example is illustrative:
'Appellant Br. 50. Using the district court's "java.lang. Math.max" example, Oracle explains that the developers could have called it any number of things, including "Math. maximum" or "Arith.larger." This was not a situation where Oracle was selecting among preordained names and phrases to create its packages.6 As the district court recognized, moreover, "the Android method and class names could have been different from the names of their counterparts in Java and still have worked."'
While that is true, the result wouldn't be compatible with the Java language. What they are saying is that since Google could have used C, or FORTRAN, or Cobal, or something completely new, they are guilty of copyright infringement when they re-implemented Java.
Finally, since the supreme court granted certiorari it doesn't stand unless affirmed.
The precedent you cite concern a case where people held a yoga session following the steps in a published book. The plantiff sued not on the basis that the book was copied (the expression) but the steps (the idea(s)). The plaintiff appealed that the sequence was worthy of copyright. But as the instructors were not copying it, but using the sequence, the appeal failed. This is good law, but not at all applicable to Google's having *copied* the Java API. It's more akin to trying to assert copyright on an algorithm like quicksort.
It was conceded at trial that java.lang, java.io, and java.util were essential to the JAVA language. The example chosen is poor in that respect, but it only favours Google's use of those three "core" packages, assuming a "fair use" defence can then be made out, noting again that interoperability is not a "fair use" defence. An illustrative sample making the same point could easily have been drawn from any of the other 34 copied. In any event, Google did not attempt to shift focus to the three.
I think O'Malley was pretty careful to frame their appellate rulings according to the 9th's precedents. I doubt things will get overturned on the basis of some incompetence on the judge's part.
Congress could make compatibility/interoperability a fair use defence. It might clear things up a bit more than the Supreme Court ruling for either party will in this particular case, except it would be helpful to resolve the inconsistencies between the circuits on copyrightability and fair use defences.
There are two types of protection for code, and they apply differently.
Copyright: You can't copy the code or substantial parts thereof directly unless you have permission.
Patent: If the process established in the code is new and its creator has a patent, you can't reimplement it without permission.
Hence, no, you can't copyright an algorithm, process, or system. You can patent those things if you've invented them, and you can copyright the code used to implement them. If you make a method of doing some task, but it's not original enough to earn you a patent, I'm perfectly allowed to make a program that does exactly what yours does. I should also be allowed to let my program take the same command line flags as yours if I want to.
In discussing the applicability of Section 120(b) of the copyright act that excludes protection for "any idea, procedure, process, system, method of operation, concept, etc." the appeals court found that (citations omitted):
It is well established that copyright protection can extend to both literal and non-literal elements of a computer program. ... Google nowhere disputes that premise.There follows a detailed analysis of a three-part test to assess whether the copied work embodies an expression of an idea, or mere idea. Too long to quote, refer here.The non-literal components of a computer program include, among other things, the program's sequence, structure, and organization, as well as the program's user interface. ... As discussed below, whether the non-literal elements of a program "are protected depends on whether, on the particular facts of each case, the component in question qualifies as an expression of an idea, or an idea itself."
At this stage, it is undisputed that the declaring code and the structure and organization of the Java API packages are original. The testimony at trial revealed that designing the Java API packages was a creative process and that the Sun/Oracle developers had a vast range of options for the structure and organization. In its copyrightability decision, the district court specifically found that the API packages are both creative and original, and Google concedes on appeal that the originality requirements are met. ... The [district] court found, however, that neither the declaring code nor the SSO was entitled to copyright protection under the Copyright Act.
Congress emphasized that Section 102(b) "in no way enlarges or contracts the scope of copyright protection" and that its "purpose is to restate ... that the basic dichotomy between expression and idea remains unchanged."
After that, this para:
Oracle asserts that all of the trial court's conclusions regarding copyrightability are erroneous. Oracle argues that its Java API packages are entitled to protection under the Copyright Act because they are expressive and could have been written and organized in any number of ways to achieve the same functions. Specifically, Oracle argues that the district court erred when it: (1) concluded that each line of declaring code is uncopyrightable because the idea and expression have merged; (2) found the declaring code uncopyrightable because it employs short phrases; (3) found all aspects of the SSO devoid of protection as a "method of operation" under 17 U.S.C. § 102(b); and (4) invoked Google's "interoperability" concerns in the copyrightability analysis. For the reasons explained below, we agree with Oracle on each point.Again, see the link for the detailed reasoning.
So, is there anything you can cite, other than the appellate court decision, to back up your claim? Simply reiterating the decisions that are at issue, and that the supreme court is set to review, isn't terribly persuasive.
Well I'm only trying to correct the record on what the status quo is. I'm not trying to convince people the law is wrong, or the judgements were wrong. I could cite the precedents noted by the judgements in support of the rulings (but why duplicate?). I could cite amici for either side, but I'm clearly not going to change your opinion on what the law should be (or how it should be interpreted).
Given the Supreme Court denied petition on Google's first appeal with regard to the JAVA API they copied was subject to copyright, I don't expect a win for them on that leg, seemingly unchanged. Now the Supremes could have denied it the first time around simply because the "fair use" alternative defence was unresolved.
Whether Google prevails on "fair use" probably hinges on whether interoperability somehow comes into it, despite not being a clear legal point of law or precedent. Without Congressional intervention, I see just as much danger in a win for either side, given folks will stretch the boundaries and litigate around them. Ambiguity is opportunity.
Then you are doing a terrible job of it. Since the supreme court granted certiorari, the status quo is that no one's ever been successfully found to have violated copyright re-implementing an API, cementing the widely understood belief that API's are unprotectable via copyright. The appellate decision in this case was the first to change that. Since it's currently under appeal, it's non-binding unless affirmed.
>The precedent risks from this particular case are overstated given the agreed facts of Google's conduct.
Unless you've been in cryostasis, visiting another planet or are just plain stupid, the EU rightly said APIs are uncopyrightable for very good reasons.
"If API come under unrestricted usage, then Google should stop whining how others use Google Maps and Other google products via API"
You've gotten that one wrong. The two are not at all similar. Google has restrictions on what you can do with their system, and the API is the path you take to use that system. Oracle aren't running a system, and intend to copyright the names and structure of their API. Google would not mind if I wrote up a program that used the same function names as one of their APIs. In fact, they'd probably be happy because it's now easier for someone else to modify my program to use their services.
In your example, Google want to keep you from acting nasty inside their house, which you got to by reading the address on the front. Oracle wants to copyright the address so you can't have any other houses with those numbers on them.
"You've gotten that one wrong. The two are not at all similar. ,,,"
I think you are correct about that. The situation would be that had Open Street Map decided to copy the Google Maps APIs in order to access the OSM map data, Google could charge them for doing so. Or tell them to cease and desist.
As it happens, OSM defined their own API (I think). But OSM does use Google's "Slippy Map" format for their actual maps, and doing that likely would be a copyright violation if Oracle wins this
Hmmm... so much fail it's hard to know where to start.
1) Google knowingly copied code from the Harmony project. That code is licensed under the Apache license, so that was perfectly legal to do. Google re-implemented the Java API. The API is unprotectable by definition, so also perfectly legal.
2) Google is not now claiming fair use because it is an API, they are telling the appellate court that if you are going to misapply the law and make API's subject to copyright (something that never was and still technically isn't) then re-implementing one for interoperability is the quintessential fair use.
3) Yes. You can use the Google API, any of their many API's, however you like, they aren't protectable by copyright (seeing a pattern here?).
4) Google can't use the Java API in violation of the terms set by the Java license, because you can't license an API.
5) Google can control/license how other's use Google Maps, or any other Google service. If you wanted to re-implement the Google Maps API so that yours or someone else's product could call your map service, that currently calls Google Maps, without having to be rewritten that's perfectly legal.
So to sum up, you don't seem to have any idea what an API is, or what it's used for.
I hope the above helps.
This post has been deleted by its author
Book Titles can't be copyrighted.
Surely APIs are a little like titles, except might take parameters or return a result.
I've no love for Google, but it seems obvious after almost 65 years of high level software (Wasn't Fortran 1956?) that long ago it was decided that source of the implementation is copyright but the "Titles" (API) can't be.
"Didn't some early PC clones have a different engineered BIOS but use the same APIs ?"
Indeed. Here's an article describing the situation. https://www.allaboutcircuits.com/news/how-compaqs-clone-computers-skirted-ibms-patents-and-gave-rise-to-eisa/
According to the article, Compaq worked out the IBM PC BIOS API by experimentation. I imagine that's correct. However, my frequently faulty memory tells me that they actually had some folks analyze IBM's published, but copyrighted, source code and write a spec. Then they had different folks write a BIOS from the spec. Maybe I made that up. Or maybe someone else -- Phoenix perhaps -- did that.
...and sell their own services built on them.
So they can offer any service without paying the original software supplier whenever they decide it's better for them, and without risking to lose customers if they can't offer a service any longer.
Too many people seem to be unaware the big changes the XaaS models are bringing into software development and the whole software market. AWS, Azure, Google and IBM all have big incentives to copy the API of whatever application is successful and offer it themselves cutting out the original developers and thus any money they would have to pay to them, or any code they should release because of licenses.
Expect any successful service to be quickly cloned and some proprietary features added to lock customers in. Open souce applications will be even more at risk, until licenses are changed to block it.
In a few years many will understand why API copyright was a good thing to keep a market open and competitive, and not let a few molochs to control it fully killing any smaller competitor as they like.
That would mean that they have to completely reimplement someone else's codebase. That takes a lot of effort. So far, they've shown no interest in doing that because they can instead just sell people resources to run the original thing on. They still get all the money, and they don't have to reimplement a thing. I have to ask if that's all that bad an outcome anyway. It means more people familiar with an open source codebase, hence more potential customers for any commercial system the original author has and more possible donations from users who want more updates.
Of course. Provided they provide their own code to reimplement the S/W that goes behind it if that's proprietary. They'd also be selling would be the CPU cycles, storage and connectivity. If it's FOSS then the CPU, storage & connectivity is all they're selling.
Here's a boggle that defies the collective might of everyone's IT intellectual powers. It has persisted for decades with not a single human able to solve it.
"If your download doesn't start within 30 seconds just click here to start it manually".
It's interesting you lot are still stymied by Y2K, 20 years on.
...with half of their cash stash, vote Ellison out at next AGM. Problem solved.
Sell ORCL stock afterwards at a small loss probably. But if the GOOGL risk management guys in treasury are any good any loss should be hedgeable via derivative structures into a nice little tax write-off. Net cost probably net zero.'ish. Or at most the sort of chump change GOOGL lose down the back of the sofa in any given quarter.
You gotta be creative when dealing with utter bastards like Ellson. Anyway, he is a geriatric old man by this stage so he should be dead soon. That would solve the problem too.
Probably because Google buying Oracle shares would constitutes a demand for Oracle shares which would increase the price of Oracle shares, which would mean it would cost a lot more than that number times their share price.
Not how this stuff is done. Charles Icahn and ilk first showed how to do it back in the 1980's. And that was before most modern financial engineering was developed. There are some very interesting financial structures out there that would make Schrodingers Cat do a double take. A bit like how Apple for decades was and was not tax domiciled in Ireland. Both at the same time. The very act of of trying to observe their tax domicile status immediately put it elsewhere.
Forget quantum mechanics, international accounting is where the really creative math is.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
