One basic travesty not covered in these comments is that a jury of people who have zero clue what software is or how they work are being asked to judge an entire industry on a topic they can't possibly understand. Sadly in civil cases the concept of a jury of your peers is not a right. In reality a jury of software engineers and the like would make more sense since they at least understand how software is put together. But that won't ever happen in our system because of the complexity of defining a peer in what might be an arcane specialty (not software but other things).
Yes, I completely agree with the above. Litigation is handled poorly, taxation handled poorly (federal and state), identity handled poorly (Social Security Admin), legislation, elections, law enforcement, and these are just the things I can think of...
At every step of the way, something or someone outside of your business can topple your personal life and your company's life just for trying to do business in the USA.
So you either try and deal with it, or go abroad and be labeled as something else entirely
LOL, kind of like the 18th century witch hunts where the witches cry, "If you must burn me at the stake, at least put me to trial by jury of OTHER WITCHES!" Imagine how that would have gone over :P
> One basic travesty not covered in these comments is that a jury of people who have zero clue what software is or how they work are being asked to judge an entire industry on a topic they can't possibly understand.
No, they aren't being asked to "judge an entire industry on a topic they can't possibly understand". They are being asked to answer fairly narrow questions of fact about specific actions of specific firms.
> Sadly in civil cases the concept of a jury of your peers is not a right. In reality a jury of software engineers and the like would make more sense since they at least understand how software is put together.
To the extent that a "jury of your peers" is a right anywhere in the US (the phrase isn't directly used in the Constitution at all, though the right to trial by jury is held to extend to it), it is, in fact, a right in most federal civil lawsuits with more than a trivial amount at stake. But the concept of a "jury of your peers" never meant people of like specific profession, it originally (in the Magna Carta) meant specifically rather than arbitrary justice of the king, nobles had the right to be tried by fellow nobles, and came to extend to the idea that other defendants have the right to be tried by a jury of the general citizenry. Which is the case with modern jury trials in the US today.
> But that won't ever happen in our system because of the complexity of defining a peer in what might be an arcane specialty (not software but other things).
No, it'll never happen today because that's never what a jury of peers meant in the first place, not because the concept is difficult to extend to arcane specialties.
>They are being asked to answer fairly narrow questions of fact about specific actions of specific firms.
They are incapable of having the knowledge needed to know when something is bullshit, however, meaning jury nullification is no longer a realistic option.
Is it Oracle's position that all implementations of the Java APIs (or partial implementations) are illegal, unless it's specifically allowed by Oracle?
That sounds ludicrous. What about unit testing libraries, for example?
Well, even though I don't like Oracle's standpoint here, I still feel that often the design of an API is much more work than the implementation of it. Implementing something is often just doing "the logical thing", whereas designing an API requires a lot of trial and error, and planning. An API describes in a way the greater design of the system (how things connect together), whereas an implementation is just filling in of the details.
This is a very common misunderstanding of fair use. Fair use is copyright infringement. It's just a legal defence when you are being sued. This is one of the big problems with fair use in the US. If you intend to use a fair use defence, you will almost certainly go to court. You will not get a summary judgement of "Oh that's obviously fair use, so we don't have to have a trial". This means you will have to pay a lot of money for a lawyer.
Having said that, IANAL and I could easily be wrong. This is not legal advice.
The real question (which seems already to have been answered) is are APIs a copywritable work, and if so is an implementation that follows the API a derived work? So is it an infringement if I simply implement the API? The original court decision said it is not an infringement, the appeal said it is and the supreme court decided not to hear a further appeal. That's why we are left with a fair use defence.
This is quite spectacularly bad for the industry IMHO, but there is not much we can do about it now other than to have US citizens lobby congress to pass a new copyright law (which seems pretty unlikely). If it turns out to be fair use, that will make it slightly less bad. However, expect rent-seekers to start coming out of the woodwork to sue for implementations of specifications anyway. They know that they can simply sue you for less money than it will cost to defend yourself with a fair use defence. Expect this to be the new patent troll.
Wouldn't an Oracle win be good for Free Software? Google isn't the good guy here, they wanted to create derivative work without GPL'ing it. Which they considered a "virus" and "infectious". I see companies like Google trying to have their cake and eat it too. Everyone wants to lean on someone elses work but not use GPL or license their own as such.
It's only bad for the industry as it exists today. Tomorrow hopefully when Oracle wins this as it appears to be a slam dunk, libre software becomes the norm rather than the Frankenstein's monster that Android is. I would either do it all in-house as Apple did with iOS or if you want to create a derivative work, use GPL'd code. Google didn't want to do the hard, time consuming work of API design. If it was the easy part, why didn't they do it?
Open and shut case in favor of Oracle. And after a rough adjustment period, I think it will promote Free Software to new heights industry-wide when they win.
Not in my opinion. The GPL is a license that depends on accepting the license -- or not. It is always acceptable not to accept the license and write your own. That's part of software freedom. In fact this judgement puts GNU Classpath in a very tenuous position because their code is also not based on the the GPLed version of Java (having been written before Java was GPLed).
Even GNU is now in jeopardy because who the heck owns the copyright for POSIX??? Is there any license language in the specification saying that you can implement it? I have been too scared to look up until now. This is incredibly important because all of the GNU tools and the Linux kernel have been implemented independently and are not derivations of things like BSD.
No. This is a nightmare for free software because it means that every single RFC in existence now needs a license thanks to copyright lasting for the life of the author plus 95 years. It means that we can never interoperate with services that choose not to grant a license to their API. Even if you reverse engineer it, expect a lawsuit having to defend yourself using a fair use defence.
And if you live in most of the world that doesn't have fair use. Well, you are just screwed.
The only thing this means is that free software will be marginalized. We'll be set back 20 years.
We disagree overall. In sum, I think it's a distinct possibility free software wins with an Oracle victory. Your position is that everything is fine and dandy today. I disagree because otherwise this wouldn't be in court. There are legitimate issues that need resolved, neither Google or Oracle are good guys. Google created their own problem trying to cut corners/save money and it backfired. They admitted in their emails it was a risk and they went for it.
But I did want to clarify one thing you said because I found it confusing.
> The GPL is a license that depends on accepting the license -- or not. It is always acceptable not to accept the license and write your own.
If you do use GPL code you have to also license it as GPL. Any derivative work you create containing even a smallest portion of the previously GPL licensed software must also be licensed under the GPL license. That's what Google meant when they called it infectious and viral. Unfortunately for these large corporations, it was also the solution (other than doing the heavy lifting in-house as Apple did).
When you don't accept GPL'd code, you write your own code and license (or adopt another).
Agreed in this particular case the API was much more valuable than the implementation. You can't mean all APIs require more work than implementations though? Implement the class AI with this API: start, stop.
I am far from an expert in these matters, but as I understand it there are fair use exemptions when the purpose of the implementation is for interoperability and compatibility. Given WINE's purpose, they would seem to be on safer ground.
I believe this was one of Google's initial arguments, but as the DoJ stated when they weighed in:
>"The Android platform uses the Java programming language, but [Google] purposely designed Android not to be compatible with the Java platform or interoperable with Java programs." [1]
A strange notion of 'not compatible'. I wrote a Java library in 1996 that's been used unchanged in Android apps. (Yes, the app author has to compile it to Dalvik.) [Added: it was always my understanding that this ability to use Java code was the whole point of using the Java API.]
What cases codify interoperability as a fair use exception? Wouldn't perfect interoperability have a bigger impact on the commercial value of existing products by making it easier for customers to switch to the drop-in replacement?
I think Apple would have a tough time arguing GNUstep was illegal given the wording of the OpenStep standard document NeXT and Sun produced in 1994. It was meant to be a standard.
It is clearly not ludicrous, as this fight has been going on for 6 years now. Oracle believes in it, and of course their well-compensated lawyers believe in it.
What I don't understand is WHY Oracle wants to go through with long legal battle. They make good revenue on their database ecosystem as well as some other products of dubious value (has anyone ever enjoyed Oracle EBS?). They've secured their interests in Java on the serverside, android is not a threat there.
Is this REALLY all about monetizing their purchase of Sun Microsystems? Seems like a round-about way to make money and it certainly carries a lot of risk.
Doesn't this action also warn other companies away from using Java (or any other Oracle technology) for anything ever again? It would if I were running a company or had purchasing power.
I'm guessing that Oracle is looking at the short term gains and ignoring the long term impacts. Business as usual in the corporate world. :/
Sun's documentation specified that the APIs were copyright, and in an email on March 24, 2006, Andy Rubin wrote that: "Java.lang apis are copyrighted ... Sun owns the brand and ip [and} Sun gets to say who they license the tck to" (edited for clarity).
That was before Sun went open source.
By 2007, Google was making serious efforts to "scrub" its code for references to Java. In 2010, it said the "bad words" were "Java, License and Patent".
On April 9, 2008 Google's Alan Donovan wrote an internal email to java-users@google.com explaining how to turn off "Sun proprietary API" warnings issued by the Java compiler.
What's most striking to me is how easily this could have been avoided, everybody knew what liabilities would arise from betting your entire mobile platform on the goodwill of a competitor. With the massively overqualified talent pool Google hoards, they could absolutely have implemented a completely new language, compiler, and VM themselves. I'm sure this alternative must have been at least on the table. Does anyone with insider info know what the reasoning was behind that decision?
If anything, Google's desire to reinvent the world has held them back here. They could have just forked OpenJDK and made their lives easier, in retrospect. Into this went their irrational fear of GPL (describing it as 'viral' or 'infectious').
The fact remains that not even Google can reinvent the world in their image. Building a whole new language at the same time as a legacy-prone ecosystem requires too many moving pieces to fit together quickly. They picked some middle ground, java allowed them to tap into the large java talent pool (then and now). Reinventing the guts allowed their ambitious engineers to show off, which they did, but maybe not as effectively as if they'd built on top of the work of others.
OpenJDK was released around the same time Android was announced as imminent, and only a little before Android was released. Google could not have forked OpenJDK for Android at launch without doing a bunch of rework and delaying the launch, because the work they did getting Android ready mostly predates OpenJDK.
No, May 2007 to September 2008 isn't two years, it's 1⅓ years. And Android had been in the works for years before that. (Even before the 2006 promise by Sun that Java would be released as open source.)
> Into this went their irrational fear of GPL (describing it as 'viral' or 'infectious').
Why irrational? If they used the GPL, a lot more of Android would need to be open source today, yes? Including proprietary hardware things that can't be open sourced?
This is not true. You could link the libraries as normal while maintaining your proprietary code. The GPL only asks you to release the code if a) you mix your proprietary code without separation from the GPL code b) you distribute the software to 3rd party. b) rarely happens if you sell the device as a closed/embedded system.
Also, they could use BSD code as well that comes with a more permissive MIT licence.
Correct in some way. Given the source code, e.g. Drupal (GPL v2), if you develop a proprietary module that can be shipped independently but relies on the Drupal Core or other GPL module, you still not violate GPL. It doesn't matter you need to compile it or not, at the end, most scripting language is compiled to bytecode in some for of JIT.
I mentioned GPL in general, not dissecting to the various version, because the parent reply was about Google's fear of GPL (in general).
I'm not sure I understand why forking OpenJDK would have been legally distinct from a from-scratch re-implementation. In both cases, Google is re-using the APIs that Oracle is claiming ownership over.
EDIT: I just realised that OpenJDK is released by Oracle. Never mind!
Exactly. And, let's be honest, the position Google took would have been supported by Sun. They would have wanted other implementations of their API.
Oracle is only doing this because they can. They have the money. They have the desire (to fuck with Google). So they do it.
I really don't get the anger toward Google. I don't think they did anything wrong here. If they did, it will haunt a lot of other companies than just Google.
True. But the fact that Google staff felt guilty about ignoring copyright notices and spent years removing evidence from their code is a pretty good indication that they knew they were doing something wrong, even if technically they weren't...
I'm not an insider, but I think the decision making is pretty clear: they bought Android (the company). They could have started something from scratch, but they felt they could get to the market faster buying up a company that was already part of the way there.
Android could easily have been built on the GPLed version of Java. But again the reasoning behind the decision of building your own JVM is pretty clear: Android wanted someone to buy their company and felt that the GPL might make the sale difficult. Of course with Google buying, they probably wouldn't have cared, but by the time Google was doing the buying, the decision was already made.
Android's success was that its foundations was something the community knew. Java was either #1 or #2 of most popular language and their was a vast mind share that could be utilized.
A new language for a new mobile platform would have been disastrous. Could you imagine someone saying her is our phone everyone learn it and make great apps for launch in 6 months?
Apple had the luxury of being the first to sell smartphones, they could do it in whatever language they wanted. Android could never have tried to do the same thing.
Nokia's smartphone line was already several generations old when Apple introduced the first iPhone... The Symbian OS had a 67% market share in smartphones in 2006. The first version of the Communicator with 3rd party software ecosystem, the 9210, was released in 2001!
Yes I can absolutely imagine that. I believe such a decision would have been welcomed enthusiastically. Early adopters of a new hardware/OS platform are extremely easy to win over with an exciting new language. Others would have followed in good time.
Don't you see all those "why we switched from language A to language B" stories that seem to come up every other day? No need to read them. The content is not important. All they ever mean to say is "we were so bored with that old language and now we're thrilled to try something new!"
Oracle already won a case that deemed APIs copyrightable. Which is bad for the industry at large. Except for Oracle and patent trolls off course. Google is now arguing whether it copied code in a fair way or not. They can't argue that they didn't copy anymore because they have already lost that case.
What is happening now is more like proving to your lecturer that you didn't copy your whole assignment from Wikipedia. You only extracted some information from it and majority are your own.
Oooooo shit. Isn't this phrase horrible? Don't get me wrong, I think suing over checkRange is ludicrous... but doesn't saying "declaring code isn't code" terrible? He comes across as he's trying to avoid the issue by playing with words. Of course declaring code is code. The clue is in the name, "declaring CODE".
Of course code declarations are "code" the same way a library listing of book titles is made up of "words". Unique, creative words that cannot be explained by chance or well known to the audience before their creation by the author.
Yet, none should be protected by copyright, this is the intention of "is not code".
Yeah, same thought here. I understand what he meant, and pretty much everybody on HN understands it.. but to a (potentially) non-technical juror, that just does not sound good at all. I hope that one gaffe doesn't cost Google the case.
If the juror can't understand the distinction between declaration and implementation, then he is not fit for this particular case. Isn't it smart of him to make that point explicit?
He made the distinction extremely poorly. And jurors are not expected to be experts in anything. It's the lawyers' job to make the case to people who are not experts.
In fact, jurors are instructed not to make use of any particular expertise they might have, and instead to rely only on testimony heard during the trial.
"declaring code" means headers, or in the case of Java function specification/prototypes, right? As in "declarations". I think it's technical language twisted through legalese.
Yep. The argument is that API specifications are not code, and reimplementing an API based on specifications is not a copyright infringement. It should not matter whether the specs are written in a natural language or a more formal one. Specs are more like ideas, and ideas cannot be copyrighted (the specification document itself could constitute a copyrighted work, though!)
The problem is that to reimplement the spec in this case, you do have to copy the formal declarations verbatim. Whether or not those "sentences" are protected, and pass the threshold of originality [1], is what is at stake here.
> He comes across as he's trying to avoid the issue by playing with words.
The audacity of Google is astonishing. Betting your mobile business on stolen concepts and getting all third party vendors on board despite the imminent legal trouble is quite a feat.
I actually hope for some fallout for Google; anything else would be a travesty.
I am curious about the implications of this lawsuit for Free SW. Claiming copyright over the Java API is not that far from claiming copyright over a C header, and most projects do just that.
On the one hand, RMS has said that "just using structure definitions, typedefs, enumeration constants, macros with simple bodies, etc., is NOT enough to make a derivative work. It would take a substantial amount of code (coming from inline functions or macros with substantial bodies) to do that".
On the other, I imagine that somebody could get in trouble for e.g. copying the files under linux/include and providing a proprietary implementation underneath (unlikely scenario, you get the point).
I'm going to go out on a limb here. While I'm definitely not on Oracle's side for this case, I'm not so sure I agree with the statement that declaring code is not code in general.
To me, that's akin to the NSA collecting phone call metadata and then claiming that it's not really a problem because they don't actually have the contents. Except, as we know, with sufficient metadata, you don't even need contents to figure out what's going on.
The same goes with APIs. With sufficiently comprehensive APIs or sufficiently advanced programming language facilities, which are becoming more and more commonplace (more sophisticated static type checking, macros, and template metaprogramming), more and more information becomes encoded in the declarations, to the point where you really can't claim that the declaration isn't something you should be able to copyright. With the Java API under consideration I agree that the APIs probably shouldn't fall under copyright, but I'm not sure I agree with this precedent being set here more generally.
>more and more information becomes encoded in the declarations
I don't see how this is true at all. We've moved continually toward higher-level APIs. There's a lot more "magic" in String.split than strtok.
If your API is so specific that the implementation is entirely implied by the declaration, then all that means is that the implementation itself is trivial, in which case I don't think your API implementation should copyrightable either.
But it isn't a single function definition it is the whole API. Deciding that you want to pitch your API at a specific level of abstraction and ensuring that level is consistently maintained across a whole language is hard work.
The recent criticisms of ASP.Net Core's API changes or PHP's "interesting" APIs over the years surely demonstrate that writing language APIs is hard.
Depending on perspective (and perhaps language), I've come across the analogy comparing this to having a book with the same (mostly generic) table of contents.
Though a ToC can be copyrighted. Imagine the situation of a physics text where there may be only a handful of reasonable ways to break down the information and order it. Would it be reasonable to sue someone for having the same ordering (deliberately in this case), but with the content rewritten from scratch (ideal since Google does have those 9 offending lines).
I would disagree on that declaring code is not code.
If I declare my api uses
a GET to /user/:id to get a user, does that interfere with someones copyright that has an api that uses a GET to /user/:id to get a user (everyone I think)?
This is just a declaration. The actual code is buried in the methods and means that actually GET the user.
This is not quite what is going on with this trial, but it's a very simplistic version. If we can't use the same declared API end points, then it will be much worse than patent trolls.
The NSA are collecting private metadata, that's the problem there. The Java APIs are public information (everyone who creates Java programs needs a copy of them and needs to know what they do).
> Bicks moved on to another e-mail, which he was allowed to put up on the courtroom screens. The message was a note from Andy Rubin to upper management, laying out strategic options for Android. One option was to do a deal with Sun, while a second option to go ahead and use Java without a license, but the company would "make enemies along the way."
If it weren't for the dreaded consequences to the industry, I would love seeing Google losing this. They well deserve with these attitude. But then I remember their enemy is Oracle. Oh my, I will close my eyes and flip a coin...
You think they should lose based on them breaking a law or you would want them to lose because you don't like them? If it's the latter I guess it's a good thing you don't like Oracle a little more.
As you pointed out, this case had far ranging consequences for the software industry and any personal opinions of how much you personally like or dislike any company need to be 100% put aside.
I don't need to put nothing aside because I'm not the jury. I don't like Google's attitude and I don't like Oracle's attitude neither. To me both deserve to lose, but how is that possible?
No matter what the result of this will be, it will be sad. They are the worse that can happen to software industry.
The more I read about this case the more I think Oracle is right. And the more I think most people, HN readers included, are grossly misinformed.
In the last big thread I asked if anyone could provide concrete examples of terrible things that would happen if Oracle won. I didn't get a good response but the comment was buried. My question stands if anyone has a good answer. I'm very open to discussion here.
It's really not about whether bad things would happen or not. It's about what is the correct decision. I define an interface for a box. It has methods push() and pull(). I implement a wooden box that conforms to this interface. Many happy users push and pull my box via the interface all day. Someone comes along and implements a metal box that conforms to my interface, so that users can push and pull a metal box. I sue that person and win. Does this sound correct to you?
What bad things would happen?
* Compiling against any C header files, such as kernel headers, is called into question. This has massive ramifications because of many for-profit businesses that compile against the headers of GPL code, as is standard practice.
* Amazon S3 API is widely implemented by other cloud storage providers. Sharing an API between products makes it easy for customers to switch one application between different providers.
* This is copyright, not patent. Which means there is no requirement to register a design, no oversight and no cost.
* It could cause a rush of people just writing obvious API combinations to be the one who "got there first" and potentially harm their competition.
> I sue that person and win. Does this sound correct to you?
Sure. That's plausibly reasonable. The API definition is significantly more detailed that just the method names. The metal box maker could easily have created their own API. But instead they use an API created by someone else.
* Compiling against headers is an important issue. That would be bad. I raised this question in the last thread but it didn't seem to be an issue.
* A closed S3 API seems fine to me. Amazon doesn't have an obligation to make switching easy. At the same time they'd have incentives to make their API open to encourage people to start using S3. Permissive open source software is exceptionally popular these days. If Amazon wants to write a closed API that presents an opportunity for someone else to write an open API.
* I think we'd be in a much better place if software could NOT be patented but APIs were copyrighted. Implementation code is already under copyright.
* I don't think "got there first" is a real concern. TCP and UDP both define connect(), send(), and receive(). But they are radically different APIs with radically different specifications.
Thank you for your thoughtful reply. This is a good discussion.
If APIs are copyrightable (even when documented and released for free in the open):
- Wine and ReactOS would become illegal. In fact, any layer to run Windows apps would become illegal. The only way to run a Windows app would be through Microsoft's blessing
>IANAL but it seems like it would set the precedent that you cannot do clean room implementations that are legal.
the practice that interfaces are copyrightable seems to has been in place for quite some time. AMD couldn't make Pentium socket compatible CPU. We have LGPL for the same reason. The miracle of IBM compatible BIOS may be attributed only to accidental benevolence of IBM :)
Google is on the receiving end right now, yet the copyright protection of the interfaces plus DMCA is what gave rise to the "platforms", and Google just happens to be a one of the 3 largest ones. Unfortunately one can't have it both ways.
Anyway, Stalman's preaching may happen to be just a very concrete practical advise after all :)
"The K7 was AMD's seventh-generation x86 processor, making its debut on June 23, 1999, under the brand name Athlon. Unlike previous AMD processors, it could not be used on the same motherboards as Intel's, due to licensing issues surrounding Intel's Slot 1 connector, and instead used a Slot A connector..."
The simplest way to mitigate the risk that you might be sued if your code is too similar to someone else's code is not to share it openly in the first place. If Oracle win then every large corporation will have to ask the question "Can we release our code? Do we know it's all ours and not something a developer took from a closed project[1]?". Many will choose to not to because the risk is too high.
[1] Knowingly or otherwise. If a dev bases their code on a Stackover Flow answer they could be unwittingly using closed code.
Safety by obscurity might not be a magic bullet. I'd still be able to tell much just from the compiled binaries.
For example, I wouldn't detect your code snippets from stackoverflow but would be capable of creating a very comprehensive list of third-party dependencies you are using.
There are companies completely dedicated to the software originality topic: http://triplecheck.net/
It's called Discovery. When a company gets sued, the first thing the opposing counsel does is request they provide all communications relevant to the case. Judges tend to frown on non-compliance with such requests (e.g. shredding papers, deleting emails, and other such similar shenanigans) and tend to send people to jail or declare judgements against the offending party. This is one of the reasons why you should be careful about the emails you send using company systems. You may one day have to read it in front of a jury.
So let's say I have a file PayYourSalary.scala, and somewhere in that file there is a method:
def payEmployeeForOneDay(rate: Int, minutesWorked: Int = 8) = {
// other stuff here
}
As you can see, there is a bug here. This method used to have a parameter hoursWorked with a default of 8 (a reasonable default!). But then it was changed to minutes and someone forgot to update the default. Because of this, some people ended up getting paid 1/60th of what they were supposed to.
That's a declaration but it certainly looks like a bug in the code to me!
Larry is being absurd.
If it's in a file with a .java extension (or .scala, or .c or even .h) it's code. If it's source that a compiler or interpreter sucks in then it's code.
Your sample code is an interesting case because the nature of declarations in Scala (among other languages) is distinct from the nature of declarations in pure Java.
Setting a default value for an argument is an assignment, a real action that is taken by the code at runtime. The Java equivalent would be in two (or three, depending on how you count) parts, something like:
// Do the things.
// If minutesWorked is left at -1, this procedure will use the default value of 480.
void payEmployeeForOneDay(int rate, int minutesWorked) { // inert declaration
if (minutesWorked == -1) { minutesWorked = 8; } // active code with bug
// ...
}
Here we have a human readable specification of behavior, which has zero impact on the compiler or generated code, a machine readable description of an interface for other bits of software to interact with this bit of software, and some working code that will make something happen.
This is interesting because the specification being described and implemented is not fully encapsulated by the function declaration/API, but also by the "non-code" english comment attached to it.
Is it fair use for me to copy this API by using the same function declaration but rewording the documentation, but writing my own implementation of the function body to correctly match the comment? What if I implemented a bug-compatible version of the body from scratch, and rewrote the comment to match?
Here's an question that should pair up pretty well to the API copyright-ability question. Is the list of words and their order in a dictionary copyrightable?
I can see the definitions being copyrightable yes, but I don't see how an alphabetically arranged list of words (just the list) would classify as copyrightable:
I can't really tell who isn't bothering to explain what an interface / API is & why you might want to copy one vs make your own. Is it Larry or the writer of this article?
If it's Larry, then it is interesting to see this sort of laziness when so much money is at stake.
Terrible to read what a song & dance Oracle is putting on. 11,000 lines of code! gtfo
I think he means that the code that doesn't do anything, just describes the interface between two software components is not a code (that you should be prevented from copying) because of its one to one equivalence with the interface.
Describing interface with words is exactly the same as declaring it with code. So such code is nothing more or less than verbal description of the interface (or any other description of it using any other syntax).
Not sure if that helps. If you can copyright interface, or just algorithms. Unless Java interface was specifically made free and open by Sun then it's really clear cut case.
I think he means header files compile to nothing, they do not end up as actual computer instructions. They only serve to help programs call the actual implementations (which he'll see as the real code) correctly.
I'm not sure if this interpretation of his words is what he meant to say.
I'd argue that code that "compiles to nothing" can be protected by copyright, too, even if it is not distributed to customers. E.g., extensive documentation inside comments in the source files is definitely copyrighted. Complex build rules might be copyrightable, too, although they definitely end up in the distributed application.
Therefore, it would probably be counterproductive to assert such a thing in court.
Yes.
I just wanted to clarify that code that "compiles to nothing", e.g., build instructions, may still be copyrightable.
Therefore, I do not think that Page wanted to extend his definition of "non-code" to anything besides interfaces/declarations.
I read it as .h vs .c files. There's code that declares what code is, e.g. the API, and then the actual implementation of that API. His argument is only the latter is copyrightable.
I think if I were Google I would be moving everything I have access to non-Oracle technologies. If that means porting Dalvik to Rust/Swift/Go then so be it. Basically, blackball Java and suck all the air out of the room.
Doe anyone know why Google decided on a jury trial? It seems they are technically in the right, but explaining it to an educated judge in a bench trial would be a lot easier than a random sample of non-programmers.
'The lawsuit began when Oracle sued Google in 2010 over its use of 37 Java APIs, which Oracle acquired when it bought Sun Microsystems. In 2012', am I crazy or is this just a misprint? Oracle sued Google in 2010 before they acquired Sun Microsystems?
The deal may have taken a while to complete (as late as 2015), but Oracle got to integrate Sun's assets into Oracle as early as 2010, and indeed that is when everyone (including Oracle) believes Sun was acquired.
The lawsuit began when Oracle sued Google in 2010 over its use of 37 Java APIs, which Oracle acquired when it bought Sun Microsystems. In 2012, a judge ruled that APIs can't be copyrighted at all, but an appeals court disagreed.
Either Google needs some better lawyers or this article is not telling the whole story. This should be a very simple issue to explain, open and shut case.
Not sure if I agree. I find that coming up with good interfaces is often more of a creative challenge than the implementation. API's are worthy of some sort of protection since ease of use is a definite competitive advantage.
Also, you can easily screw your perf with bad interfaces (especially in C++). E.g., not templatizing, requiring extra allocations, type impedance mismatches, vtable bloat, etc. The interface certainly affects how the machine executes your code.
Patents have been granted on claims that essentially cover an API. I think it would be harder to get such patents issued today than 10 years ago though.
Oracle will likely win on technical grounds regarding APIs but only because the law is unsuited to software. It's whether a judge should overrule it on principle of not patent trolling as it's against the public good.
It's the fact they bought Sun with the intention of suing Google in order to profit from Android's success. If it was Sun suing it would different.
After Elon Musk pledged that other car manufacturers could use Tesla's patents is Larry Ellison going to wait until all cars are electric and Tesla is a minor player before buying them out and immediately turning around and suing the entire industry?
That is a good question. I think short-mid term not much, as a huge amount of infrastructure is dependent on the jmv as a platform, switching to .NET or independent solutions is only a long-term option.
I don't know how big a long-term impact will be, but I think it won't be neglible...
How are they "being dicks"? It's their job, they have to ask questions and find cracks within the legal system to prove their point. That's literally their job, no more, no less.
I would contend that finding cracks doesn't lead to as many successful convictions as people think it does - and probably leads to a great many wrongful ones. Focus should be on the facts. It's also an approach that puts those who are better at concealing these cracks (think sociopaths; Bundy) at an advantage.
Yeah I guess - but for me it seems like the focus should be on the facts rather than theatrics. That said I have sat on a jury where the performance of the prosecuter played a pivotal role in papering over some of the mistakes in the investigation. But the guy was a perfect gentleman at all times. Innocent until proven guilty.
That said I have sat on a jury where the performance of the prosecuter played a pivotal role in papering over some of the mistakes in the investigation.
I sat on a jury once where the behavior of the prosecutor really hurt his case, because he acted like a total dick and was demeaning and rude towards the defendant. In theory that should have nothing to do with the actual merits of the case, but people being people, it created a certain measure of sympathy for the defendant.
In the end, we acquitted the guy for a number of reasons (mysteriously "missing" evidence, an incompetent investigator, perception that the investigator and victim may have lied, etc.) but the prosecutor's behavior was definitely something that all (or most) of the jurors picked up on and commented on.
I believe that simple things like how the prosecutor (or the defendant) carry themselves, and how they act towards other participants in the trial, can absolutely affect the outcome of cases, at least sometimes.
That seems like a stretch. Judges routinely make questionable rulings. Heck, in this case Alsup did a great job in the first (jury) trial .... and then Oracle appealed and the original decision, which I thought was right, was overturned by judges.
