The quoted exchange is between Judge Alsup and Oracle's counsel, David Boies, and concerns the issue of what damages Oracle intends to seek in phase 3 of this trial (phase 1: copyright liability; phase 2: patent liability; phase 3: damages). The jury hung on the major copyright claims and the judge has yet to rule on the ultimate question whether the 37 Java API packages at issue are even protectible by copyright. Oracle proved infringement concerning the nine lines of code constituting rangeCheck and the judge held as a matter of law that Google had infringed respecting a couple of test files that were subsequently removed from Android. In this context, under applicable law, Oracle may elect to get statutory damages of $150K for each of the infringements or it may elect to go after what are known as "infringer's profits" - meaning that it would ask the jury to award it damages measured by profits made by Google on account of the infringing acts. Mr. Boies is telling the judge that Oracle wants to go for infringer's profits "as a matter of principle" and the judge is telling him, in effect, that he is astounded that Oracle would be prepared to make a claim for a billion dollars (or some other very large number) based essentially on nine lines of code among the tens of millions of lines of code in Android and a few test files. Mr. Boies strains to offer various rationales for how Oracle might prove damages of this type, mostly tied to the idea that Google gained in time to market for its Android product by relying on the infringing materials. The judge basically tells him that this position is ridiculous and that he cannot believe that an attorney of Mr. Boies's stature would even make it (at one point, he notes that Oracle is trying to make a "federal case" out of this and, catching himself, says (I paraphrase here), "oops, this is a federal case . . . well, seeks to make a bigger federal case out of it than it is"). (The Groklaw report on this exchange is worth reading and even fun in spots - it may be found here: http://www.groklaw.net/article.php?story=20120515120106322#U...)
This exchange highlights the rather unfavorable position that Oracle finds itself in on the copyright issues. It has won nothing of significance and stands to get very little from the jury on these issues. Concerning the broader claims on which the jury hung, it still faces a potent objection from Google that it cannot assert copyright violations based on the 37 API packages owing to defects in how the Java program was registered with the copyright office. It also faces the risk that the judge or a court of appeals will hold that APIs are not copyrightable.
A word on this last item: Much as the developer community believes very strongly that APIs should not be copyrightable, the Ninth Circuit law that is binding on this judge (beginning with Johnson Controls in 1989) is not particularly favorable in that it provides that software programs are to be analyzed item-by-item on the facts of each particular case to determine whether any particular component is protectible expression versus an unprotectible idea, function, system, or method of operation (this is in stark contrast to the First Circuit, which held that judges could make categorical judgments that certain components are functional by nature and hence unprotectible by copyright (as opposed to patent), as the menu structure was held to be many years ago in the Lotus/Borland case. Google is arguing the issue categorically ("APIs are inherently unprotectible under copyright law") but this makes for a tough sell in a jurisdiction where the appellate authority has said that such issues cannot be categorically determined. Google has alternative arguments, the main one tied to a leading Ninth Circuit case (Sega) that Google argues enables copying of functional elements of any program needed to ensure compatability. But, in my view, astute as this judge is, he will be bound to apply the fact-specific approach, making it tough for him to adopt Google's strongest argument and thus significantly reducing the prospects for a definitive ruling from the judge along the lines sought by Google (of course, this might come on appeal, where the court is free to reshape its earlier precedents in light of modern-day realities in the software world).
Excellent analysis, but I have one question. So if you cannot categorically state that APIs should not be copyrightable (how does this relate to previous industry efforts around clean room engineering and cloning, like the IBM PC/firmware clones and x86 processor clones? Why did those escape the courts?) , how does one even go about, on a item-by-item basis, of providing APIs should be copyrightable?
For example, take the Java package java.io used for reading/writing files among other things. How can you construct an argument that the structure of the API itself should be copyrightable? And what would be an example of an API that couldn't be copyrighted for that matter?
Even though I am not averse to IP rights generally, I strongly believe they need to be applied with their proper goals in mind and that it is deeply prejudicial to all concerned when they are misapplied - in that vein, my view is that APIs should not be copyrightable, as this to me is an abuse of the principles of copyright (if a rare API design is so novel as to be worthy of protection, it should be protected by patent).
In the Ninth Circuit, however, the same Johnson Controls case that held that the components of a computer program are to be assessed item-by-item to determine what is protectible and what is not also set forth the (judge-invented) doctrine that the structure, sequence and organization of elements in a computer program can be protected by copyright even if the discrete pieces are not in themselves expressive. Taking this as its point of departure, Oracle argues at length about all of the "expressive choices" that were made in the 166 API packages that are part of Java (and in the 37 API packages specifically at issue in this case), how they are named in special ways, how they are structured to take certain parameters and not others, how some call certain classes and methods not others, etc. Oracle further argues that Google could have achieved the same functionality that it gained from copying the APIs through "other means" such as APIs with different names and the like and that it could have done so without using the identical "sequence, structure, and organization" used in the Java APIs. It analogizes all this to a musical composition that is readily protectible under copyright even though individual notes are not.
I personally think the Oracle argument is a crock but, when you are able to devote huge resources to developing a case, when you can hire the best experts who can attest to the countless forms of "creative expression" of the type alluded to above, when you can pay the best lawyers to spin it out endlessly from every conceivable angle, you get the scary prospect of a court buying into this sort of analysis and mechanically concluding that, yes, all this is protected by copyright because it is "expressive" and not merely functional. This is why I think that the judge, who is bound to follow the Ninth Circuit precedent, will really need to dig deep to make a definitive ruling here that APIs are not protectible by copyright as a matter of law. An appeals court will have more freedom, however, and can focus on the purpose of copyright law and on why it is absurd in light of modern programming realities to give any party the power to monopolize API-style functionality in ways that will paralyze the industry. The judge is a very good judge and he may also land on the right conclusion - it is just harder for him because he is bound by some restrictive precedents.
I'm having difficulty with this. I also agree that APIs should not be copyrightable, because that defeats the purpose of an API. Their value to technology in general goes down if people can claim copyright infringement if someone else implements the same API. And that is, I think, the true test for what should and should not be legal: how will this impact society? I think that being able to copyright an API is a clear harm to society.
My difficulty comes from the fact that designing a good API is hard, and I think that there clearly are creative aspects to it. Doing a good job requires having an intimate knowledge of the component being interfaced with, and how programmers are likely to use it. The mere fact that we have said before "This API sucks" implies that it is not just a mechanical process.
Basically, I want one result because I feel it's better for society. But based on first principles, that's not the conclusion I arrive at.
That's not my point. My understanding of grellas' argument for why APIs are not copyrightable (which, again, I don't want them to be) hinges on "expressive" versus "functional." I am not a lawyer, so I don't understand the legal version of those concepts, but as a layman, APIs seem to me to be expressive; they require creativity and insight to create. If anyone would like to explain why they are not considered "expressive" constructs under the law, I would be glad to hear it.
The "subject matter" for copyright is defined in 17 U.S.C. section 102. Part (a) of the statute defines what can be copyrighted (essentially, original works of authorship) and part (b) defines what cannot. For policy reasons, the (b) part says, in effect, that even if something is an original work of authorship (meaning it is expressive and creative and otherwise eligible for copyright), nonetheless certain things cannot be copyrighted because this would not further the goal of copyright law (to further the progress of science and the arts) and would otherwise potentially harm society.
Section 102(b) reads as follows: "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."
The idea here is not to give anyone a monopoly via copyright over such fundamental concepts as ideas, etc. Things that are purely functional within systems and the like fall within 102(b) and cannot be copyrighted even if they are otherwise expressive. That is what Google is arguing about the 37 Java API packages in this case.
So did Huffman encoding. So did the Laplace transform. So did quicksort, red-black trees, and hell, even the Universal Turing Machine. These are all the result of many hours of creative endeavor, yet they are none of them copyrightable.
This is the same thing that makes Wolfram's claims of ownership of the existence of a proof of Rule 110 CAs as universal calculators particularly onerous.
I gladly accept grellas's arguments. But your examples are ideas, which would fall under patents, not copyright. Source code does fall under copyright, so we need reasoning to explain why APIs - which are a part of source code - do not.
"It analogizes all this to a musical composition that is readily protectible under copyright even though individual notes are not."
This is a nice analogy. APIs are more expressive than individual notes but hardly raise themselves to the level of a fully formed composition.
Imagine a list of musical phrases. That includes scales and progressions at the simplest level and pleasing variations on those themes but not enough to form a contained composition themselves -- at most a couple of bars.
Each entry could show what scales and progressions they are derived from and even suggest which other entries, in simple combination, are common or otherwise musically sound. Let's further assume that they are given convenient names.
Would that rise to the level of copyright? If someone were to create a distinct variation on that list but slightly different for use with instruments tuned in an unusual way but used all of the same names because ultimately the way all of the phrases relate to one another is the same, would that be fair?
I haven't thought this scenario all of the way through, but it seems useful to take my familiarity with software out of the process...I have to admit, at first blush, I am a bit torn.
Perhaps it's reading too much into things, but doesn't that raise the possibility that this judge, knowing more than the average about computer science, is working hard to carefully justify as definitive ruling as possible arguing against the copyrightability of APIs?
At least, that's my hope. The transcripts indicate that he understands the tech better than most.
This is somewhat off topic, but why does the same lawyer show up so often?
David Boies has argued in Bush v Gore, defended Napster, worked for SCO in SCO v Linux, argued the recent California gay marriage law, was the council for US team in the recent America's cup case, and now he's Oracle's lawyer here (at least I see the last connection).
I can't discern a pattern to those cases other than their high profile nature. Wouldn't it make more sense to hire someone that is an expert in computer IP law for SCO, Oracle, Napster type cases, a constitutional lawyer for the Gay marriage and Gore v Bush type cases, etc. How can one guy be the go-to for so many high profile cases?
Basically, the guy is a genius. Read his Wikipedia bio.
Praise of the man:
"The one talent of David's that stands out is his ability to lay out a course of action that would take into account any sort of complicated facts and develop a far-reaching scenario. It's a chess player's sense: If I do this, the following 15 things are going to happen, and if step 11 goes so, I'll do this rather than that. It's a fantastic game-playing ability." Thomas D. Barr, quoted in the New York Times Sunday Magazine, June 1, 1986
"The Boies memory is one of the first things cited when people discuss his strengths. What's most impressive about that gift -- focused as it may be by the intensified concentration that his dyslexia demands -- is Boies' uncanny ability to recall a key fact, legal citation or piece of contradictory testimony at moments of the most intense pressure." Time Magazine, "Get me Boies!" by Daniel Okrent, December 25, 2000
A trial is a problem in maximizing the reasoning, under law and supported by fact, presented to a judge and / or jury. Those audiences have limited bandwidth to begin with. The "under law" constraint largely drives which reasonings and facts will be most important -- especially as all that must cross a barrier of evidentiary rules and trial procedure. The ability to weave all of that into a coherent narrative is crucial to communicating to the audience.
Boies can grab enough of the subject matter to speak to the key legal issues, and to ask experts the questions that define the boundaries around those questions. Another lawyer might know more of the subject matter, but that won't matter if they can't translate that extra knowledge into legal strategy.
Remember also that while you might be able to find legally pertinent technical responses to Boies' work in court, you're reacting to that after hearing his strategy. Good trial communication requires telling a unified narrative -- if your story doesn't already provide a basis for your response, that response will be weaker and may even distract from the story you do have. Boies' ability to anticipate arguments, mentioned by another comment, is crucial to all this -- it's not enough to have an answer, you really need to have that answer in advance of his question.
It's his "trial" skills. There is a team of lawyers, each lawyer skilled in one particular aspect of the case. Mr. Boies's specialty is pulling all the information collected/discovered by the various attorneys and creating a grand advoacy plan that includes strategy and argument. So an attorney incredibly astute at patent law may not be so good when it comes to verbal argument (specifically, appealing to the sentiments of the jury is an art in itself, and few attorneys are able to master this skill) and overall case strategy, but is able to effectively assist Mr. Boies in preparing for trial.
As a former litigator turned startup founder, I can attest to the difficulty of assembling the right team with the ideal point man for a trial, and when you do find one you respect, he is worth every penny. David Boies is one such man - nobody has gotten fired for hiring him as the lead trial attorney.
Maybe for his litigation skills? I'm sure there's a large legal team behind the scenes that includes IP experts, but "litigation" is its own field - most lawyers never see the inside of a courtroom. There's rhetoric, witness examination, making motions and objections, and so much more than expertise in an area of law.
(IANAL but I helped AOL sue Sanford Wallace, and it was a sight to behold.)
> Judge: We heard the testimony of Mr. Bloch. I couldn't
> have told you the first thing about Java before this
> problem. I have done, and still do, a significant amount
> of programming in other languages. I've written blocks of
> code like rangeCheck a hundred times before. I could do
> it, you could do it. The idea that someone would copy that
> when they could do it themselves just as fast, it was an
> accident. There's no way you could say that was speeding
> them along to the marketplace. You're one of the best
> lawyers in America, how could you even make that kind of
> argument?
It sounds like the judge is saying that he has written code before, just not in Java. Presumably this was some time ago, before he decided to become a judge.
So he was playing dumb earlier for the benefit of the jury - to make the advocates spell out their case clearly. This is what he was responding to:
> This copying allowed them to use fewer resources and accelerate that. Suppose they
> accelerated it two days. They're making $3 million a day now [...] If you just get
> one or two days' acceleration, that's $6 million
This is a good point; it's common to underestimate how long it takes to code something. And time to market is often strategically crucial - that is, productivity isn't just efficient, but can be the difference between success and failure. rangeCheck is trivial; but writing, testing, debugging, naming and documenting take time. A trivial typo bug in rangeCheck can cost a disproportionate amount of time - and it's amplified here, when rangeCheck was used to test other code. (Who shall unit test the unit tests?)
To answer Groklaw's final question as to why Alsup couldn't decide on API copyrightability yet, he clearly said he needed to do a lot of reading. He not only has to decide according to law, he is in effect creating law, since this specific issue hasn't been decided earlier. His ruling has wider significance than just this particular case. Future potential litigants will read his ruling, and will avoid court if it's clear who would win. Although he is only one judge and so his precedent won't be binding on a full bench/higher court, those judges would also carefully read his judgment. He'd better get it right, not only in the result, but in the reasoning, and integrating it with related cases.
It's great that Groklaw is making these transcripts - because the court is a public institution, I think the official transcripts should be available (and why not video too? The emphasis in oral argument sometimes isn't captured in a transcript.)
I don't think it's a good point at all. I think it's completely disingenuous. The analysis quoted assumes that the implementation of the rangeCheck function is on the critical path to shipping, which is preposterous in my opinion.
I think it was mentioned that this code was used in testing other code - when you're reverse-engineering, conformance testing is about as critical as you can get. You could start coding without it, but it's quicker to catch bugs early. [NB: I don't know whether it actually is used in testing]
He only copied it because he was planning to submit the code to the OpenJDK and writing his own would have led to unnecessary duplication of code. The copied code would no longer be needed when the new code was added to the same package.
Bashing it out cowboy style would have been faster and in no way harmed Android. It's Oracle's codebase he was spending time and energy improving with good engineering practice.
My point is that it's worse than nonsense, it's actually arguing the opposite of the truth. The "copying", rather than speeding up Android development to Google's benefit, actually slowed Android development in an attempt to help OpenJDK/Oracle.
That this is the only direct copyright infringement they could find is highly ironic, but I guess either the lawyers didn't understand the subtleties here, or thought the jury wouldn't as this argument wasn't made (except obliquely in Bloch's statements).
While the basic line of reasoning is valid, it is absurd in the context of the rangeCheck function.
There might be a nine line function that takes a day or two to get right, but for even a bad programmer, rangeCheck would take a few minutes. With thorough tests, maybe ten minutes. I've barely touched Java code in over a decade, but I could write that function -- with tests -- in less than two minutes.
RangeCheck is the kind of function you'd get on a quiz in your first week of your first CS class in college.
I was simply trying to show that even seemingly-simple functions can have surprising bugs. Binary search isn't week 1 of CS101 - I think it was week 4 for me. Bentley's published version had a bug, Bloch's original corrected version had a bug, etc.
Working on it myself, after having read what the code does and being committed to re-implementing it myself, it took me 3.5 minutes and there were 2 bugs. (I needed to look at the original code again to determine that to == length and to == from were both allowed -- those were the bugs.)
Did you include the time it took to read what was needed, including the different exceptions? I would estimate, if one wasn't fresh and up for a challenge, 15 minutes (against your approx 10 minutes). And given that a day of programming isn't pure programming, I'd double it to 30 minutes. It feels way too long, but it's a realistic, day-in-day-out estimation.
Programming takes time... which is why it's so powerful if you can reuse code (as Bloch did), and even better if you can find a way to reduce the code needed, or best, to avoid needing any code.
sub rangeCheck {
my ($len, $from, $to) = @_;
if (($from > $to) || ($from < 0) || ($to > $len)) {
die "Illegal index $len ($from / $to)";
}
}
Java, as usual, makes a big hairy deal out of it. If the lack of types bothers you it's trivial in Haskell too. (Though trying to be idiomatic would lead you down a very different road. Perl is more similar to Java than Haskell, even as they are all very distant from each other.)
As it happens I've recently written somewhat similar code in Perl where I want to explicitly deal with out-of-range accesses (in a way other than silently receiving undefs) in a particular case, so this isn't even that odd.
You're throwing a generic exception; Bloch's version throws two specific exceptions, together with appropriate information. Java tends to have excellent error reporting.
All this reminds me of people saying that could code stackoverflow or facebook in a weekend. The difference is that rangeCheck actually is trivial - it's just that it's easy to underestimate the work involved in coding something. Even something trivial.
>>You're throwing a generic exception; Bloch's version throws two specific exceptions, together with appropriate information. Java tends to have excellent error reporting.
I know. I reduced it to one generic exception because that is what the person I was replying to did. Bloch's version is better of course.
I think in defining a range, the toIndex means up-to-but-not-including the element at that index. Thus, to include the full array, you'd use the range fromIndex=0, toIndex=length (one past the last one, since the index of the last element is length-1). With this notation, you can then make ranges of any width, from 0 up to length. If instead you included the element at that index, you couldn't have 0-width ranges (unless you allowed toIndex to equal one less than fromIndex).
I don't know whether 0-width ranges are directly useful for the Timsort algorithm; or whether it's just a convenient notation that happens to have that ability as an unused side-effect.
Maybe not 2, but less than 20. I've never written any Java, don't code regularly, and consider myself more of plodder than a coder, but it only took me a minute to figure out what the function was doing and why. Knowing when to put such functionality into your code is a larger challenge than actually coding it; this is a very trivial piece of procedural code.
Your parent poster didn't imply agreement with the line of reasoning he explained. He was just illustrating why the question is important to begin with.
Releasing two days earlier or later doesn't imply loss/gain of market share. Practically nobody buys mobile phones on a horizon of days.
Thus, if we do suppose that Android was accelerated two days, the benefit wasn't $6 million - it was having that money in hand a little earlier. The interest on $3 million for a day at 7% pa is $575/day - or $1725 total. Or less money than it costs Oracle's counsel to sneeze.
It's an interesting point, about which Oracle might argue entertainingly. e.g. if a market has a limited life, then 2 days delay means 2 days less to make money (markets don't last forever). e.g. being earlier to market is well known to does make a difference for getting a foothold in a market (mindshare, word of mouth, technical feedback, supplier relations), but especially because you are judged relative to your competitors - releasing your next version before their next version helps you win.
Except that Android's first release was a beta and SDK, almost a full year before phones shipped.
From that, it's not remotely clear whether saving 2 days to beta would have even resulted in 2 days of savings in the creation of any device.
To say nothing of whether Google/TMobile/HTC pre-selected a launch date in advance for the Dream, in which case they easily may have squandered a handful of days waiting for their desired PR timing.
Furthermore, adding two days' development time doesn't mean shipping two days later, especially if that time is spent reimplementing functionality for which you already have a perfectly useful (although not shippable) alternative.
All it means is you'd have had to allocate two more days worth of some programmer's time away from some less important task. For something like this, the programmer wouldn't even need to know thing one about the Android project - just that "we need our own implementation of this standard Java function".
Official transcripts are available, usually, but the transcriptionists are private contractors rather than employees of the court, and are hired by one or both sides to create a record of the trial for appeal - essentially the attorneys are outsourcing that bit. Most documents in a court case are easily accessible online at moderate cost (typically ~$0.08 per page, to cover the cost of hosting) but transcripts can be insanely expensive, running into the hundreds or thousands of dollars. It's a bit of a racket to be honest, but court-employed transcriptionists would either raise the cost of filing in court or require more taxes, and legislatures keep courts on pretty tight budgets.
I don't like the idea of court video that much...bad memories of the OJ trial.
Even if it took 1 engineer 2 days to program rangeCheck, it doesn't mean Android would have been delayed by 2 days, since development of this magnitute is done in parallel.
Note he said "suppose". His argument also applies to the copied test code (that was removed).
Parallelization is limited similarly to http://en.wikipedia.org/wiki/Amdahl%27s_law (usually called critical path when applied to development). I don't know the dependencies for this code, though it is part of a sort (Timsort) which was likely used by a few things, being a utility. As for test code, although TDD advocates doing it first, it's not a functional dependency. But, given the crucial importance of compatibility in this situation (reverse-engineering standard libraries), you might well want it first, to catch problems ASAP when they are cheaper to fix.
> Q. Why did you copy the rangecheck function for Timsort?
> A. It's good engineering to reuse the same function if possible
That's Joshua Bloch (it was his own code he copied).
http://www.groklaw.net/articlebasic.php?story=20120419221941... I think "good engineering" includes the accelerating factors I mentioned above (also, future modifications/bugs-fixes can be made in one place, when the same code is called, which was Bloch's long-term expectation).
BTW: Some other people are responding without reading fully - please take the time to do so. It elevates the discussion, making it interesting and engaging. I am really delighted to be shown wrong and to learn something, but it's hard for a response to a comment to be persuasive if it doesn't address that comment.
A good point? I think it is false to equate a day's worth of work -- were rangeCheck to take a day of "writing, testing, debugging, naming, and documenting" -- to a day's worth of profits, but say you [they] are right, I expect Oracle can get away with $2083 -- 3e6/(24*60) -- of Google's earnings, assuming the first days of Android can be as profitable as "now." We'll see how Oracle equates their "nexus" between those lines of code and their profits, but it can't be as simple as Boise is trying to elide in this statement.
And how many developers work on Android? If it were 200 developers, then this one person day would equate to 1/200th of a day, or $150,000 in lost profits (according to Oracle's math).
I'm sure there are more than 200 developers, so that lost person day would mean much less than $150,000 in lost profits.
The thing I don't get is, rangeCheck doesn't actually _do_ anything. If it was taken out, the code would still function exactly the same, you just wouldn't get a nice exception when you pass in the wrong parameters (it'd still be an exception, just not as useful).
Actually, that's not entirely true. If you swapped the "hi" and "lo" parameters, the function would return an unmodified array if rangeCheck were taken out, rather than throwing an exception. But that's the only functional change.
So the idea that rangeChange is in any way significant is disingenuous at best, I think.
Seems like this is a good answer to those asking "how could learning to code help X to do their political job". That's how. By giving them some basic sense of proportions when it comes to software.
This doesn't quite follow... The objection I thought of is that if you have a populace where most members believe they know a subject well enough, perhaps because they "went over the fundamentals for a couple weeks in a college course", actual experts are less able to influence policy in an actually effective way since "everyone is an expert" and there will be disagreements; people won't see their ignorance as mountainous but merely as "a weekend of study would catch me up". There are plenty of good arguments for a broadly-but-shallowly educated populace, but I don't think this is really one of them.
The idea behind a liberal education isn't to get students to believe that they can understand a topic because they "went over the fundamentals for a few weeks in college". It's to get them to be able to rationally discuss the topic with someone who is an expert.
My wife tells a story about a business class she took in undergrad. It was about markets and investing for non-business majors. The professor started out very clearly by explaining that the class was not going to make them financial geniuses - that it would not make them all millionaires. But, that it would help them make better decision so they could understand what the recommendations of their financial planners.
In undergrad, I took a course on the "international political economy" (on of my favorites too - Thanks Dr. Katz). Now, I don't think that means I'd be equipped to negotiate a treaty, but it does help me follow international events with a bit more context.
Do you think we should get rid of Wikipedia, so people don't spend a few hours reading about topics, lest they start to think they are experts?
I guess it depends whether the oft-cited Dunning Kruger is linear. i.e. does a little knowledge of a subject allow you to understand how incomplete your knowledge is?
Sure, nothing is ever perfect. But think about the alternative. How do uneducated people know which "experts" to trust? The term "snake oil salesman" came from somewhere...
Learning a little about your car can help keep you from getting ripped off by a crooked mechanic. So why wouldn't learning a little about the world help keep you from getting ripped off by political leaders and other public figures?
That's how. By giving them some basic sense of proportions.
ftfy.
seriously though, most of these people that don't fathom the work that goes into creating software don't fathom the work that goes into designing a car, or building a house, or just what it takes to get a product made in china to their door.
I'm curious now what context his programming comes in. His bio doesn't really show any pre-law career: law degree 1971, law clerk 1971-72, private attorney 1972-78, assistant in the Solicitor General's office 1978-80, private attorney 1980-99, judge 1999-present. So it must've come in the context of his law career somewhere (some kind of DIY automation?), unless it's a hobby.
It is hard to believe that he has been a lawyer/judge for decades, yet is also an active programmer, and yet and doesn't know a thing about a language that is easily top 5 most commonly known and heavily litigated (Microsoft).
Judges tend to have ego battles with lawyers and like to show off in their decisions, trying to bluff and snow each other. That seems to be what this is.
I couldn't tell you the first thing about Perl, or any number of other common tools and languages - and I've been programming for about 25 years. I've just used different tools so far.
What's more interesting is Oracle's lawyer's "rebuttal" to Alsup (according to Groklaw):
> I'm not an expert on Java -- this is my second case on Java, but I'm not an
> expert, and I probably couldn't program [rangeCheck] in six months.
I don't know, how can anyone be taken seriously after something like that? He's clearly either stupid or willfully ignorant if he thinks he (a no doubt well-educated and intelligent man) couldn't learn to program rangeCheck in six months.
Yes, I know, of course his defence against this charge will be "I can't be expected to know industry-specific things like this," but then why on Earth are you allowed to regulate and prosecute it?
Perhaps you classify this as willfully ignorant, but I suspect he has no idea what it is like to program. He also probably assumes that if they're litigating it, it must be important or hard to do. With mental barriers like that, I could see him believing he couldn't do it in six months. But, again, you may consider that the same as willful ignorance.
It's almost certainly willful ignorance. Boies is a very talented litigator and one important skill for a litigator is quickly achieving a fluency in the subject matter of the litigation. Boies has done quite a bit of software work, so he almost certainly gets the gist of what it is like to program.
Boies is indeed well-educated and intelligent - he is one of the best trial lawyers in America. He's being somewhat disingenuous here, on behalf of his client; arguably, you would need to spend 6 months programming before you could look at RangeCheck and know what it does and why you'd want to use it. '6 months' is sort of arbitrary, but suppose your positions were reversed, and you were asked to fill in for David Boies and draft a fairly standard legal motion for submission to the court next week - you'd probably demur and say you'd need time to study legal procedure properly before you would feel confident drafting even a simple motion.
I think Boies is trying a forest-for-trees argument here, hinting that a jury might see the issue quite differently from a judge and that Alsup is discounting the significance of prior expertise and Bloch's existing understanding of Java. It's like one side saying '(something) is so trivial, anyone would have done that without thinking' and the other side saying 'well hold on, that task requires doing ten different things in the right order, and would take even an experienced person several minutes - looks to me like you made a very deliberate choice.' It's not a terribly strong argument, but Boies isn't there to represent himself; he's there to present a view of events most favorable to his client.
why on Earth are you allowed to regulate and prosecute it?
you would need to spend 6 months programming
before you could look at RangeCheck
Except that's sunken cost for education that's paid only once. You also need 12 years to go through high-school and another 3 years to get a BS.
RangeCheck is as trivial as counting your fingers. Counting reliably is learned in the first year of primary school, does that mean that counting isn't trivial because it took a year to learn?
I hope Google's response was "First year CS students have to implement more complex functions than rangeCheck on daily quizes within the first week or two."
This is simple - he is lying, but as long as nobody can prove he is, it is fine for him. Lying for the benefit of the client is the thing that lawyers do. Of course he knows it couldn't possible take any intelligent person with basic knowledge in the field six month to write this trivial piece of code. But he is hired to try and prove that Google owes Oracle 2 billion dollars for it. So he wouldn't be a good lawyer if he didn't try to claim it is a big deal. Just as criminal defense attorney would not be a good lawyer if he didn't try to claim his client is not guilty even though privately he would think the client did it. Of course, sometimes it looks hilarious, but in most cases it works, and works very well, judging by how much these people earn.
As a service provider to any industry, it is fundamental that one understand the product. Lawyering is no different but as an attorney it astounds me how many times this is simply ignored.
I believe it is incumbent upon the attorneys to understand the basics of any industry that they are involved with. I first learned BASIC in 1980(?) and have been an amateur ever since and I do believe that has helped me relate to my clients.
BTW, thanks to HN I "learned" Ruby shortly after the posting of a great article on _why.
What a stud, and what a perfect rebuttal to the deeply flawed "Please don't learn to code".
Willful ignorance is never a good solution. It's due in large part to the how fashionable it is to be "dumb", and "non-techy", and "etc" that our public policy w/ respect to science and technology is such a junk show. The only way out of the current patent mess and into some semblance of a functioning society which can actually enjoy the fruits of technology and invention is people like this Judge who have "learned to code".
Judge Alsup didn't learn to code during the trial - he already coded before it! It's just that he learned about Java during the trial.
---
Judge Alsup: "I couldn't have told you the first thing about Java before this problem. I have done, and still do, a significant amount of programming in other languages. I've written blocks of code like rangeCheck a hundred times before."
On a slightly different note (from that same Groklaw article), I like Oracle's defense against Google's claim that they didn't have access to the patents in question:
"Access? Google organizes the world's information! Of course they had access to the patents."
It's actually a little dangerous for the Judge to be introducing his personal experience like this. The Judge cannot serve as a witness, and editorializing in a way that amounts to the presentation of expert testimony can be grounds for reversal.
Yup, same here, mobile devices must go through a g+ signup to get to the content. This aggressive pushing of g+ is why i won't use it, and nobody else should either.
All due respect, but I think the Judge is missing the point here. Its kind of like saying "I can carve a turkey, therefore any high-schooler could do open-heart surgery".
Sure, its easy to check whether an integer is in a range. But THEN what do you do? Return 0? Throw an exception? How does the result of this little function combine with thousands of others to form a coherent and productive API? Of course, as system architects, we can decompose the large, complex problem into smaller problems, and repeat the process until the sub-tasks are trivial. But then for the Judge to look at one of the results of this process and declare the whole thing trivial is really a monumental misunderstanding of what goes into creating a world-class API.
It's good they got a judge who knows a little about programming :D As far as the case in general, I think it's quite interesting, but I personally feel Oracle has somewhat of a case, but to what extent, I don't know.
Another important question apart from whether Oracle has a case, is whether Oracle should have a case when the results of that case are taken in the context of the entire software industry. In other words, is the law giving Oracle a valid claim against Google worth the potential damage caused to software development outside of Oracle and Google?
Judges always take sides - they are humans after all. Their job is it to ignore that and let "justicia" decide. Given how ridiculous Oracle's claims are, he has to look after it that ridicule does not take over and damages the trial.. I don't think he really sides with Google, he has probably just adopted his programmer's world view in this case, and sees how ridiculous the claims really are. In many other tech cases (ahem, copyright infringement) judges are not as competent and can't imagine the real implications of their rulings.
This exchange highlights the rather unfavorable position that Oracle finds itself in on the copyright issues. It has won nothing of significance and stands to get very little from the jury on these issues. Concerning the broader claims on which the jury hung, it still faces a potent objection from Google that it cannot assert copyright violations based on the 37 API packages owing to defects in how the Java program was registered with the copyright office. It also faces the risk that the judge or a court of appeals will hold that APIs are not copyrightable.
A word on this last item: Much as the developer community believes very strongly that APIs should not be copyrightable, the Ninth Circuit law that is binding on this judge (beginning with Johnson Controls in 1989) is not particularly favorable in that it provides that software programs are to be analyzed item-by-item on the facts of each particular case to determine whether any particular component is protectible expression versus an unprotectible idea, function, system, or method of operation (this is in stark contrast to the First Circuit, which held that judges could make categorical judgments that certain components are functional by nature and hence unprotectible by copyright (as opposed to patent), as the menu structure was held to be many years ago in the Lotus/Borland case. Google is arguing the issue categorically ("APIs are inherently unprotectible under copyright law") but this makes for a tough sell in a jurisdiction where the appellate authority has said that such issues cannot be categorically determined. Google has alternative arguments, the main one tied to a leading Ninth Circuit case (Sega) that Google argues enables copying of functional elements of any program needed to ensure compatability. But, in my view, astute as this judge is, he will be bound to apply the fact-specific approach, making it tough for him to adopt Google's strongest argument and thus significantly reducing the prospects for a definitive ruling from the judge along the lines sought by Google (of course, this might come on appeal, where the court is free to reshape its earlier precedents in light of modern-day realities in the software world).