Oracle v. Google - Judge Alsup Rules APIs Not Protected By Copyright(groklaw.net)
groklaw.net
Oracle v. Google - Judge Alsup Rules APIs Not Protected By Copyright
http://www.groklaw.net/article.php?story=20120531172522459
29 comments
I like how Florian Mueller manages to spin this[1] as a two year respite for Google who will eventually lose on appeal!
[1] http://www.fosspatents.com/2012/05/judge-says-google-only-us...
[1] http://www.fosspatents.com/2012/05/judge-says-google-only-us...
I can't remember ever having read a legal document that pulled me in as this one most-definitely did. I found it fascinating and educational. Every time I had a question Judge Alsup answered it. In detail. It clarified many points and questions I had about some of my work and upcoming projects where the question of interface vs. expression was surely going to come-up. The other thing it did for me is further clarify the demarcation line between copyright and patent. I had a very good idea, but this document explored edges I didn't know existed.
Ralph Yarro is bummed.
Update: Grocklaw now links directly to the PDF:
http://www.groklaw.net/pdf3/OraGoogle-1202.pdf
Someone linked to this in the groklaw comments: http://www.scribd.com/zdnetrachel/d/95477548-Oracle-v-Google...
I assume this is legit.
Someone linked to this in the groklaw comments: http://www.scribd.com/zdnetrachel/d/95477548-Oracle-v-Google...
I assume this is legit.
"So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different. When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law."
Yep, that's the juicy excerpt. Other bits that I found salient from the ruling, on patent vs. copyright:
Much of Oracle’s evidence at trial went to show that the
design of methods in an API was a creative endeavor. Of
course, that is true. Inventing a new method to deliver a
new output can be creative, even inventive, including the
choices of inputs needed and outputs returned. The same is
true for classes. But such inventions — at the concept and
functionality level — are protectable only under the
Patent Act.
...
That a system or method of operation has thousands of
commands arranged in a creative taxonomy does not change
its character as a method of operation. Yes, it is
creative. Yes, it is original. Yes, it resembles a
taxonomy. But it is nevertheless a command structure, a
system or method of operation — a long hierarchy of over
six thousand commands to carry out pre-assigned functions.
For that reason, it cannot receive copyright protection —
patent protection perhaps — but not copyright protection.
Does this mean that companies will start to patent their APIs? I wonder if this means we should expect virtually the same case s/copyright/patents/g a few years in the future.
Patenting of APIs/protocols/file formats has been going on for a while. The bar for patenting an API will be much higher[1] because it has to be a novel concept.
[1] In theory. In reality, the USPTO will issue anything.
[1] In theory. In reality, the USPTO will issue anything.
USPTO will issue anything, but the patents rarely survive. In this litigation, all the patents brought out by Oracle were struct down.
Sure but if it had been a company (or individual) other than Google with less than millions of dollars with which to defend itself how would it have turned out? They'd be out of business leaving lawyers to feed upon the carcass.
How much it does it cost the US tech industry to get all the garbage rubber stamped by USPTO struck down? How much good innovation from small business and individuals has been killed off by small trolls and big company bullies?
How much it does it cost the US tech industry to get all the garbage rubber stamped by USPTO struck down? How much good innovation from small business and individuals has been killed off by small trolls and big company bullies?
The fact that patents don't survive only matters when two giants battle. Not when a larger company starts litigation as a method to stifle a startup.
whether patents survive litigation or not is irrelevant unless both parties have equivalent resources to spend on litigation. large companies can use their patents to bully small companies into paying licensing fees without having any fear of needing to defend their patents.
which seems to be a problem with the patent invalidation process - it shouldn't cost anyone money to invalidate a patent. If a patent holder's patent is found to be invalidated, the costs for the entire process should be be beared by the patent holder!
That would only work if patent holders were required to post a bond or something at time of filing for the costs of invalidating their own patents. Otherwise, costs will be incurred by the victim in the process of invalidating the bogus patent that will not be recovered until the invalidation is finished. If they run out of money in the mean time, they die, and the patent stands.
It would be very bad to require such a bond to be placed for new patents, as that would be the final blow that kills the idea that patents protect the "little guy."
It would be very bad to require such a bond to be placed for new patents, as that would be the final blow that kills the idea that patents protect the "little guy."
[deleted]
Actually 2 of them survived until trial (1 still facing further review), but Google was deemed to not be infringing by the jury.
The judge ordered Oracle to limit themselves to their ten best patents for the case and Oracle chose ten.
Google then went to the Patent and Trademark Office to try to get those ten struck down.
Two out of ten survived review. Eight were declared to have been mistakenly granted. (One of those is still under appeal.) That rate -- eight out of ten of the very best selection of software patents obviously bogus -- is actually low; many more than eight out of ten are bogus on average, even when only considering the best ones. But that was all Google could get from the PTO.
Note that your startup can't just go to the PTO like that when attacked with bogus patents -- it takes years and millions of dollars.
Then the trial started with two remaining patents. But they were not the two that survived review. One survived review and was in the trial. One is rejected on review but can still be appealed and also was in the trial. And one was rejected on review and then re-accepted on review appeal, but had still been rejected when Oracle requested an acceleration of the trial date so they had to abandon the claims to get their earlier trial date. The other seven remain rejected.
Google then went to the Patent and Trademark Office to try to get those ten struck down.
Two out of ten survived review. Eight were declared to have been mistakenly granted. (One of those is still under appeal.) That rate -- eight out of ten of the very best selection of software patents obviously bogus -- is actually low; many more than eight out of ten are bogus on average, even when only considering the best ones. But that was all Google could get from the PTO.
Note that your startup can't just go to the PTO like that when attacked with bogus patents -- it takes years and millions of dollars.
Then the trial started with two remaining patents. But they were not the two that survived review. One survived review and was in the trial. One is rejected on review but can still be appealed and also was in the trial. And one was rejected on review and then re-accepted on review appeal, but had still been rejected when Oracle requested an acceleration of the trial date so they had to abandon the claims to get their earlier trial date. The other seven remain rejected.
I thought part of the case was already a patent lawsuit. Our are you referring to the possibility that Oracle might get patents specifically on the Java APIs and sue with those?
How does this effect the GPL? Is this no longer something that the GPL can restrict?
http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
No, it's a different issue. When you take a GPL (not LGPL) library (not an API, an actual piece of software) and "use it", you're creating a derivative work of that library. The only way to license such a work is under the GPL. Because if you don't, you don't get a license to use the library (not the API, the software) under copyright law. But it's the copyright on the software that is the teeth here. In principle you could distribute your code under GPL-incompatible licenses, but only as a piece of useless source code. Anyone who wants to ship useful software needs to abide by the copyright of the software they use.
What Google (really Harmony) did is mere cloning. They (very) expressly didn't use Java the software, only the "Java API".
What Google (really Harmony) did is mere cloning. They (very) expressly didn't use Java the software, only the "Java API".
> In principle you could distribute your code under GPL-incompatible licenses, but only as a piece of useless source code.
It's not useless. Your customers can compile it, and link it to the GPLed library. After all the GPL allows you absolute freedom of use, as long as you don't distribute the derivative work.
It's not useless. Your customers can compile it, and link it to the GPLed library. After all the GPL allows you absolute freedom of use, as long as you don't distribute the derivative work.
No, the point is that your code is the derivative work. If you distribute it to the customer with the intent of it being a useful integration, you can only do so legally under the GPL. The GPL library owner could sue you to stop that distribution.
Obviously there's some gray area if you, say, publish your code in the context of fair use (as an academic paper, say) and someone else does the integration work without your blessing (this is what I meant by "useless piece of source code"). But simply saying "build it yourself" is not a get out of jail free card for the GPL.
Obviously there's some gray area if you, say, publish your code in the context of fair use (as an academic paper, say) and someone else does the integration work without your blessing (this is what I meant by "useless piece of source code"). But simply saying "build it yourself" is not a get out of jail free card for the GPL.
If my code just uses APIs from a GPLed library, how is it a derivative work? APIs aren't copyrightable (yay).
In my understanding only the compiled result which links to the GPLed library is a derivative work.
In my understanding only the compiled result which links to the GPLed library is a derivative work.
The GPL never forbade creating a nonfree library with the same interface as a free one.
That's my reading too, though I remember someone who wrote a MySQL API layer that was not libmysql was accused of violating the GPL. Amusingly, MySQL is now an Oracle product (though I'm not sure it was at the time).
It had been MySQL's standard MO for a while. Their point of view was you either had to completely open source your product, or you had to pay them lots of money. Using it in an in-house webapp, or as you mentioned, reverse engineering the API, would get them knocking on your door threatening to sue you.
Which is, incidentally, not too far from how GNU/Linux came to be - a free OS with the same interface as a nonfree[1] one.
[1] AT&T was legally required to provide the source code of its OS 'for free', I'm not sure if the terms actually qualify as 'free-as-in-freedom', hence the impetus to create an alternative implementation.
[1] AT&T was legally required to provide the source code of its OS 'for free', I'm not sure if the terms actually qualify as 'free-as-in-freedom', hence the impetus to create an alternative implementation.
This posts siblings are correct - the GPL can forbid linking because it is a condition of you being able to use the library. Reimplementation of a GPL library to be distributed under different terms is certainly permitted, and has happened (see readline).
There is still some debate -- and this case didn't touch it -- over linking and derivative works. Static linking pretty clearly involves something that requires a license from the copyright holder, but dynamic linking is far from clear. The GPL basically asserts that dynamic linking makes a derivative work, but there's no guarantee that this is how copyright law would actually be interpreted by a court.
There is more to it than just the technical nature of the linking, though - the court would take into account all of the circumstances of the claimed infringement.
For example, if you distributed your commercial software packaged up with a GPL library, with scripts or links or whatever designed to have that library loaded together with the commercial binary as part of a finished product, then the "dynamic" nature of the linking might well be considered to be a technical irrelevancy.
On the other hand, if you distributed your commercial binary on it's own, and expected your customers to find a compatible library to dynamically link against it, then that might be a different matter.
For example, if you distributed your commercial software packaged up with a GPL library, with scripts or links or whatever designed to have that library loaded together with the commercial binary as part of a finished product, then the "dynamic" nature of the linking might well be considered to be a technical irrelevancy.
On the other hand, if you distributed your commercial binary on it's own, and expected your customers to find a compatible library to dynamically link against it, then that might be a different matter.
The second case is the more common one, and has come up a few times. See, for example, debates over whether code written to a generic readline-esque API must comply with readline's GPL, even though non-GPL alternatives are available.
So if you code against a GPL library, but don't distribute that GPL library with your code, are you still bound by the GPL? According to the GPL license itself, it seems so, as long as there is not other library that implements with the same interface. But what part of copyright law makes this possible?
Do people distribute their non-free code, which then, somehow bootstraps GPL libraries (from GPL sources)? Would that be compatible with the GPL, or is there a provision against that?
Presumably, if proprietary code isn't linked with GPL code, it's not a derived work, but two separate works under different licenses. If your situation can tolerate it, you might could write a gplserver running in a separate address space. Or, if it's hardware to hide, video drivers frequently provide a razor-thin kernel driver that does little more than let you mmap the device's I/O space, with all the action sequestered in a proprietary userspace library.
c.f. rlwrap
You're still linking in the free software. If dynamically linking the normal way would be verboten, I can't see why dynamically linking that way would be any different.
Any project that builds using Maven does that all the time!
(And really it's not simply a question of "non-free" -- there are plenty of open source licenses that are incompatible with the GPL. Is this technically a workaround for the incompatibility between Apache v2 and GPL v2?)
But a non-free villain could bootstrap a build using Maven without even publishing their source at all -- just keep a Maven repository with their binary jars and and a pom.xml that specifies dependencies on a whole bunch of GPL libraries.
Is there a provision against it? I hope so, but I haven't found it yet.
http://wbillingsley.blogspot.com.au/2012/06/does-oracle-v-go...
(And really it's not simply a question of "non-free" -- there are plenty of open source licenses that are incompatible with the GPL. Is this technically a workaround for the incompatibility between Apache v2 and GPL v2?)
But a non-free villain could bootstrap a build using Maven without even publishing their source at all -- just keep a Maven repository with their binary jars and and a pom.xml that specifies dependencies on a whole bunch of GPL libraries.
Is there a provision against it? I hope so, but I haven't found it yet.
http://wbillingsley.blogspot.com.au/2012/06/does-oracle-v-go...
Sanity prevails when you have a judge who can also code...
Who is he referring to here? " For those who have depended on the self-described patent expert for your understanding of this case . . . well, maybe now you will know better than to trust a paid spokesman." FOSS Patents?
Mueller's likely cooking up another article of baked shit right now. He will write about how Oracle actually won this case (even with all the verdicts and judgements going against them), so it was actually bad for Google.
I guarantee he posts an article tomorrow lamenting how Google will only face more lawsuits like this and they won't luck out with an "incompetent" judge and google-loving jury next time. He has been so off the mark with every article he's written on this case he's got to have zero personal pride in his work.
It's a shame people go to him for information. He's a poison in the software community.
I guarantee he posts an article tomorrow lamenting how Google will only face more lawsuits like this and they won't luck out with an "incompetent" judge and google-loving jury next time. He has been so off the mark with every article he's written on this case he's got to have zero personal pride in his work.
It's a shame people go to him for information. He's a poison in the software community.
He makes valid points about abuse of the FRAND patent system.
I would assume so.
Probably.
So, now that the recrimination phase of the trial has begun: where did Oracle go wrong? I mean, at this point they've lost everything and it's abundantly clear that Sun would have been better off just blessing whatever Google wanted to do as "Java". At the very least, they'd have gotten some branding karma and been able to sell an "Official Android Pro SDK" product or whatever.
But at what point was that clear? Who missed that call?
But at what point was that clear? Who missed that call?
Well, I got the distinct impression (though it may be colored by hindsight and the journalists it was filtered through), that Oracle originally thought the patent portion of the case contained the real offenses, with the copyright arguments more limited (and restricted to just code copying, which I recall they were fairly vague with at first, implying many more instances of direct copying than there was).
It was only as the patents were knocked off one by one that the copyright portion of the suit became their major complaint and what they were pinning expectations and their hopes to.
It was only as the patents were knocked off one by one that the copyright portion of the suit became their major complaint and what they were pinning expectations and their hopes to.
No, Oracle was betting more on copyright, because copyright protections are much stronger than patents. Here are some big differences:
(1) copyright lasts longer
(2) copyright infringement is easier to prove
(3) in most cases having the copyright of something is indisputable
On the other hand patents ...
(1) are often discovered to be invalid (many "inventions" are unpatentable)
(2) the monopoly lasts for only 20 years and in this industry most worthwhile things have been invented before the nineties
(3) there are huge amounts of prior art
(4) patent infringement is hard to prove
If anything, this is really great news, because if Oracle could claim the copyright-ability of Java APIs, then our industry would never be the same.
(1) copyright lasts longer
(2) copyright infringement is easier to prove
(3) in most cases having the copyright of something is indisputable
On the other hand patents ...
(1) are often discovered to be invalid (many "inventions" are unpatentable)
(2) the monopoly lasts for only 20 years and in this industry most worthwhile things have been invented before the nineties
(3) there are huge amounts of prior art
(4) patent infringement is hard to prove
If anything, this is really great news, because if Oracle could claim the copyright-ability of Java APIs, then our industry would never be the same.
In a recent case an appeals court in the US noted that something like 60% of patents that were ever challenged in court were eventually invalidated.
It is great news, I agree.
It is great news, I agree.
I think Oracle bought Sun, at least in part, thinking they could do a better job monetizing Java than Sun had done.
That's where they went wrong.
That's where they went wrong.
I have to agree.
Oracle's only possible course in purchasing Sun was litigation. (And I think most expected nothing less from Larry Ellison.)
Google seemed like a vulnerable target.
Alsup was a spanner in Ellison's plan. It could be argued that Google's legal defense was another.
Oracle's only possible course in purchasing Sun was litigation. (And I think most expected nothing less from Larry Ellison.)
Google seemed like a vulnerable target.
Alsup was a spanner in Ellison's plan. It could be argued that Google's legal defense was another.
> Oracle's only possible course in purchasing Sun was litigation.
To be fair to Oracle (OMG I can't believe I just typed that) it's not clear to me that they realized that at the time.
Oracle has a relatively large, locked-in, and well-monetized customer base. They have tools and languages and interefaces too. I imagine that most of the time they don't end up litigating against their customers.
Sun had a good customer base and a lot of them were fairly deeply committed to Sun hardware, Solaris, and yes, Java. Often they were running Oracle on Sun hardware and developing database data entry apps in Java.
It's possible that they were thinking "There's a good synergy here with the market footprint, opportunity for vertical integration, we both have some server tools, developer tools used by committed/locked-in corporate users. Sun isn't getting any revenue from Java because they're just too much "Mr. Nice Guy". We can fix that, we know how to monetize an app platform in the corporate market.
It may also be that I am hopelessly naive and they bought Sun solely as a ticket to sue Google.
Edit: See example "Mr. Nice Guy" blog post at http://groklaw.net/article.php?story=20110723095928839 How would an Ellison interpret that?
To be fair to Oracle (OMG I can't believe I just typed that) it's not clear to me that they realized that at the time.
Oracle has a relatively large, locked-in, and well-monetized customer base. They have tools and languages and interefaces too. I imagine that most of the time they don't end up litigating against their customers.
Sun had a good customer base and a lot of them were fairly deeply committed to Sun hardware, Solaris, and yes, Java. Often they were running Oracle on Sun hardware and developing database data entry apps in Java.
It's possible that they were thinking "There's a good synergy here with the market footprint, opportunity for vertical integration, we both have some server tools, developer tools used by committed/locked-in corporate users. Sun isn't getting any revenue from Java because they're just too much "Mr. Nice Guy". We can fix that, we know how to monetize an app platform in the corporate market.
It may also be that I am hopelessly naive and they bought Sun solely as a ticket to sue Google.
Edit: See example "Mr. Nice Guy" blog post at http://groklaw.net/article.php?story=20110723095928839 How would an Ellison interpret that?
No, I think you're correct.
Oracle on Sun hardware was like peanut butter & jelly for a long time. It would have been very bad for Oracle's business if IBM had purchased Sun and used the hardware as a wedge to sell middleware. So while I'm sure Oracle wanted to monetize Java as much as possible, buying Sun was largely a defensive move.
Oracle on Sun hardware was like peanut butter & jelly for a long time. It would have been very bad for Oracle's business if IBM had purchased Sun and used the hardware as a wedge to sell middleware. So while I'm sure Oracle wanted to monetize Java as much as possible, buying Sun was largely a defensive move.
Actually, I wouldn't have been surprised if IBM (if it had purchased Sun) had dumped Sun's hardware division. It was losing money hand over first, and IBM was doing a pretty good beating Sun with its hardware offerings. Between IBM's x86, Power, and Mainframe hardware product lines, it really wouldn't need sparc. So the only question is how quickly IBM would have been able to transition what was left of Sun's hardware business to IBM's x, p, or z series machines.
As a result, that's probably why Oracle was willing to pay more than IBM. Both IBM and Sun wanted to be able to make sure they could continue to use Java --- and preserving the freedom of action against lawsuits was I'm sure high on both company's minds. But Oracle could also find a good use for its hardware division, where IBM probably would have tried to sell it off.
As a result, that's probably why Oracle was willing to pay more than IBM. Both IBM and Sun wanted to be able to make sure they could continue to use Java --- and preserving the freedom of action against lawsuits was I'm sure high on both company's minds. But Oracle could also find a good use for its hardware division, where IBM probably would have tried to sell it off.
Well, platforms like Solaris/Sparc are never just dumped. No matter who ended up with it would be milking it all the way down, making it that much more expensive & obscure every year, until the users finally say uncle. Generally that's when the customer wants a new CRM or something and gets two birds with one stone.
That's why it would have been disastrous for Oracle if IBM got them. Everytime a Sun customer ordered a new stick of RAM, the IBM software sales team would have been circling around.
(Note: I'm sure there's some niches where Sun hardware is very strong, but those are only going to get narrower over time.)
That's why it would have been disastrous for Oracle if IBM got them. Everytime a Sun customer ordered a new stick of RAM, the IBM software sales team would have been circling around.
(Note: I'm sure there's some niches where Sun hardware is very strong, but those are only going to get narrower over time.)
So then why sue Google for using Java in Android?
The staff lawyers were getting bored and Ellison fell for the old "must defend our intellectual property or lose it" routine?
Just in the hope of picking up a little short term cash by shaking down the deeper pockets in the Java community at the expense of making .Net look to 3rd parties like a legally safer ecosystem?
The staff lawyers were getting bored and Ellison fell for the old "must defend our intellectual property or lose it" routine?
Just in the hope of picking up a little short term cash by shaking down the deeper pockets in the Java community at the expense of making .Net look to 3rd parties like a legally safer ecosystem?
On one level, the Sun people went to great efforts to prevent 'fragmentation' of the Java platform, and I think they felt honestly wronged by what Google did. Sometimes people sue over the principle, not the law.
On another level, it was probably just dumb greed.
But I do agree Oracle aggressively wanted to remind the industry they owned it. And that they don't really care if Java is COBOLized. (COBOL is still big business!)
On another level, it was probably just dumb greed.
But I do agree Oracle aggressively wanted to remind the industry they owned it. And that they don't really care if Java is COBOLized. (COBOL is still big business!)
I think they felt honestly wronged by what Google did
On the contrary, "Jonathan Schwartz, then CEO of Sun Microsystems, praised Google and others for incorporating Java into Android back in 2007" - http://www.groklaw.net/article.php?story=20110723095928839
On the contrary, "Jonathan Schwartz, then CEO of Sun Microsystems, praised Google and others for incorporating Java into Android back in 2007" - http://www.groklaw.net/article.php?story=20110723095928839
Food for thought: SAP had been going down the path of being a dual stack company, using both Java and ABAP. The Java side was being invested in to provide better (i.e. more modern) integration capabilities and Oracle's acquisition of Sun succeeded in getting SAP to take a step back on this strategy.
They didn't step back that far. SAP just announced earlier this month they would help port OpenJDK to PowerPC:
http://mail.openjdk.java.net/pipermail/discuss/2012-May/0026...
http://mail.openjdk.java.net/pipermail/discuss/2012-May/0026...
If that's true then I would expect them to reduce their future investment in developing Java.
Just my opinion:
Sun probably knew that at the time but due to hubris didn't want to admit it, so they just willingly looked the other way and kept doing what they were doing. So you get Jonathan Schwartz, in 2007, wishing that Google would take a license, but begrudgingly congratulating them anyway, but not doing the "Official Android Pro SDK" thing you suggest. (http://web.archive.org/web/20101023072550/http://blogs.sun.c...). So that was a small mistake, a missed opportunity, but life went on.
Then at some point (maybe even before they purchased Sun, maybe after?), Oracle decided to waaay up the stakes with this lawsuit. Given how it's turned out, I'd call that a much bigger mistake.
So it was probably a little clear even to Sun in 2007 that alienating Google was the wrong call but/so they decided not to do anything about it, and then Oracle, well, I don't know whether it's correct to characterize this as missing a call vs intentionally taking a big risk in hopes of a big reward.
Sun probably knew that at the time but due to hubris didn't want to admit it, so they just willingly looked the other way and kept doing what they were doing. So you get Jonathan Schwartz, in 2007, wishing that Google would take a license, but begrudgingly congratulating them anyway, but not doing the "Official Android Pro SDK" thing you suggest. (http://web.archive.org/web/20101023072550/http://blogs.sun.c...). So that was a small mistake, a missed opportunity, but life went on.
Then at some point (maybe even before they purchased Sun, maybe after?), Oracle decided to waaay up the stakes with this lawsuit. Given how it's turned out, I'd call that a much bigger mistake.
So it was probably a little clear even to Sun in 2007 that alienating Google was the wrong call but/so they decided not to do anything about it, and then Oracle, well, I don't know whether it's correct to characterize this as missing a call vs intentionally taking a big risk in hopes of a big reward.
This is really a huge win for Google not just against Oracle but for Larry Page and Schmidt who made the ballsy call here and in general to remake many standards instead of licensing.
A judge making a rational and fair decision? Seems to be happening a lot lately, maybe the world is ending. Needless to say as a programmer this makes me incredibly happy, if the judge ruled API's are copyrightable, then there would have been a lot of sore bums as a result. I have a feeling if the judge didn't know how to code, the result could have been marginally different.
We as a community live and breath computers all day. When SOPA is put in front of us, we immediately know it is wrong. When you talk about the idea of copyrighting an API, we pretty much instantly were against it. And most of us are against the indiscriminate sueing of file sharers (not to open that can of worms here, but just as a point).
Whethers its judges, politicians, companies, or public opinion overall, it can take years for the viewpoint of the 'experts' to become mainstream. We look at this stuff 24/7, most other people are thinking about it with 1% of their time.
I don't think its just us either, if you dive into a community of people focused on medicine or energy, they are 5 years ahead of you and I as well. It just takes a long time to percolate outwards from the experts to the laymen.
Whethers its judges, politicians, companies, or public opinion overall, it can take years for the viewpoint of the 'experts' to become mainstream. We look at this stuff 24/7, most other people are thinking about it with 1% of their time.
I don't think its just us either, if you dive into a community of people focused on medicine or energy, they are 5 years ahead of you and I as well. It just takes a long time to percolate outwards from the experts to the laymen.
" And most of us are against the indiscriminate sueing of file sharers"
I was with you up to that point. I think you would find that the majority of HN doesn't have a lot of sympathy for those who would distribute other people's creative works in violation of said creator's copyrights.
After all, the same thing that protects authors rights in the GPL underly the rights belonging to the creators of "Game of Thrones".
Let's not stretch something that 95%+ of us agree on (You should't be able to copyright an API) into a place where there isn't consensus.
I was with you up to that point. I think you would find that the majority of HN doesn't have a lot of sympathy for those who would distribute other people's creative works in violation of said creator's copyrights.
After all, the same thing that protects authors rights in the GPL underly the rights belonging to the creators of "Game of Thrones".
Let's not stretch something that 95%+ of us agree on (You should't be able to copyright an API) into a place where there isn't consensus.
Well. There's a difference between "lack of sympathy for those who would violate copyrights" and "indiscriminate sueing of file sharers".
(Especially how it's turned out -- the few cases that went to court and proceeded to a verdict have absurdly huge penalties; the suits were structured so that often an accusee's best strategy is immediate settlement even if innocent.)
Many of us do rely on IP law to get paid, and there do need to be ways to reward and encourage creative work, but there also needs to be a balance.
(Especially how it's turned out -- the few cases that went to court and proceeded to a verdict have absurdly huge penalties; the suits were structured so that often an accusee's best strategy is immediate settlement even if innocent.)
Many of us do rely on IP law to get paid, and there do need to be ways to reward and encourage creative work, but there also needs to be a balance.
I favor the GPL over BSD n-clause (and over putting code into the Public Domain). However, I would still prefer a world without any copyright enforcement. It would mean the GPL was unenforceable, but a company using GPL code in a piece of commercial software would have no protection against undesired redistribution of that software, so it evens out a little bit: even though the source code for the derivative work would not be freely available, the functionality of the derivative work would be.
However, instead of doing away with copyright entirely, I would prefer to see copyright only enforceable when the redistribution is directly for-profit: that is, but for a payment, the copied or derived work would not be available. (Worded that way to prevent "commercial redistribution" from including software published on blogs with ads and similar venues.)
GPL would still mostly apply in that ideal fantasy world, because who wants to violate the GPL except to distribute something for profit? All the notable GPL violations I can think of have been the result of commercial interests (preventing competitors from copying something you're trying to sell).
However, instead of doing away with copyright entirely, I would prefer to see copyright only enforceable when the redistribution is directly for-profit: that is, but for a payment, the copied or derived work would not be available. (Worded that way to prevent "commercial redistribution" from including software published on blogs with ads and similar venues.)
GPL would still mostly apply in that ideal fantasy world, because who wants to violate the GPL except to distribute something for profit? All the notable GPL violations I can think of have been the result of commercial interests (preventing competitors from copying something you're trying to sell).
The GPL, from a practical standpoint, is the opposite of normal copyright. Particularly, while the GPL does happen to use copyright law, its effect is the opposite--instead of taking away consumers' rights, it adds to consumers' rights.
The GPL is really a stop-gap measure. It cleverly turns copyright law against itself, and manages to use an existing legal framework to achieve a completely different end. However, it would be even better if it did not have to exist and all code was always open source. The whole free software movement is about not having software protected by copyright or even implicitly protected by being closed-source: it's the software that has to be free, in the sense of freedom.
In short, while the GPL does use copyright, it's just an implementation detail. The actual effects are the opposite--it uses copyright law to neuter copyrights so that the users' freedom is always preserved.
The GPL is really a stop-gap measure. It cleverly turns copyright law against itself, and manages to use an existing legal framework to achieve a completely different end. However, it would be even better if it did not have to exist and all code was always open source. The whole free software movement is about not having software protected by copyright or even implicitly protected by being closed-source: it's the software that has to be free, in the sense of freedom.
In short, while the GPL does use copyright, it's just an implementation detail. The actual effects are the opposite--it uses copyright law to neuter copyrights so that the users' freedom is always preserved.
I actually agree with you and don't think you deserve down votes. Having written open source code (and code in general), I'm far more on the side of 'people who enforce copyright' than on those that choose to download copyrighted works.
Plus, in a selfish way, I'd love if Microsoft, Dassault, et al started enforcing their copyright on software harder. That would push more people towards open source and alternate solutions. Piracy really undermines one of the major 'selling' points of free software.
That said, the way the copyright industry has gone about their war on copyright infringers is very wrong. Using the courts to basically extort those that can't afford to defend themselves? Trying to pass legislation like a bull in a china shop - completely ignoring the distructive side effects their pet issue might cause. I don't think anyone on HN believes the way they have been trying to win the battle makes any sense.
Plus, in a selfish way, I'd love if Microsoft, Dassault, et al started enforcing their copyright on software harder. That would push more people towards open source and alternate solutions. Piracy really undermines one of the major 'selling' points of free software.
That said, the way the copyright industry has gone about their war on copyright infringers is very wrong. Using the courts to basically extort those that can't afford to defend themselves? Trying to pass legislation like a bull in a china shop - completely ignoring the distructive side effects their pet issue might cause. I don't think anyone on HN believes the way they have been trying to win the battle makes any sense.
I don't know about a majority.
This poll, while hardly conclusive, suggests at least a sympathy for the "IP is imaginary!" crowd.
http://news.ycombinator.com/item?id=2555088
This poll, while hardly conclusive, suggests at least a sympathy for the "IP is imaginary!" crowd.
http://news.ycombinator.com/item?id=2555088
No, it really doesn't.
There are 3/28 votes for abolishing copyright, 1/28 for the current system as-is and the bulk, 24/28, for retaining copyright with some reforms.
Supporting copyright reform is solidly opposed to the "IP is imaginary!" crowd. Supporting reform means valuing the concept of copyright and wanting to see it work better. The "IP is imaginary!" crowd would much rather see the current system collapse under its own weight as a path towards getting copyright abolished.
There are 3/28 votes for abolishing copyright, 1/28 for the current system as-is and the bulk, 24/28, for retaining copyright with some reforms.
Supporting copyright reform is solidly opposed to the "IP is imaginary!" crowd. Supporting reform means valuing the concept of copyright and wanting to see it work better. The "IP is imaginary!" crowd would much rather see the current system collapse under its own weight as a path towards getting copyright abolished.
"I have a feeling if the judge didn't know how to code, the result could have been marginally different."
When people tell me about how the sky is falling because of software patents I remind them that in 1995 when the patent frenzy kicked off exactly zero federal judges had the kind of exposure to computers that would be required to ajudicate these issues. This became pretty obvious during the Microsoft Anti-trust trial as technical witnesses struggled to explain the ramifications of what 'bundling' did. And the problem extends throughout the system since these things get appealed etc.
So 15 years later, we start getting Federal judges who know a bit about computers (and Alsup knows more than many) and that leads to rulings that are a lot more reasonable.
Part of the 'pain' we feel is that the world change rate is faster than the institution adaption rate, however institutions that are designed to adapt do, and we are starting to see the benefit of that. In another 15 years these judges from today will be filling appellate and circuit court seats, even supreme court seats. And then it will be very difficult indeed to claim that using a laser pointer to amuse a cat is novel or patentable.
When people tell me about how the sky is falling because of software patents I remind them that in 1995 when the patent frenzy kicked off exactly zero federal judges had the kind of exposure to computers that would be required to ajudicate these issues. This became pretty obvious during the Microsoft Anti-trust trial as technical witnesses struggled to explain the ramifications of what 'bundling' did. And the problem extends throughout the system since these things get appealed etc.
So 15 years later, we start getting Federal judges who know a bit about computers (and Alsup knows more than many) and that leads to rulings that are a lot more reasonable.
Part of the 'pain' we feel is that the world change rate is faster than the institution adaption rate, however institutions that are designed to adapt do, and we are starting to see the benefit of that. In another 15 years these judges from today will be filling appellate and circuit court seats, even supreme court seats. And then it will be very difficult indeed to claim that using a laser pointer to amuse a cat is novel or patentable.
This is definitively a relief for our whole industry.
Thanks to Judge Alsup for taking an impartial stand on the whole matter and for the commitment to enable himself to an understanding of the matter and an informed decision going as far as to even learn himself how to program in Java.
I hope this does not remain one of the few cases when knowledge, ethics and the law is applied in its true sense while billions are brought to the battlefield.
Maybe all those that think that "rounded corners", sending email messages/calendar entries from mobile devices or different shades of gray are true inventions will one day soon rethink their monopoly strategies and start again with what they were once great at - actually create and invent things that people want to use.
Thanks to Judge Alsup for taking an impartial stand on the whole matter and for the commitment to enable himself to an understanding of the matter and an informed decision going as far as to even learn himself how to program in Java.
I hope this does not remain one of the few cases when knowledge, ethics and the law is applied in its true sense while billions are brought to the battlefield.
Maybe all those that think that "rounded corners", sending email messages/calendar entries from mobile devices or different shades of gray are true inventions will one day soon rethink their monopoly strategies and start again with what they were once great at - actually create and invent things that people want to use.
We've seen invention companies turn into patent trolls. The latest example - a shell company built around the Nortel patents - is a classic case. A telecom company, where it should be easy to sell inventions to upper management, went bankrupt by refusing to innovate. (I know there are other reasons Nortel is dead, I apologize for the simplification.)
I don't believe anyone has ever seen a patent troll "turn from the dark side." It's not just cynicism: a company whose business plan is "aggressively pursue patent licenses" has a fiduciary responsibility to stakeholders to stay the course. It's easier to drive a company into Chapter 11 bankruptcy than convince a majority of stakeholders to unite, pivot, and abandon their cash cow.
The easiest way to defeat patent trolls is to succeed as a startup.
I don't believe anyone has ever seen a patent troll "turn from the dark side." It's not just cynicism: a company whose business plan is "aggressively pursue patent licenses" has a fiduciary responsibility to stakeholders to stay the course. It's easier to drive a company into Chapter 11 bankruptcy than convince a majority of stakeholders to unite, pivot, and abandon their cash cow.
The easiest way to defeat patent trolls is to succeed as a startup.
While I agree with the gist of what you're saying, the "rounded corners" claim was that the specific corner shape was an ornamental as opposed to useful part of the iPad's design. Design patents and utility patents aren't even close to the same thing.
The key element of both (all) types of patents is that, rather than "protecting" your property, they actually allow you to prevent others from independently inventing or designing the same thing by giving you a legal monopoly. In that regard using the law to prevent someone having rounded corners on a handheld device isn't too different from preventing them having a touchscreen device that you unlock by swiping.
Sure. I'd even go on to say that the latter isn't much different, in principle, than granting Eli Lilly a monopoly on pills that, by a certain chemical action, boost serotonin levels in the brain.
Which is not to say that there might not be sensible reasons for society to favor protection of one over the other. In the words[1] of Oliver Wendell Holmes, "the life of the law has not been logic: it has been experience."
Fortunately for the industry, today's ruling was clearly written by a judge well-versed in both.
[1] http://books.google.com/books?id=xXouAAAAIAAJ&pg=PA1 (well worth reading in context)
Which is not to say that there might not be sensible reasons for society to favor protection of one over the other. In the words[1] of Oliver Wendell Holmes, "the life of the law has not been logic: it has been experience."
Fortunately for the industry, today's ruling was clearly written by a judge well-versed in both.
[1] http://books.google.com/books?id=xXouAAAAIAAJ&pg=PA1 (well worth reading in context)
And you are of course right, but - I believe - what is important here is that for keeping our legal systems functional it is necessary to actively limit the opportunities to abuse it
True. And the main reason for keeping our legal system functional? The belief that alternatives would invite even more abuse!
"For example, Java-based code using the replicated parts of the 37 API packages will run on Android but will not if a 38th package is needed. Such imperfect interoperability leads to a “fragmentation” — a Balkanization — of platforms, a circumstance which Sun and Oracle have tried to curb via their licensing programs. In this litigation, Oracle has made much of this problem, at times almost leaving the impression that if only Google had replicated all 166 Java API packages, Oracle would not have sued."
LOL
LOL
Why is that an LOL?
That is exactly why Sun sued Microsoft and won. Microsofts JVM was slightly incompatible with the official one. If Microsoft had replicated all Java API packages, and not added Windows-specific ones then they wouldn't have sued.
One of the big sells of Java has always been "write once, run anywhere", Sun sued Microsoft because their incompatible JVM made that not true anymore. Now it's effectively true of Android; no program written in Java not specifically for Android can possibly be expected to work. Not that I think that is a particularly bad thing, since J2ME is a big pile of crap, but it's kind of interesting to see the difference between the perception in favor of Sun then and against Oracle here when the core issue is the same.
That is exactly why Sun sued Microsoft and won. Microsofts JVM was slightly incompatible with the official one. If Microsoft had replicated all Java API packages, and not added Windows-specific ones then they wouldn't have sued.
One of the big sells of Java has always been "write once, run anywhere", Sun sued Microsoft because their incompatible JVM made that not true anymore. Now it's effectively true of Android; no program written in Java not specifically for Android can possibly be expected to work. Not that I think that is a particularly bad thing, since J2ME is a big pile of crap, but it's kind of interesting to see the difference between the perception in favor of Sun then and against Oracle here when the core issue is the same.
Microsoft entered into an contract with Sun specifically agreeing that any Java implementation they shipped would be fully compatible with Sun's version.
Now it's effectively true of Android; no program written in Java not specifically for Android can possibly be expected to work.
The large majority of existing Java code and libraries will work on Android without modification.
Now it's effectively true of Android; no program written in Java not specifically for Android can possibly be expected to work.
The large majority of existing Java code and libraries will work on Android without modification.
The relevant point being that Google didn't want to license Java under the standard terms because they wanted control over the platform, and certainly partially because they saw what happened to Microsoft.
It certainly wasn't just the technical matter of reproducing "166 APIs", there was the whole political angle of putting Android under control of Sun/Oracle's committees.
(And just on a trivial note, Microsoft eventually created their own 'clean-room' Java called "J#". It died in obscurity, but Google wasn't the first.)
It certainly wasn't just the technical matter of reproducing "166 APIs", there was the whole political angle of putting Android under control of Sun/Oracle's committees.
(And just on a trivial note, Microsoft eventually created their own 'clean-room' Java called "J#". It died in obscurity, but Google wasn't the first.)
Great! Now just a few years of appeals and it will all be over...
Don't celebrate too much yet. This is likely to be appealed.
I think the judge did a good job in trying to make sure this decision stands on appeal but until the appeal process is over, this could still turn ugly.
I think the judge did a good job in trying to make sure this decision stands on appeal but until the appeal process is over, this could still turn ugly.
IANAL, but I'm not sure that this is too likely, because of the way that Alsup separated the jury's decision from his own.
Prosecution can't appeal a jury's acquittal; in this case, Alsup's ruling is separated from the jury's decision (remember when he told them to 'assume APIs are copyrightable'), so I'm not sure what the possible courses of legal action are here. This is a subtle point, so I imagine one would have to be a lawyer to answer this one, though I have a suspicion that there may not be a precedent here (or, if there is, it's a weak enough precedent that it could still reasonably go either way).
Prosecution can't appeal a jury's acquittal; in this case, Alsup's ruling is separated from the jury's decision (remember when he told them to 'assume APIs are copyrightable'), so I'm not sure what the possible courses of legal action are here. This is a subtle point, so I imagine one would have to be a lawyer to answer this one, though I have a suspicion that there may not be a precedent here (or, if there is, it's a weak enough precedent that it could still reasonably go either way).
I can't speak very much or about this particular case (because i'm involved), but i can tell you you are confusing civil and criminal law. You are correct that in a criminal case, the government cannot generally appeal a jury acquittal .
In a civil case, you can appeal a jury verdict (in practice, I'm being deliberately loose with terminology to make this understandable), the usual method is to file a post-judgement motion for judgement as a matter of law, and then appeal its denial, or appeal the jury instructions, or ...
I know civil and criminal are different; however, I thought that was the whole point of the special jury instructions (making it impossible/more difficult for his ruling to be overturned on appeal).
In any case, I guess we'll see soon....
In any case, I guess we'll see soon....
Sadly, I can't comment on the jury instructions except to encourage you to look around at other patent and copyright cases and see if you think they are really all that special or different.
I can say it is statistically more difficult to overturn jury verdicts than it is to overturn judge verdicts. On the patent side, you can find interesting but slightly out of date data here:
http://www.patentlyo.com/patent/2010/04/are-appeals-at-the-f...
You should be able to figure out which issues are eliminated by having mainly a jury decision on patents instead of a judge decision.
I can say it is statistically more difficult to overturn jury verdicts than it is to overturn judge verdicts. On the patent side, you can find interesting but slightly out of date data here:
http://www.patentlyo.com/patent/2010/04/are-appeals-at-the-f...
You should be able to figure out which issues are eliminated by having mainly a jury decision on patents instead of a judge decision.
I imagine this has implications for the Cappuccino framework, which uses the Cocoa API with some minor changes (replacing NS with CP).
Kudos to the judge for making the effort to really understand the issues. I'm curious, did WINE ever come up as an example of an alternative API implementation?
I'd actually find that a more interesting case, as it's an alternative implementation of APIs where the creator never even envisioned there being an alternative implementation.
Java, despite what Oracle may say, was always spec'd to a point where alternative implementations were probable, and many JVM improvements started off as proprietary forks/implementations.
I'd actually find that a more interesting case, as it's an alternative implementation of APIs where the creator never even envisioned there being an alternative implementation.
Java, despite what Oracle may say, was always spec'd to a point where alternative implementations were probable, and many JVM improvements started off as proprietary forks/implementations.
So far as I could tell, WINE was never part of the trial record (i.e. no testimony, exhibits, etc.) so it wouldn't (shouldn't) be referred to in the legal arguments in the trial.
That being said, it would be good to see the WINE project submit an amicus brief (possibly with the help of, for example, the EFF) during the appeals process.
That being said, it would be good to see the WINE project submit an amicus brief (possibly with the help of, for example, the EFF) during the appeals process.
Reading the ruling is fantastic.
The judge basically puts a CS 101 chapter in to explain some of the basics of Java. I laughed when he used the variable name 'Foo' as an example.
This was one argument that I haven't seen before:
"This brings us to the application programming interface. When Java was first introduced in 1996, the API included eight packages of pre-written programs. At least three of these packages were “core” packages, according to Sun, fundamental to being able to use the Java language at all. These packages were java.lang, java.io, and java.util. As a practical matter, anyone free to use the language itself (as Oracle concedes all are), must also use the three core packages in order to make any worthwhile use of the language. Contrary to Oracle, there is no bright line between the language and the API."
The judge basically puts a CS 101 chapter in to explain some of the basics of Java. I laughed when he used the variable name 'Foo' as an example.
This was one argument that I haven't seen before:
"This brings us to the application programming interface. When Java was first introduced in 1996, the API included eight packages of pre-written programs. At least three of these packages were “core” packages, according to Sun, fundamental to being able to use the Java language at all. These packages were java.lang, java.io, and java.util. As a practical matter, anyone free to use the language itself (as Oracle concedes all are), must also use the three core packages in order to make any worthwhile use of the language. Contrary to Oracle, there is no bright line between the language and the API."
there is no bright line between the language and the API
This is actually a deep observation about the relationship between languages and libraries: the line between them is fluid and to some extent just a convention.
How astonishing that the judge of a lawsuit would show this level of technical understanding. Let's hope he has succeeded in appeal-proofing the ruling.
This is actually a deep observation about the relationship between languages and libraries: the line between them is fluid and to some extent just a convention.
How astonishing that the judge of a lawsuit would show this level of technical understanding. Let's hope he has succeeded in appeal-proofing the ruling.
Think about this for a second. What I heard the judge saying is basically this (and something judges have repeatedly said): Copyright is not a barrier to competition with functionally equivalent products, nor is it a barrier to interoperability of functional software. WINE is not a derivative work of Windows, for example....
Instead copyright (at least in the US) only protects creative expression to the extent it can be separated from function. This means it protects source code in kind of funny ways and with strange boundaries which haven't been as fleshed out as much as one might think. This is important.
It places a lot of the more extremist rhetoric about what the GPL prohibits in doubt too, since by this logic steps that are minimally necessary to interop with a piece of software can never, by themselves, rise to the level of copyright infringement.
Instead copyright (at least in the US) only protects creative expression to the extent it can be separated from function. This means it protects source code in kind of funny ways and with strange boundaries which haven't been as fleshed out as much as one might think. This is important.
It places a lot of the more extremist rhetoric about what the GPL prohibits in doubt too, since by this logic steps that are minimally necessary to interop with a piece of software can never, by themselves, rise to the level of copyright infringement.
We could even call it "introspection".
> How astonishing that the judge of a lawsuit would show this level of technical understanding.
It's been reported that he's done programming before. I had very high hopes based on that and the extensive research he did in preparing for this ruling. He asked for several rounds of briefings and spent a considerable amount of time reaching this decision.
So in a sense it's not that astonishing: he worked really hard to arrive at the correct answer. I'm just glad they got such a capable judge.
It's been reported that he's done programming before. I had very high hopes based on that and the extensive research he did in preparing for this ruling. He asked for several rounds of briefings and spent a considerable amount of time reaching this decision.
So in a sense it's not that astonishing: he worked really hard to arrive at the correct answer. I'm just glad they got such a capable judge.
It's been reported that he's done programming before.
Of course; that's the astonishing part. This was more than a capable judge - this was a capable judge with deep intuition for the domain. You don't get that by cramming from scratch.
For once, we software people got a lucky break in the courts. If only this guy could be set on a patent troll case.
Of course; that's the astonishing part. This was more than a capable judge - this was a capable judge with deep intuition for the domain. You don't get that by cramming from scratch.
For once, we software people got a lucky break in the courts. If only this guy could be set on a patent troll case.
I really liked that he added the last bit. It explicitly denied the theory that the language elements that were 'code' in the core packages were part of the same work (language) that is parsed by the lexical analyzer. This is a critically important element of language design.
Oracle should really save themselves the embarrassment and admit the law is not on their side, and they are being just way too greedy trying to get Google to pay for this. But they'll probably take it further anyway...
i suspect they've already sunk in enough effort - i m sure they aint' just gonna give up.
I just hope that when they do appeal, that they don't somehow manage to get a judge that is incapable of understanding the technical subtlties involved, and ruin everything.
Does this set a precedent for all kinds of APIs or just the Java API?
Can I go and implement any commercial API and sell my own implementation without having to pay any fee to the original author of the API?
That would be awesome.
Can I go and implement any commercial API and sell my own implementation without having to pay any fee to the original author of the API?
That would be awesome.
If you can be sure that the implementation wouldn't be encumbered by a patent, then yes. But, you can't be sure that you still wouldn't get sued. Although, if the API isn't publicly available, I'm not sure it is so clear.
You've always needed to be able to implement APIs in order to have compatibility, so in essence, this decision puts into case-law what what already assumed to be the case.
You've always needed to be able to implement APIs in order to have compatibility, so in essence, this decision puts into case-law what what already assumed to be the case.
OK, let me clarify.
Let's say a software vendor out there is making a ton of money with a product that exposes a certain API.
Let's say I know a way to implement that API in such a manner that its performance will be improved by an order of magnitude. (without using any patented method in my implementation)
Can I put together that implementation and market it as a competitive product?
In my experience, APIs of commercial products are disclosed under the terms of their licensing agreement. So, one could argue that I cannot market a competitive implementation, if the license terms I agreed to (to gain knowledge of the API itself) prevent me to do so.
Let's say a software vendor out there is making a ton of money with a product that exposes a certain API.
Let's say I know a way to implement that API in such a manner that its performance will be improved by an order of magnitude. (without using any patented method in my implementation)
Can I put together that implementation and market it as a competitive product?
In my experience, APIs of commercial products are disclosed under the terms of their licensing agreement. So, one could argue that I cannot market a competitive implementation, if the license terms I agreed to (to gain knowledge of the API itself) prevent me to do so.
If you agreed to a license or NDA prohibiting you from competing, that might be enforceable under contract law, but that is neither related to copyright nor patents.
Assuming a case where there's no contract involved, patents are typically what would cause trouble. The original implementor will typically have a patent on some silly thing their software does, and you have to do that thing to make a compatible implementation, so they sue you for violating their patents.
Assuming a case where there's no contract involved, patents are typically what would cause trouble. The original implementor will typically have a patent on some silly thing their software does, and you have to do that thing to make a compatible implementation, so they sue you for violating their patents.
A lot of things out there are very dumbly implemented and you can implement them better easily. Patent-heavy code is fairly rare (maybe 10% of all enterprise applications) in my experience.
To go back to my question, there are a lot of entrenched players out there who rely on an age-old user base to keep afloat. If you can provide a better implementation without asking them to rebuild their client applications, their customers will have an easy road to migrate towards your implementation.
To go back to my question, there are a lot of entrenched players out there who rely on an age-old user base to keep afloat. If you can provide a better implementation without asking them to rebuild their client applications, their customers will have an easy road to migrate towards your implementation.
I think if it were a publically available API you'd have a pretty fair shot at it. Start with the Google Maps or Google Charts one, it would be hard for them to turn around and sue you after having just won a case to the contrary.
It's a trial decision, so it doesn't set a binding precedent at all. You might want to wait for the appeal before starting your scheme.
Favorite part: "Oracle has made much of nine lines of code that crept into both Android and Java. This circumstance is so innocuous and overblown by Oracle that the actual facts, as found herein by the judge, will be set forth below for the benefit of the court of appeals."
So here's the question: Can you protect a computer language with copyright, e.g. a high level language like a scripting language?
IANAL. Read the ruling. To me it seems to reaffirm the principle that no functional aspect of a system are under copyright. Sun/Oracle's consternation about it's lack of control over Java due to "fragmentation" was even interpreted to support the idea that the aspects of Java that Google copied to develop a compatible system were, in fact, functional.
"Short labels" are out too.
So AFAICT you can't copyright "if ... then", and you can't copyright "if" or "then" either.
Also see the recent case of SAS (a computer language product) in the EU. https://en.wikipedia.org/wiki/SAS_Institute_lawsuit_with_Wor...
"Short labels" are out too.
So AFAICT you can't copyright "if ... then", and you can't copyright "if" or "then" either.
Also see the recent case of SAS (a computer language product) in the EU. https://en.wikipedia.org/wiki/SAS_Institute_lawsuit_with_Wor...
I'm fairly sure that languages cannot ever be copyrighted, programming or otherwise.
Can the interpreter be protected by copyright? Technically that is a program, not the language.
Of course. But that doesn't stop anyone from writing their own interpreter that interprets the same language, as long as they don't copy any copyrightable parts of your interpreter to do so.
(Such an interpreter would likely contain a table of function names. The effect of this ruling is to clarify that that set of function names can't be copyrighted, so the alternative implementation of your interpreter can copy it. We already knew that the names themselves couldn't be copyrighted, but this ruling clarifies that also the "structure, sequence and organsiation" of those function names can't be copyrighted either.)
(Such an interpreter would likely contain a table of function names. The effect of this ruling is to clarify that that set of function names can't be copyrighted, so the alternative implementation of your interpreter can copy it. We already knew that the names themselves couldn't be copyrighted, but this ruling clarifies that also the "structure, sequence and organsiation" of those function names can't be copyrighted either.)
This still seems like pretty good protection for someone who has written an interpreter that performs "the best" vis-a-vis any clones. From the end user/customer's perspective, who cares how the function's interface/arguments are structured? What matters is how well the functions are written and thus how well the interpreter, and the programs it runs, perform. Of course, programmers might care about how well interfaces are designed, but unfortunately we can't sue people for crappy interfaces.
Well, from the end-user's perspective they care very much that the clone can provide the same functions organised in the same way as the original, because otherwise their scripts that run on the original interpreter won't run on the clone.
But yes, the underlying implementation is still subject to copyright (and potentially, patent). You can't copyright the fact that your scripting language has an operator spelled >< that concatenates strings, but you can copyright your particular code that performs string concatenation.
But yes, the underlying implementation is still subject to copyright (and potentially, patent). You can't copyright the fact that your scripting language has an operator spelled >< that concatenates strings, but you can copyright your particular code that performs string concatenation.
Yes, same functionality. I only meant the implementation, the code. Let's take an example: The APL and APL-related languages. IBM and some other old companies have been licensing these "languages" for many years. But what are people really licensing? Not the language. If we agree that languages are not protectatble, then no one needs permission to use a language. (What the licensee is really paying for is the use of an interpreter and perhaps support/consulting.) But how many programmers understand this distinction?
I think the implications of this case are huge.
Apart from having the non-copyrightability of APIs reaffirmed (hugely important in itself), we're now seeing the whole general broadside of the intellectual property armageddon largely fizzing out. We have huge tech giants throwing whole rafts of patents at each other and seeing time and time again 95% of them dismissed and the remainder get trivially worked around.
Hopefully this starts to change the mentality into one where these companies realize that patents are fairly worthless protection for trivial ideas in the first place and the only way to truly protect yourself is to actually out-innovate and be one step ahead of where the competition is.
Apart from having the non-copyrightability of APIs reaffirmed (hugely important in itself), we're now seeing the whole general broadside of the intellectual property armageddon largely fizzing out. We have huge tech giants throwing whole rafts of patents at each other and seeing time and time again 95% of them dismissed and the remainder get trivially worked around.
Hopefully this starts to change the mentality into one where these companies realize that patents are fairly worthless protection for trivial ideas in the first place and the only way to truly protect yourself is to actually out-innovate and be one step ahead of where the competition is.
The problem is that threatening to throw those patents at small companies has proven, and will probably continue, to be effective. It doesn't matter whether or not they effectively protect ideas when their true value lies in raising barriers to competition.
True, but I think the effect will even trickle down to smaller cases. That is the benefit of having a clear precedent set. For example when Big Co. now tries to sue Small Co. for implementing their API Small Co. will be able to stand up with much more confidence and tell them to go away. Even if that could have been interpreted from previous legal doctrine, having such a clear and and recent statement on it will bolster anybody in that situation to defend themselves instead of caving.
It's not a lack of courage that keeps small companies from defending themselves, it's a lack of money.
Well, I would argue a clear precedent dramatically lowers the cost of defending yourself as well. Instead of a team of lawyers to finesse obscure complicated points and amassing huge quantities of research and evidence it just comes down to a simple well established point of law: the stuff is not copyrightable (I'd agree doesn't help so much with patents, which aren't affected by precedent in this case).
What a great judge. If only the politicians passing tech laws would put in this kind of effort.
a judge goes thru some very different education and indoctrinations than a politician would have.
A judge is more difficult to corrupt, and/or bribe with circumstances, because there is no incentive for the judge to favour one or the other. Thus, this is fair.
A politician has plenty of incentive to favour one party over another when creating legislation - after all, who pays for their campaign contributions? He/she/it who pays controls.
A judge is more difficult to corrupt, and/or bribe with circumstances, because there is no incentive for the judge to favour one or the other. Thus, this is fair.
A politician has plenty of incentive to favour one party over another when creating legislation - after all, who pays for their campaign contributions? He/she/it who pays controls.
As it happens, most trial court judges in the US are elected. See here: http://www.brennancenter.org/content/section/category/state_...
Judge Alsup is a federal judge, so he's an appointee, not an elected official. But most judges do need campaign donors. It's a problem.
Judge Alsup is a federal judge, so he's an appointee, not an elected official. But most judges do need campaign donors. It's a problem.
With this ruling, Judge William "Haskell" Alsup has become a personal hero of mine - a real caped crusader!
Way to go, judge! The wider developer community salutes you.
Way to go, judge! The wider developer community salutes you.
A few thoughts:
1. This is a meticulously researched, marvelously analyzed, and brilliantly synthesized order done by a judge who has a keen grasp of not just the facts of the case but of those that really matter. As the opinion notes, this was a case of "first impression" - meaning that no published decision has ever dealt specifically with the precise question raised of whether APIs in themselves are protectable by copyright or not.
2. The developer community needed a definitive ruling that was almost impossible to arrive at in light of the controlling precedents of the Ninth Circuit (which are binding on the judge). Why? Because (beginning with the Johnson Controls case in 1989) the precedents had held that the "structure, sequence, and organization" (SSO) of any part of a software program were potentially protectable by copyright and that the issues had to be determined case-by-case to determine whether a particular component was or was not protectable. Thus, the best a trial judge can do in such a case is to make a fact-specific conclusion about the case immediately being tried, one which would have limited impact in the next case, where the parties could argue the same issue on different facts. Yet, while doing just that and limiting his ruling to the particular facts before him, Judge Alsup has provided a definitive and logically compelling approach to how such issues are to be decided where they concern APIs and copyright and such reasoning is, in my view, destined to be widely applied throughout the court system going forward. Lower court rulings can have a powerful impact through the sheer force of their reasoning. This is just such a ruling. It is rare to get this. It could not have been better timed on a vital issue affecting interoperability in our modern era.
3. Fundamentally, Oracle had been arguing that the SSO of its 37 API packages reflected creative expression of precisely the type that the Copyright Act was intended to protect. And it is true that API design choices reflect all sorts of creative forms of expression. To deal with this issue, the judge got down to fundamentals, with the key language found at page 35 of the opinion: "Much of Oracle’s evidence at trial went to show that the design of methods in an API was a creative endeavor. Of course, that is true. Inventing a new method to deliver a new output can be creative, even inventive, including the choices of inputs needed and outputs returned. The same is true for classes. But such inventions — at the concept and functionality level — are protectable only under the Patent Act. The Patent and Trademark Office examines such inventions for validity and if the patent is allowed, it lasts for twenty years. Based on a single implementation, Oracle would bypass this entire patent scheme and claim ownership over any and all ways to carry out methods for 95 years — without any vetting by the Copyright Office of the type required for patents. This order holds that, under the Copyright Act, no matter how creative or imaginative a Java method specification may be, the entire world is entitled to use the same method specification (inputs, outputs, parameters) so long as the line-by-line implementations are different" (my emphasis). Thus, even though the judge was forced by Ninth Circuit precedents to assess the SSO based on the particular facts before him only, he did so by finding, as a matter of fact, that only a 3% layer of code dealt with the SSO of the API packages, that this consisted entirely of names that had to be identical for compatibility purposes and of tasks that could be performed in only one way in order to work, and in this way - having established the factual setting as consisting entirely of elements he concluded were unprotectable under copyright - he could make a powerful and sweeping statement of law that will undoubtedly have a huge impact on future cases.
4. The judge finally had to deal with the claim that the SSO constituted a sort of taxonomy that has been held protectable under copyright in other circuit courts. Here, too, he addressed the issue based on fundamentals: assuming that the API design structure here constituted a taxonomy, he nonetheless held that it was above all a command structure that was unprotectable based on 17 U.S.C. section 102(b) (which categorically excludes ideas, concepts, etc. from copyright protection). Thus (at page 39): "In our circuit, the structure, sequence and organization of a computer program may (or may not) qualify as a protectable element depending on the 'particular facts of each case' and always subject to exclusion of unprotectable elements. Johnson Controls v. Phoenix Control Sys., 886 F.2d 1173, 1175 (9th Cir. 1989). Contrary to Oracle, Johnson Controls did not hold that all structure, sequence and organization in all computer programs are within the protection of a copyright." This is another way of saying that what might otherwise constitute protecable expression (e.g., the creative design choices made in developing the SSO of APIs) is nonetheless not protectable if it functionally operates within a computer program as a command structure. This, of course, is what APIs do and this means that his conclusion can be used as a powerful guide in all future API copyright cases. As a trial court decision, this ruling is not binding on other courts, yet it is compelling and persuasive, which can amount to the same thing (including in its impact on the Ninth Circuit when it considers this case on appeal).
5. Oracle here is like the Black Knight in Monty Python: as each limb of this case was lopped off, it dismissively would say "a mere flesh wound." Now that its case has been reduced to a final stump, it can continue to declaim but who will listen? Maybe a long shot on appeal but I wouldn't hold my breath. This is an unbelievable outcome that illustrates that great good can come even from lousy things that people do. The computing world owes a great vote of thanks to Judge Alsup: the cause of interoperability has won a huge victory.
1. This is a meticulously researched, marvelously analyzed, and brilliantly synthesized order done by a judge who has a keen grasp of not just the facts of the case but of those that really matter. As the opinion notes, this was a case of "first impression" - meaning that no published decision has ever dealt specifically with the precise question raised of whether APIs in themselves are protectable by copyright or not.
2. The developer community needed a definitive ruling that was almost impossible to arrive at in light of the controlling precedents of the Ninth Circuit (which are binding on the judge). Why? Because (beginning with the Johnson Controls case in 1989) the precedents had held that the "structure, sequence, and organization" (SSO) of any part of a software program were potentially protectable by copyright and that the issues had to be determined case-by-case to determine whether a particular component was or was not protectable. Thus, the best a trial judge can do in such a case is to make a fact-specific conclusion about the case immediately being tried, one which would have limited impact in the next case, where the parties could argue the same issue on different facts. Yet, while doing just that and limiting his ruling to the particular facts before him, Judge Alsup has provided a definitive and logically compelling approach to how such issues are to be decided where they concern APIs and copyright and such reasoning is, in my view, destined to be widely applied throughout the court system going forward. Lower court rulings can have a powerful impact through the sheer force of their reasoning. This is just such a ruling. It is rare to get this. It could not have been better timed on a vital issue affecting interoperability in our modern era.
3. Fundamentally, Oracle had been arguing that the SSO of its 37 API packages reflected creative expression of precisely the type that the Copyright Act was intended to protect. And it is true that API design choices reflect all sorts of creative forms of expression. To deal with this issue, the judge got down to fundamentals, with the key language found at page 35 of the opinion: "Much of Oracle’s evidence at trial went to show that the design of methods in an API was a creative endeavor. Of course, that is true. Inventing a new method to deliver a new output can be creative, even inventive, including the choices of inputs needed and outputs returned. The same is true for classes. But such inventions — at the concept and functionality level — are protectable only under the Patent Act. The Patent and Trademark Office examines such inventions for validity and if the patent is allowed, it lasts for twenty years. Based on a single implementation, Oracle would bypass this entire patent scheme and claim ownership over any and all ways to carry out methods for 95 years — without any vetting by the Copyright Office of the type required for patents. This order holds that, under the Copyright Act, no matter how creative or imaginative a Java method specification may be, the entire world is entitled to use the same method specification (inputs, outputs, parameters) so long as the line-by-line implementations are different" (my emphasis). Thus, even though the judge was forced by Ninth Circuit precedents to assess the SSO based on the particular facts before him only, he did so by finding, as a matter of fact, that only a 3% layer of code dealt with the SSO of the API packages, that this consisted entirely of names that had to be identical for compatibility purposes and of tasks that could be performed in only one way in order to work, and in this way - having established the factual setting as consisting entirely of elements he concluded were unprotectable under copyright - he could make a powerful and sweeping statement of law that will undoubtedly have a huge impact on future cases.
4. The judge finally had to deal with the claim that the SSO constituted a sort of taxonomy that has been held protectable under copyright in other circuit courts. Here, too, he addressed the issue based on fundamentals: assuming that the API design structure here constituted a taxonomy, he nonetheless held that it was above all a command structure that was unprotectable based on 17 U.S.C. section 102(b) (which categorically excludes ideas, concepts, etc. from copyright protection). Thus (at page 39): "In our circuit, the structure, sequence and organization of a computer program may (or may not) qualify as a protectable element depending on the 'particular facts of each case' and always subject to exclusion of unprotectable elements. Johnson Controls v. Phoenix Control Sys., 886 F.2d 1173, 1175 (9th Cir. 1989). Contrary to Oracle, Johnson Controls did not hold that all structure, sequence and organization in all computer programs are within the protection of a copyright." This is another way of saying that what might otherwise constitute protecable expression (e.g., the creative design choices made in developing the SSO of APIs) is nonetheless not protectable if it functionally operates within a computer program as a command structure. This, of course, is what APIs do and this means that his conclusion can be used as a powerful guide in all future API copyright cases. As a trial court decision, this ruling is not binding on other courts, yet it is compelling and persuasive, which can amount to the same thing (including in its impact on the Ninth Circuit when it considers this case on appeal).
5. Oracle here is like the Black Knight in Monty Python: as each limb of this case was lopped off, it dismissively would say "a mere flesh wound." Now that its case has been reduced to a final stump, it can continue to declaim but who will listen? Maybe a long shot on appeal but I wouldn't hold my breath. This is an unbelievable outcome that illustrates that great good can come even from lousy things that people do. The computing world owes a great vote of thanks to Judge Alsup: the cause of interoperability has won a huge victory.
Please seriously consider starting a blog. Even if you post just once every two months, after major rulings, your analysis is always so illuminating. I come into legal threads on HN specifically to read what I know will be your top-rated comment.
Couldn't agree more, except I like the fact that grellas posts his stuff (which keeps getting better, by the way) as part of community discussions here. It's like one of HN's superpowers. Even though both are completely public, blogs feel more arm's length and isolated, where this is convivial.
I know, and I love that such in-depth and approachable analysis is a part of our community, but I feel compelled to tell him that it would benefit himself so much.
I remember you saying that this was clearly a judge who did his homework. I'm glad to see that he took his time and came up with the well-reasoned judgement I was hoping for.
Oracle's case has been coming undone for some time now. I couldn't believe the way their expert witness was rebuked in the denial of Oracle's JMOL motion the other day, either. They have, what? One claim for copyright infringement via those test files? I sincerely doubt that even the maximum penalty there would permit them to recoup the cost of this litigation. And I think you've said as much before.
Oracle's case has been coming undone for some time now. I couldn't believe the way their expert witness was rebuked in the denial of Oracle's JMOL motion the other day, either. They have, what? One claim for copyright infringement via those test files? I sincerely doubt that even the maximum penalty there would permit them to recoup the cost of this litigation. And I think you've said as much before.
The statutory penalty for the test files and rangeCheck is $150k per incident or $300k (which is nowhere near the $50 million estimated cost of the litigation for each party to date).
However, Oracle has elected to go after "infringer's profits" instead of taking statutory damages, so it is very possible that they will end up with less. It's very unlikely that they'd end up with more as the judge understands how trivial both parts are (and Oracle and Google have agreed to let him decide damages).
However, Oracle has elected to go after "infringer's profits" instead of taking statutory damages, so it is very possible that they will end up with less. It's very unlikely that they'd end up with more as the judge understands how trivial both parts are (and Oracle and Google have agreed to let him decide damages).
Wow, great analysis. Thanks.
I'm so glad to hear this. This is more than a win for developers (almost) everywhere, this is deterrence for large companies that want to bully others with their legal team when almost everyone is saying what their legal team is doing is at best suspect and at worst a travesty.
[1] A judicial clerk is a young lawyer, normally just out of law school and generally with a first-rate academic record, hired by a judge to serve for one or two years as a researcher and (often) as an opinion-drafter. ('grellas, for example clerked for Judge Ingraham.) Clerk positions are highly coveted among law students, because they can open doors to jobs in large law firms, the Justice Department, etc. As just one example, Chief Justice John Roberts clerked for then-Associate Justice, later Chief Justice William Rehnquist. See http://en.wikipedia.org/wiki/Law_clerk#United_States