Skip to comments.What was Larry Ellison thinking in Java Android lawsuit?
Posted on 05/23/2012 11:39:12 AM PDT by Ernest_at_the_Beach
This lawsuit is rather important, however, if only because it has raised the spectre that software APIs might be found subject to copyright. As many people have already noted, that would have dire consequences for interoperability and software freedom throughout the IT industry. It would put into play programming languages, the interfaces of software stacks and potentially even the internet itself.
All kinds of APIs could suddenly become targets for the extraction of licensing fees and endless litigation. That could effectively destroy the entire software industry and stifle innovation for years, creating a terrible dystopia.
While that depressing vision might not in fact develop if APIs are deemed copyrightable - and it seems unlikely that Judge Alsup will rule that they are, given that US copyright law has always considered them functional elements and not creative expression that's deserving of copyright protection - that's what Oracle has argued for in its lawsuit against Google.
Oracle apparently backed itself into claiming that the Java APIs are copyright-protected because it accused Google of copyright infringement. But the Java language is entirely free to use and Google not only used the Apache Harmony version, it also developed its own Dalvik virtual machine in a clean-room environment to run software written in Java on Android.
Maybe Oracle tossed in copyright infringement to try to frighten Google into a settlement or perhaps it realised that its software patent case was weak. In either case, the charge is not likely to stick. The judge has yet to rule on the copyrightability of software APIs, but it will be surprising if he rules that software APIs can be copyrighted, since their purpose is to enable a vendor's software to be used, thus promoting that eco-system and interoperability.
Oracle doesn't have much to hang its hat on in the patents phase of this lawsuit, either. Of the seven patents that it brought into court, four were invalidated by the US Patent and Trademark Office prior to trial and it waived another one with prejudice in order to get to trial this Spring rather than have to wait until Autumn, and Judge Alsup held it to that.
Thus, the question of whether software APIs are copyrightable aside, Oracle has only two thin software patents left, which Google's Dalvik virtual machine arguably does not infringe. Whether it does, of course, is for the jury to decide, and the jury is still out on that.
Even if Oracle should prevail on one or both of the two patents still at issue, it will still face a daunting burden to claim any significant damages. It can claim either nominal statutory damages of $50,000 up to $150,000 if the jury finds willful infringement, per infringement, or actual damages plus infringer's profits, if it can establish that there is some direct causal nexus between Google's alleged infringement(s) and its profits.
But Google doesn't charge its smartphone OEM partners for Android and so doesn't profit from it directly. Oracle will have to argue that Google profits indirectly, through advertising, but in that case making the causal connection will be extremely problematic.
This is what I mean by saying that Oracle's case against Google has fallen apart. What was Oracle thinking when it decided to sue Google over Android? Didn't Oracle perform any due diligence on this lawsuit before it filed its complaint? It must have known that its case fell somewhere between arguably weak and a very long shot.
What was Larry Ellison thinking, anyway? I have a theory on this, and I will explain it.
Ellison apparently is loyal to his friends, among whom are (or were) founders and CEOs of other Silicon Valley companies in the information technology industry. One of those friends was Mark Hurd, the former CEO of HP until he was abruptly fired by HP for allegedly hitting on a female contractor. (Although the official reason HP fired Hurd was said to have been record keeping discrepancies in his expenses, the allegation of sexual harassment was reportedly the real reason.)
Ellison not only immediately hired Hurd as Oracle co-president, but Oracle soon afterwards decided to drop support for HP's Itanium servers. Perhaps that was not a mere coincidence, of course.
Now, Steve Jobs happened to be another one of Ellison's friends. Jobs was absolutely incensed when Google developed Android smartphones and began to challenge Apple's Iphone franchise. When Oracle filed suit against Google over its use of Java in Android back in late 2010, Jobs was still alive. It looks a lot like Ellison sued Google for Steve Jobs.
At the time James Gosling, the father of Java blogged, "This skirmish isn't much about patents or principles or programming languages. The suit is far more about ego, money and power."
Gosling was perhaps more right than he suspected. It seems that Larry Ellison can be a menace when he acts out of loyalty to his friends. He ought to have some self-discipline and practice a little more restraint, before he harms more than just a few large IT companies, including his own. µ
Hope this Legal Action is over soon.
The Patent portion just ended with Google walking away with a clean sweep, i.e. the patents weren’t violated. For coverage - look at www.groklaw.net where the trial has been extensively reported on. What EVER you do - do NOT pay attention to the FOSS patents blog run by Florian Mueller - he is literally ON Oracle’s payroll.
There is SO MUCH law predating this trial that says that APIs can’t be copyrighted, I have to believe the judge would be reversed if he goes that way. He REALLY shouldn’t have even allowed the claim to proceed because of all the per-existing decisions.
An API by definition is open source. It is the mechanism to share with another system.
Therefore, the code that drives the API must be open source.
Were talking database exchange here, not graphic user interface which may have a look and feel copyright.
The rule of law prevailing would mean that licensing agreements are upheld.
If one does not want to license, one should simply not use the API.
If any developer (an individual person) had created Java and the API and published it in the same way, and intended to make money from the API (or perhaps just control the course of it’s development) and get the lanuage widely used by having a more pure GPL of the language, they’d feel very much the same as Oracle America, Inc. does. They would want to see people either NOT use their API or use it and abide by the licensing agreement.
Opensource is and has been fantastic as part of the software landscape, in that it provided a private-sector initiative that restrained the MS Operating System monopoly.
However, proprietary work of services (works for hire) and products is still the lifeblood of revenue that pays for a good bit of our wonderful technology sector of the economy.
I always hear the response that the theory is that “software businesses will make money off the services”, that the software “should be free”. No one will go and work for a company for a year and not get paid. No one will start a software company if their products can be acquired for free and they have no paying customers. Companies will sometimes contribute the work of a small number of their employees towards opensource work. But they have other workers who generate revenue for the company. Many people are opensource contributors on their own in their spare time. But somehow they need to make a living and they have some other source of income.
The cost to businesses for software is largely maintenance. I’ve been asked by angry users why are we doing this upgrade ? They don’t like the idea of $100k in labor (services) going out the window - and they have no new features. This is why the idea of having an opensource “community” generating constant software changes may not always be appealing. Depends on which software we’re talking about. Mission-critical systems are often still developed completely custom in house, and that’s one of the big reasons; no forced upgrades except for the tools it’s built with.
I took a few minutes to review Oracle’s Corrected Proposed Findings of Fact and Conclusions of Law.
Google in this case is trying to get the benefits of using Java without complying with the owner’s licensing terms.
If they don’t like it, they should simply develop their own software.
If an opensource product has gotten too commercialized, it will naturally phase out of use by those who prefer opensource software for the given application.
All google had to do was very simple: do not emulate the Java API at all. Do not try to have any compatibility at all, have people do their development work who never saw the Java API in their life. Make it their own world.
But then they would lose all compatibility. Exactly ! Then they would be doing their own work and would be on 100% solid legal ground.
Some developers don’t understand that it’s wrong to steal other people’s code. If the other person puts it into the public domain, you’re not stealing it, that is 100% legal as long as you abide by the license agreement. If the other person does not put it in the public domain and wants customers to be more restrictive - read the license agreement. If you want to use it after you find out the terms and the cost, go ahead and license it. If you don’t, then don’t use it.
Licensing not “smelling very good” to me is one of the reasons why I do not use Java at all.
Oracle is in serious trouble in this lawsuit because the judge is a programmer. They aren’t able to bullshit him.
The big fallacy with your argument is that IMHO Oracle is trying to extend copyright to a place it can’t go. They are trying to get the judge to extend coverage to APIs which here-to-fore has ALWAYS been considered outside of copyright.
So they are trying to make you take a license on something they have no right to claim a license too!
(Oh - that is essentially Google’s theory - and I happen to agree with them.)
Let’s take a similar example - I program in C - it’s like most any other modern programming language. It has program flow syntax , arithmetic, storage class definitions, etc. However, without the APIs - say “stdio.h” you can’t do anything useful with the computations - no I/O. The APIs are a basic extension mechanism to the definition of the language. Without it - you haven’t implemented the language. Making these non-functional interface definitions copyrightable is illogical, and would be horrible for the industry at large. Copyright wasn’t intended for non-functional descriptions like this. Oracle only BARELY got the judge to grant them a trial on the subject because they argued that the Composition as a whole, and it’s organization took creative effort. It still reduces down to an interface description and shouldn’t be copyrightable.
There was a case 20 years ago between Intel and NEC. Intel claimed that NEC had created a derivative work, i.e. violated copyright to make a compatible product - they claimed copyright on the Instruction Set architecture of the 8086. The ISA is VERY much like the API for a computing language - the court found you couldn’t copyright this.
Then there is the SONY V. CONNECTIX case that the court is asking for a brief on - they came to the same conclusion relative to a clean-room implementation - very much like what Google did.
So - if you want to outlaw reverse engineering - we can go your way.
Finally - there is a defence that Sun invited everyone into the pool and asked them to create competitive products to entrench the language. Now - Oracle wants to change the rules of the game after so many years. That isn’t fair either.
Take your pick as to which defence you agree with.
but your argument never gets off the ground because of facts.
Things like books written that document the API. You don’t have to download anything from a website to see the API. Then you ignore my original claim that such things CANT BE COPYRIGHTED. So even if I download it with some sort of license that restricts my rights to use the API - such licenses won’t be valid because the Copyright law doesn’t allow it.
Oracle is trying to argue that because we did something really commplex - that makes it copyrightable. I simply don’t buy that.
The difference between fopen/fclose/open/close/printf... and the API’s in java simply one of complexity - it doesn’t change the fact that it describes a function, but doesn’t implement it. It is a description of interaction - not the implementation of how that interaction occurs - that is the difference between something that can not be copyrighted, and something that can be.... at least the understanding I’ve used over the last 30 years in the business.
Mark my words - if the judge doesn’t rule consistent with my description - it will be catastrophic for the software industry. Even Europe just ruled last week along lines I’m describing here!
We’ll see what the judge says in a bit here.
A book about the API would be fair use if the copyright holder allowed it. For quite a long time, PeopleSoft had a policy of not allowing insiders to write books about PeopleSoft’s software; once it became ubiquitous, the policy changed. The software was only marketed to large businesses who had no interest in violating the licensing agreement for the software they licensed at considerable cost; no consultants or employees would want to risk being sued either. Was this a bad thing, that it was not made “free for the world” ? No, it never would have been developed if it could not have been successfully marketed and sold.
Header files are source code and are therefore copyrightable.
Source code is copyrightable.
All of JimRob’s source code is copyrightable. Source files, header files, all of it.
Say FR developed, for their own use in the development of the FR site, a library, mylib.so and a header file, mylib.h which is what they compile with their other source files to be able to call the functions in mylib.so - this is an API.
Say JimRob lets one of his friends publish a book about his API library because he is so proud of it; he grants his friend a license to include the header files in his book as long as he includes the complete listing; right in the listing of the header file is a copyright notice.
An appendix is then included in the book containing the complete listing of the header file used to link with the API library. No source for the library code, just the header source with all the function declarations, etc.
Now we’re mired in First Sale Doctrine, which is arguable as to whether JR would have lost control. But guess what, since the entire book itself is copyrighted by the author - a software developer who copies code out of it to use in their own software would be infringing at least on the copyright of the book’s author.
You could read all about it in the book and refer to the listing to understand all the explanations in the book, then write your own library - from scratch - that worked using the same ideas, algorithms, etc., and you would not be infringing. You didn’t copy the header file, you did your own thing that was similar.
You would be infringing, however, if you read the book then:
a) wrote your own version of the FR API library based on the header file, then
b) created your own mylib.h file on your computer and typed into it the full header file from the listing in the appendix in the book, then
c) distributed the library you made along with the header source you copied out of the book.
You would have copied part of the copyrighted work and distributed your copy without permission.
I’ve worked for a software company, as well as many clients and employers, writing custom source code for them. Never ever once did I ever dream of copying source code that I wrote or anyone else at the client wrote or any code that I saw while at the client, let alone copy the source code and actually using it in any situation other than for that client or employer.
The only time I’ve ever copied code out of a book and compiled it was Peter Norton’s Assembly language book from decades ago as a tutorial for myself when I was just starting to program. Which was exactly what the book was intended for; it was a complete example of an assembler program that would read and display disk blocks, as I recall. I did not make any distributions of the tutorial copy I created.
For the lazy, it may be tempting to copy stuff. And the opensource folks have so much effort tied up in Java-based things they’ve written. I knew it was turning yucky when the whole mountain of libraries started to be added on, it was just too tempting to use that stuff.
As far as patentability, I say, hogwash, software is nothing but math, essentially, which was always supposed to not be patentable. That being said, when other countries steal things, reverse engineer them then sell their own knockoffs, that ain’t right. The solutions start with not selling high tech things to them.
But copyright applies to all source code; header files are source code.
Think about it; if I simply don’t use headers and put all code in the .c files, redundantly declaring as needed in each one, the “can’t be copyrighted” argument is gone.
Years ago when I used cobol, assembler, scripts - they all have some sort of include, copybook, etc. They were all copyrighted. There is no “open season” on copying source code that happens to be in include files.
Whether source code is copyrightable has nothing to do with whether it declares a functions or defines them, what is copyrightable is source code, because it all is authored work; someone wrote it. I know there are all sorts of books describing the APIs out there, but google’s problem is that at the end of their development, since they wrote their libraries according to the header files - they need to violate the copyright on the header files in order to distribute the header files themselves. If the API was not under the same opensource agreement as the Java language itself, they should have not used the libraries, but made a new API of their own design - then they would not be using the header files. Google could have used similar ideas and concepts, just changed the structure to a significant degree by making fairly straightforward design choice changes, and changed all the names of things, and they would be completey ok on copyright. The only available recourse for Oracle would have been patents, because - like you say - ideas and concepts are not copyrightable. As long the APIs were either not patented, or the patents were designed around (not that difficult for anything but “exotic” algorithms which I doubt there were any), Google would have been good to go and the issue would never have gotten off the ground.
This is what Google has to say about your argument - they are responding to a question by the judge - likely the last brief of the trial. Note that they quote both relevant cases to their point and the copyright law relevant to the point. Your feelings aside - this is what the law says.
“Because aspects of a computer program that are functionally required for compatibility are not copyrightable, it does not matter what the defendant does with them. Even if the defendants product is not compatible with the plaintiffs product, the plaintiff still cannot assert infringement based only on the copying of unprotected elements. The protection established by the Copyright Act for original works of authorship does not extend to the ideas underlying a work or to the functional or factual aspects of the work. Sega, 977 F.2d at 1524 (emphasis added) (citing 17 U.S.C. § 102(b)). A party claiming infringement may place no reliance upon any similarity in expression resulting from unprotectable elements. Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1446 (9th Cir. 1994) (quotation marks and citation omitted; emphasis in original). Thus, because the SSO of the 37 API packages is functionally required for compatibility, Google was entitled to use that SSO, regardless of whether its use made Android fully compatible or not.”
This just in -
“he overall name tree, of course, has creative elements but it is also a precise command structure a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability....
Contrary to Oracle, copyright law does not confer ownership over any and all ways to implement a function or specification, no matter how creative the copyrighted implementation or specification may be. The Act confers ownership only over the specific way in which the author wrote out his version. Others are free to write their own implementation to accomplish the identical function, for, importantly, ideas, concepts and functions cannot be monopolized by copyright.”
So there we have it - until an Appeals Court says otherwise, you can’t copyright APIs, and Google did NOT do anything wrong. Oracle was trying to take Copyright into an area where you have to get a patent.
If you want to protect and API - you either have to keep it a Trade Secret, or patent it. Copyright isn’t the vehicle for that protection.
Well, there you have it.
I’m developing a toolset right now for my own use.
I was going to expose APIs and sell them as a development toolket, but I won’t now, as it makes no sense financially. If I am able to start selling them and making any decent amount from them, a larger company could simply copycat the API and put far more money into marketing than I could and I’d be sunk.
I’ll only make applications available for sale. Any toolset that I develop and use to build those applications will be 100% proprietary and trade secret.
I don’t have a choice at this point, this knucklehead Judge can’t see what they’ve just done.
By the way this wording reads, sounds to me like if I make my own language that a copyright of a language would be indefensible.
Is not a language “a precise command structure a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot be copyrighted. Duplication of the command structure is necessary for interoperability....”
Hmmm... do you think a software language copyright is defensible given this ruling ?
You are correct - you can’t copyright the language either, and really never have been able too. If you accept that “ABI”s aren’t copyrightable, also the case (See Intel Vs NEC, though mostly about accusing NEC of creating derivative microcode), etc. then the same logic is extensible to high-level languages. The judge even states that is the law now. I suggest you read the ruling because it has a huge amount of historical info on Copyright decisions and how they have evolved, along with references to the latest changes circa 1980 to the actual provisions in the law.
Note - there ARE two counter-prevailing decisions that lend some support to your point of view. It is just that the majority of decisions have gone along the way the judge took it. In his opinion he DID make a decision in uncharted territory for APIs explicitly. The decision is also not broad, i.e. only applies to this case. Likely affirmation at the appeals level will widen it’s applicability.
The thing is - you have ANOTHER choice - copyright isn’t the vehicle for the kind of protection you are looking for, but rather patents are. That is one of the BIG reasons why copyright can’t go where you want it too, and if you read the judge’s decision, that becomes apparent. Copyright lasts too long - and granting a monopoly for 90 years or whatever it is that Copyright lasts today is not how a free market system works.
Patents grant exactly that - a government sanctioned monopoly for 20 years. For exposing your invention to the public, you have 20 years to make a profit on it protected by law. Now, reality is that patents are notoriously hard to defend. My Uncle was a case in point. He invented a unique covering system for the back of a truck. He produced and marketed it. He was continually having to police copy-cats, and it ate up a fair amount of his profits. Finally it was easier to sell the business to a bigger manufacturer.
I am strictly opposed to software patents and will never seek one for a few simple reasons.
1) math is not patentable according to patent law; one can’t get a patent issued for 2+2=4. What the knucklehead LAWYERS don’t want to admit (for they’d have much less business) is that algorithms fall exactly into that realm. If I want to write a program that allows me to enter in every State fair I go to and track a few pieces of information about them, then you get the same idea - completely on your own - and we both write such a program, for either of us to be able to limit what the other can do is preposterous. We would have to design the thing with some fields like “Fair Name”, “Start Date”, etc. We’d both have a search functionality that allowed us to look up fairs that matched search criteria that included those fields. This would involve naming that is unpatentable and basic search functionality techniques that are widely known, fundamentally based on math and unpatentable.
2) Which brings out the second point, novelty. And the ugly truth that can’t be truthfully avoided is that if me working in my garage and you working in your garage, both completely independent of each other, (as well as millions of other programmers) can come up with essentially the same program in a few days, then obviously there’s nothing that novel about what we’re accomplishing.
3) Pure-math algorithms, such as google’s pagerank, are simply that - pure math, and strictly speaking should not be patentable. Instead of limiting the patent description to the essential algorithms presented in a generic and mathematical way, lots of gobbledygook wording related to the particular programming field that the patent seeker is trying to “lock up”, (for “pagerank” this is links, backlinks, nodes, etc.) is added around the essential algorithms. In this way the patent application looks like a nice, big, professionally-written spiel about the field - it looks so good, it has to be credible. The pagerank patent itself claims to be a more sophisticated version of commonly-known algorithms. Essentially, it’s something like this:
I have 2 ducks in a puddle in my back yard
+ (I go and get two ducks and bring them home)
= 4 ducks are now at my house.
And this obviously would apply to anything in the field of counting ducks or putting ducks into rows or any other formation, either on land, water or in the air. Because it’s obviously the heart of the invention, the novel application of the widely-known adding 2 plus 2 idea to the new and challenging field of duck management.
Google’s patent arrangement:
The pagerank patent belongs to Stanford, where Page and Brin were graduate students. Having Stanford own the patent was the best way to start commercializing the product immediately and have no potential legal flak from Stanford such as occurred between the Netscape founders and Univ. of Ill. Brin and Page then founded google which exclusively licensed the patent from Stanford - the payment for the license was stock in google from which Stanford eventually made a very large profit. One could say that this was a very equitable arrangement for all concerned - and it truly was. Stanford only gets a lot of money if Page and Brin have a big upside, Page and Brin have no real downside on their payment to Stanford if google had failed as a business.
The effect of patents on innovation and small business (that weird “growth engine thingy”) using google as an example:
So Page and Brin had very little cost ? No, they needed to be attending Stanford to get this arrangement. Most people seeking to start a small business are not Stanford PhD candidates.
So Stanford provided essential help to Page and Brin in devloping pagerank ? No, the primary leverage Stanford had to get paid for the work of Page and Brin on pagerank was the potential for litigation on their part. The equipment and capital was mostly the minds of Page and Brin and some computers, which, today, don’t cost much.
Having the patent issued to a patent-holder with large financial resources to retain the best patent defense attornies makes everyone else in the world steer clear of the pagerank patent. If anyone does work on internet search algorithms at all they need to spend extra time and thought on designing around the pagerank patent. This is something that small inventors who have very little funds will not have the resources to waste time on. So inventors with small amounts of funds will be much less likely to work on internet search algorithms.
Alternatively, if software was not patentable and simply had to be maintained as a trade secret, as small inventors saw google’s success early on, many people would start thinking about internet search algorithms. Inventors with small amounts or no funds would be very likely to work on such algorithms. Even though no one would be able to legally see the pagerank algorithm, there would be a hefty amount of independent competitive research going on. Other competitive search engines would have popped up much sooner that used automated bots, as it would become apparent very quickly that no humans were entering webpages into the google database and ranking them manually as Yahoo did. Perhaps google would not have gotten as big if there were others who had success early on; perhaps they would have come out on top anyway. The biggest cost to society is that of opportunity cost: perhaps someone else would have invented something much better than google, but the effort was simply never embarked on.
Getting a patent issued is a big hurdle for small business that has no sophistication in terms of legal and patent issues. The elites of America who send their children to the best colleges - and these colleges themselves - are easily able to set up arrangements such as google’s early arrangements. Trouble is, for the county college attendee, etc., who may be very smart but typically is poor and has practically zero connections, setting up such arrangements is an enormous hurdle. Especially since everyone they meet will want to cash in bigtime on this person’s idea - if they even take them seriously at all. So instead of getting the best deal possible throughout the whole process from initial start up to the final pump and dump in the stock market - exactly like houseSYSTEM, er, I mean, facebook - they wind up getting pushed out very early in the process.
Put simply, patents favor those with at least 30k or so and some serious time (time=money) to go into the effort of securing a patent. They are therefore attractive to large businesses and people who can afford them and are interested in obtaining them. They hold back entrepreneurial success for most people who would otherwise would be making and doing more and better things.
Some ideas - or parts of ideas - an inventor may want to put into the public domain. This is also fine. They may not desire to commercialize their idea at all but still make it available to the public, or they may want to make their public license cover perhaps one invention and have others that are trade secrets, which is a possible scenario that may work well.