Linked by Thom Holwerda on Thu 26th May 2016 22:13 UTC
Legal

At the end of their third day of deliberation, the jury found that Google's use of the declaring code and the structure, sequence, and organization of the Java APIs in the Android code was a fair use.

After the verdict was read aloud, Judge William Alsup thanked the jury for their service, noting that the jurors - who often came to court even earlier than the set start time of 7:45 AM, and lingered after hours to pore over their notes - had been "attentive" and "worked hard."

Great news for the industry.

Order by: Score:
Comment by motang
by motang on Thu 26th May 2016 23:15 UTC
motang
Member since:
2008-03-27

Good news, as this would have had a huge and very bad result on the industry!

Reply Score: 8

RE: Comment by motang
by bfr99 on Fri 27th May 2016 17:47 UTC in reply to "Comment by motang"
bfr99 Member since:
2007-03-15

Jury verdicts in this type of case are meaningless. I was personally involved in an intellectual property case that flipped-flopped at every appellate stage all the way to the Supreme Court.(Data General vs Digidyne 1985).

Reply Score: 3

Wait and see
by teco.sb on Thu 26th May 2016 23:36 UTC
teco.sb
Member since:
2014-05-08

Great news for the industry.

I don't know... To be honest, I think we'll only really know if this is the case sometime in the future.

What we know now, however, is that in the U.S. APIs are copyrightable and reimplementation is a copyright violation. The only thing Google proved here is that their particular reimplementation is "fair use". Someone else's reimplementation may not be. We'll only really know what is what when the next case comes along, if one ever does.

Reply Score: 9

RE: Wait and see
by galvanash on Thu 26th May 2016 23:41 UTC in reply to "Wait and see"
galvanash Member since:
2006-01-25

Yep

Reply Score: 2

RE: Wait and see
by phoenix on Fri 27th May 2016 01:32 UTC in reply to "Wait and see"
phoenix Member since:
2005-07-11

APIs are considered copyrightable in one federal circuit, not in all of the US.

Reply Score: 6

RE[2]: Wait and see
by nej_simon on Fri 27th May 2016 06:21 UTC in reply to "RE: Wait and see"
nej_simon Member since:
2011-02-11

For us outside America, what does that mean?

Reply Score: 3

RE[3]: Wait and see
by Drumhellar on Fri 27th May 2016 07:48 UTC in reply to "RE[2]: Wait and see"
Drumhellar Member since:
2005-07-12

It's more or less like this:

In the US, the Federal court system is divided into circuits, typically geographically, but some circuits have jurisdiction over specific subjects.

When one circuit court makes a ruling, it only sets a legal precedent within the circuit. Other circuits may use the precedent, but they are not bound by it, and there are times when different court rule differently on similar legal questions. Usually the way to resolve this is intervention by the Supreme Court.

So, Google had previously gotten a ruling in the circuit court that APIs were not copyrightable. The Court of Appeals (Which has jurisdiction nation wide) overturned that ruling, saying that APIs are indeed copyrightable, and sent the case back to the circuit court for trial. Google won the trial, successfully convincing the jury that their use of copyrighted APIs constituted fair use.

Now, something I think other people have missed, if I remember correctly, is that jury verdicts do not set binding precedent, even within the circuit. While the Jury decided that Google's use of copyrighted Java APIs was fair use, the jury does not have the authority to say that using copyrighted APIs is always fair use - only a judge can do that.

Until a judge issues a ruling himself that using APIs is fair use (And if the ruling survives appeal), or until Congress writes it into law, then companies can still sue over this, and it will still go to trial every time, even if over and over juries rule in favor of the fair use arguments.


Just a note: Patent law cases are decided nationally, and are not confined within geographic boundaries. Copyright, I'm pretty sure, is the same deal.

Edited 2016-05-27 07:55 UTC

Reply Score: 6

RE[4]: Wait and see
by softdrat on Fri 27th May 2016 22:07 UTC in reply to "RE[3]: Wait and see"
softdrat Member since:
2008-09-17

Just to clear a few things up - appeals involving copyright are NOT normally decided by the Appeals Court for the Federal Circuit, and in fact that Court rarely encounters them. The only reason it is hearing Oracle v. Google is because the original lawsuit involved patents as well, so all claims in the case get dragged along (at least, that is how I remember how this case started.) The Federal Circuit is actually a poor place to have issues such as the copyrightability of APIs decided. Much copyright law originates in the Ninth Circuit, which includes California - and Hollywood and Silicon Valley - and thus where many disputes arise. Judge Alsup is probably better positioned to make a sane ruling than is the Federal Circuit. Just my opinion.

Reply Score: 2

RE[2]: Wait and see
by kokara4a on Fri 27th May 2016 06:26 UTC in reply to "RE: Wait and see"
kokara4a Member since:
2005-09-16

APIs are considered copyrightable in one federal circuit, not in all of the US.


Doesn't the word federal ring a bell? There's only one Court of Appeals for the Federal Circuit and (Wikipedia):

The decisions of the Federal Circuit, particularly in regard to patent cases, are unique in that they are binding precedent throughout the U.S. within the bounds of the court's subject-matter jurisdiction.

Contrary to your statement.

Reply Score: 1

RE[3]: Wait and see
by phoenix on Fri 27th May 2016 15:24 UTC in reply to "RE[2]: Wait and see"
phoenix Member since:
2005-07-11

Note the "within the bounds of the court's subject-matter jurisdiction". The Federal Circuits Appeals Court deals mainly with patents (and a few other federal-level issues), not copyrights. Look through the list of jurisdictional areas that's just above the part you quoted on that Wikipedia page. You'll note there's nothing there about copyrights of any kind.

A case can be made that the copyright decision is non-binding precedent.

Reply Score: 3

RE[4]: Wait and see
by kokara4a on Mon 30th May 2016 05:44 UTC in reply to "RE[3]: Wait and see"
kokara4a Member since:
2005-09-16

So why is the case appealed in the Federal Circuit Court of Appeals instead of a Regional Circuit Court of Appeals?

Reply Score: 1

RE[5]: Wait and see
by phoenix on Mon 30th May 2016 06:06 UTC in reply to "RE[4]: Wait and see"
phoenix Member since:
2005-07-11

Because there was originally a patent part to the case, so Alaska automatically go to the federal circuit appeals court.

Reply Score: 2

RE: Wait and see
by ddc_ on Fri 27th May 2016 06:50 UTC in reply to "Wait and see"
ddc_ Member since:
2006-12-05

What we know now, however, is that in the U.S. APIs are copyrightable and reimplementation is a copyright violation. The only thing Google proved here is that their particular reimplementation is "fair use".

If it is fair use, it is not a violation.

Though you people turn this into drama, all decisions on the subject of copyright vs. APIs were totally predictable. The court could not just disregard copyright law and say that headers are not copyrightable. Headers are part of a copyrightable work - library - and are as much subject to copyright as all the source code is. The court could not say that reimplementation costitutes copyright infringement because it perfectly qualifies for fair use.

Well, there is still one thing that was not tested by court. Google's reimplementation of Java SE APIs was not thorough. A case about fully compatible implementation would remove the last ambiguities from the matter. But I wouldn't expect it to end differently.

Reply Score: 1

RE[2]: Wait and see
by przemo_li on Fri 27th May 2016 08:52 UTC in reply to "RE: Wait and see"
przemo_li Member since:
2010-06-01

BS.

Inserting mathematical formula into text book DO NOT make mathematical formula copyrightable!

Same goes for APIs. This is common thought in software development community.

Implementation is copyrightable. API is not.

No law needed. This is just how everybody understood it.

Until Oracle CEO & layers got their hands on it.


The best proof is in having not a single case about APIs beforehand. Even though copyright cases are quite popular, and enforcing copyright on implementation is quite popular.... APIs where never before copyrightable.

Do we need the law proclaiming the sky is blue too?

Reply Score: 6

RE[3]: Wait and see
by ddc_ on Fri 27th May 2016 11:06 UTC in reply to "RE[2]: Wait and see"
ddc_ Member since:
2006-12-05

Inserting mathematical formula into text book DO NOT make mathematical formula copyrightable!

Sorry, but you don't understand how copyright works. Formula in the book is not copyrightable, but excerpt of the book, even containing only that non-copyrightable formula, is convered by copyright. The expression - formula on the page, the page with that formula, the section of the book - all are protected by as parts of the single copyrightable work - the book.

Same goes with header files. Statements alone are not subject to copyright, just as individual words or sentences of the book are not. They are protected as parts of a whole protected work - implementation of Java SE.

Implementation is copyrightable. API is not.

Again, nobody ever said differently. API is an idea, and it cannot be copyrightable. Header files are text, and they may or may not be copyrightable as part of the whole work depending on whether they are trivial or not. Eg. header file with single statement
#define MAX(a, b) ((a) > (b)) ? (a) : (b)
is not copyrightable at all, while header files with function declarations of a complex project are subject to copyrigh for the project.

The claim that header files are inherently uncopyrightable is particularily funny when you consider projects like nanosvg¹ or queue.h.²

No law needed. This is just how everybody understood it.
[...]
Do we need the law proclaiming the sky is blue too?

There is copyright law, which always layed out the rules. Once courts decided that software is copyrightable, header files became parts of copyrighted works and recieved copyright protection immediately. Whether you understood it or not is irrelevant. The world is not there to please you, you know?

¹ https://github.com/memononen/nanosvg
² available in many places, eg. http://svnweb.freebsd.org/csrg/sys/sys/queue.h?view=annotate

Reply Score: 1

RE[3]: Wait and see
by dionicio on Mon 30th May 2016 14:05 UTC in reply to "RE[2]: Wait and see"
dionicio Member since:
2006-07-12

"...Inserting mathematical formula into text book..."

IF you worked very hard -years some times- to get to that simple formula, przemo_li, THEN you deserve some compensation for it.

You should ask some compensation to anybody wishing to publish that formula at manuals, websites, programs, tables.

[On related issue, how could Small Actors "Pay The Cost" of this Oversight on Their Copyrights? as is, LAW FRAME PROTECT ONLY BIG ACTORS].

Reply Score: 2

RE[4]: Wait and see
by dionicio on Mon 30th May 2016 14:38 UTC in reply to "RE[3]: Wait and see"
dionicio Member since:
2006-07-12

APIs are not Copyright-able because they're Protocol. They are created on explicit purpose to be shared. Not even Closed Source APIs are Copyright-able.

The nightmare with MS APIs is that They in the Past kept muting constantly, which goes against the philosophy of any Meta-Language. Meta-Languages should be more stable that Languages.

Its the direct use of Thousands Lines of Google Code, and at things not APIs also, what constitutes break of Trust.

Maybe, a form of reducing this tendency [simply grabbing the lines] among Coders is that an API plug should be build with a different language from an API socket.

Reply Score: 2

RE[5]: Wait and see
by dionicio on Mon 30th May 2016 14:53 UTC in reply to "RE[4]: Wait and see"
dionicio Member since:
2006-07-12

"...Thousands Lines of Google Code...".

Should say: "...Thousands Lines of Oracle Code...".

Reply Score: 2

RE[5]: Wait and see
by dionicio on Mon 30th May 2016 15:07 UTC in reply to "RE[4]: Wait and see"
dionicio Member since:
2006-07-12

"...Meta-Languages should be more stable that Languages."

Because the More Meta, the More Toward User Side.

Assembly is absolutely Developer.

Reply Score: 2

RE[5]: Wait and see
by dionicio on Mon 30th May 2016 15:27 UTC in reply to "RE[4]: Wait and see"
dionicio Member since:
2006-07-12

"... an API plug should be build with a different language from an API socket."

That would favor Security a Lot, also.

Reply Score: 2

RE[5]: Wait and see
by dionicio on Mon 30th May 2016 15:55 UTC in reply to "RE[4]: Wait and see"
dionicio Member since:
2006-07-12

There are Private APIs, not subject to this... The act of officially publishing whole or part; make that part copy-able, on fair use.

Customary is publishing a part, required as work-around to rise over emergency situations.

Salvo is, as long as they're declared Private, no moral duty to keep them Stable -or published-.

You shouldn't Bet any significant resources building over Private APIs, if not YOUR APIs.

Software Houses must be pressured to transfer those 'provisional' Surfaces to the Public API, and demanded on failing trust.

.....

But definitely, prefer Agent models. [Our agent, not Google' agent]. They have to have some intelligence -and ethics, and authority- embedded.

APIs are passé.

Reply Score: 2

RE[4]: Wait and see
by dionicio on Mon 30th May 2016 15:15 UTC in reply to "RE[3]: Wait and see"
dionicio Member since:
2006-07-12

But Rights are about Politics. Not about Reason.

No way to evade, even if OSnews is a tech site. Ignoring Politics is ignoring IT future.

Reply Score: 2

RE[4]: Wait and see
by Alfman on Mon 30th May 2016 16:00 UTC in reply to "RE[3]: Wait and see"
Alfman Member since:
2011-01-28

dionicio,

IF you worked very hard -years some times- to get to that simple formula, przemo_li, THEN you deserve some compensation for it.


I have no objection to that on face value, you should be paid. However if the implication is that you need patents to prevent others from working on it, then I strongly disagree. It doesn't make sense that algorithms should be exclusive.

Consider if you ask one software developer to solve a problem, he might come up with two or three solutions. A second developer will come up with a handful of solutions, BUT there may be some overlap. Ten developers working in the field are very likely to come up with several overlapping solutions. Eventually even though all developers are working independently, there will be fewer solutions than there are developers, which IMPLIES that some developers will not be entitled to use any of their own solutions.

So, if we allow these algorithms to be exclusive, then you end up in a situation where developers have difficulty solving the problems in their field without infringing just by chance. In the beginning software engineers would deliberately try to "engineer around" existing patents. Diverting developer effort to avoid patents is not only time consuming and expensive, but it leads to sub-optimal engineering. Today there are so many patents that avoidance is practically impossible, consequently patent lawsuits have to be absorbed into the cost of doing business. Even if we're not directly involved in these lawsuits, we all pay for it one way or another in higher prices, sub-optimal implementations, and less competition.

Edited 2016-05-30 16:09 UTC

Reply Score: 2

RE[5]: Wait and see
by dionicio on Mon 30th May 2016 16:49 UTC in reply to "RE[4]: Wait and see"
dionicio Member since:
2006-07-12

"...However if the implication is that you need patents to prevent others from working on it, then I strongly disagree..."

Also disagree, my argument is in the sense that Oracle missed focus on going after API use, and not code use.

Reply Score: 2

RE[5]: Wait and see
by dionicio on Mon 30th May 2016 17:13 UTC in reply to "RE[4]: Wait and see"
dionicio Member since:
2006-07-12

"...which IMPLIES that some developers will not be entitled to use any of their own solutions..."

That's convergent development, so common that demands are dismissed for trivial produces.

Remember that 11th JS liner that broke a lot of things at Scripting Wonder Land? Trivial.

The issue here is thousands lines of code, making ARDUOUS at best any argument about isolated development. Their hurry -not their competence- was such...

They capitalized and leveraged on another's work. Which being OPEN code, allowed.

Due compensations another issue, at that Licensing.

Reply Score: 2

RE[2]: Wait and see
by teco.sb on Fri 27th May 2016 12:55 UTC in reply to "RE: Wait and see"
teco.sb Member since:
2014-05-08


If it is fair use, it is not a violation.

If you read what I wrote again, you'll notice I said, "this particular use is fair use". A fair use argument must decided case-by-case, that's just the nature of the argument. Fair use is not a blanket statement, it has never been.

Though you people turn this into drama, all decisions on the subject of copyright vs. APIs were totally predictable. The court could not just disregard copyright law and say that headers are not copyrightable. Headers are part of a copyrightable work - library - and are as much subject to copyright as all the source code is. The court could not say that reimplementation costitutes copyright infringement because it perfectly qualifies for fair use.

What the courts said is that APIs are copyrightable (the federal appeals court, in this case) and a jury then decided that this particular case is fair use. As a previous poster noted, the appeals court ruling created a precedent, a jury trial did not.

Reply Score: 2

RE[3]: Wait and see
by ddc_ on Fri 27th May 2016 13:21 UTC in reply to "RE[2]: Wait and see"
ddc_ Member since:
2006-12-05

If you read what I wrote again, you'll notice I said, "this particular use is fair use". A fair use argument must decided case-by-case, that's just the nature of the argument. Fair use is not a blanket statement, it has never been.

This paragraph is meaningless. All arguments are decided by courts case-by-case. What you probably wanted to say that there is no guarantee that another similar case will end up with similar decision. While technically true, it is not a real concern. The court decisions are not rolled by random number generator: the argument that reproducing header files with a goal of creating compatible implementation does not constitute fair use had snowball's chance in hell from the very beginning.

What the courts said is that APIs are copyrightable

No. API is an idea, and it cannot be copyrighted. I have never heard about any court decision saying otherwise. What the court said is that header files – an expression of the API idea – are subject to copyright protection if conditions are met.

Edited 2016-05-27 13:24 UTC

Reply Score: 3

RE[2]: Wait and see
by segedunum on Sat 28th May 2016 13:28 UTC in reply to "RE: Wait and see"
segedunum Member since:
2005-07-06

Headers are part of a copyrightable work - library - and are as much subject to copyright as all the source code is.

Nope. The uncomfortable discussions about the GPL in this case said otherwise. Headers simply contain method names.

You are confusing code and merely method names. Licenses rely on the copyright of code libraries. This has nothing to do with whether the method of calling a library is itself copyrighted.

This is the view of Stallman and the FSF where the GPL is concerned: http://lkml.iu.edu/hypermail/linux/kernel/0301.1/0362.html

Reply Score: 3

RE[3]: Wait and see
by ddc_ on Sat 28th May 2016 22:23 UTC in reply to "RE[2]: Wait and see"
ddc_ Member since:
2006-12-05

You are confusing code and merely method names. Licenses rely on the copyright of code libraries. This has nothing to do with whether the method of calling a library is itself copyrighted.

This is outright wrong. The "method of calling a library" (whatever you may mean by this phrase) is not copyrightable. You can't enjoy copyright protection for a function name. You can't have separate copyright for a header file containing just function prototypes and trivial macros. Contrary to your statement such header file may only be subject to copyright as a part of a whole copyrightable object, including source code proper, header files, documentation, executables, intermediary object files, etc. Copyright may work at smaller granularity too, but only for objects that have all the necessary properties according to copyright law. This is just not the case here.

This is the view of Stallman and the FSF where the GPL is concerned: http://lkml.iu.edu/hypermail/linux/kernel/0301.1/0362.html

Do you understand that issue discussed in this mail (becoming derivative work by using the API) and issue discussed in Oracle v. Google are not even related? Oracle did not claim that Google's violation is in using Java SE API. Quite to the opposite, they claimed that Google used significant portion of copyrighted files from Java SE source in its work. Do you feel the difference between calling functions from the API and copying header files with a goal to reimplement the library providing API?

FWIW I don't really understand why do you talk about FSF. Their position is not necessarily defendable in court. (Although in this particular case it is unusually reasonable.)

Edited 2016-05-28 22:25 UTC

Reply Score: 2

RE[4]: Wait and see
by Alfman on Sat 28th May 2016 23:46 UTC in reply to "RE[3]: Wait and see"
Alfman Member since:
2011-01-28

ddc_,

This is outright wrong. The "method of calling a library" (whatever you may mean by this phrase) is not copyrightable. You can't enjoy copyright protection for a function name. You can't have separate copyright for a header file containing just function prototypes and trivial macros. Contrary to your statement such header file may only be subject to copyright as a part of a whole copyrightable object, including source code proper, header files, documentation, executables, intermediary object files, etc.


Except that the court did not say "header file may only be subject to copyright as a part of a whole copyrightable object, including source code proper, header files, documentation, executables, intermediary object files, etc." They held that the class declarations themselves are grounds for infringement, in their own words:
http://www.msn.com/en-us/news/technology/what-you-need-to-know-abou...
Because we conclude that the declaring code and the structure, sequence, and organization of the API packages are entitled to copyright protection, we reverse the district court’s copyrightability determination with instructions to reinstate the jury’s infringement finding as to the 37 Java packages,


Edited 2016-05-28 23:47 UTC

Reply Score: 3

RE[5]: Wait and see
by ddc_ on Sun 29th May 2016 00:17 UTC in reply to "RE[4]: Wait and see"
ddc_ Member since:
2006-12-05

Yup, they said that the contents of headers are entitled to copyright protection. They never said they are entitled so separately from the library (or API package as they confusingly call it). That is basically what I am reiterating for the whole freaking time.

Reply Score: 2

RE[6]: Wait and see
by Alfman on Sun 29th May 2016 00:57 UTC in reply to "RE[5]: Wait and see"
Alfman Member since:
2011-01-28

ddc_,

Yup, they said that the contents of headers are entitled to copyright protection.


Well, they don't even mention "headers", but the API declarations and structures themselves are copyrightable. Which is the exact opposite of how I read your posts.


They never said they are entitled so separately from the library


That's where we have to disagree. To most of us in the software industry, a "library" refers to an implementation of an interface. So assuming you are using this definition, then android does not infringe java libraries. If that were a prerequisite as you say it is, then the appetite court would not have reversed the lower court's ruling.

I'm not really understanding how libraries came up since this case wasn't about libraries. APIs are front and center here irrespective of infringing the libraries.

Edited 2016-05-29 01:09 UTC

Reply Score: 2

RE[6]: Wait and see
by segedunum on Sun 29th May 2016 13:04 UTC in reply to "RE[5]: Wait and see"
segedunum Member since:
2005-07-06

Yup, they said that the contents of headers are entitled to copyright protection. They never said they are entitled so separately from the library (or API package as they confusingly call it). That is basically what I am reiterating for the whole freaking time.

Which is completely meaningless and makes no sense. No matter how you cut this, what this trial shows us is that once you delve into how things work this cannot be true.

Reply Score: 3

RE[4]: Wait and see
by kwan_e on Sun 29th May 2016 00:58 UTC in reply to "RE[3]: Wait and see"
kwan_e Member since:
2007-02-18

Quite to the opposite, they claimed that Google used significant portion of copyrighted files from Java SE source in its work.


Except it wasn't significant.

Do you feel the difference between calling functions from the API and copying header files with a goal to reimplement the library providing API?


In another language, C and C++, to use header files for either purpose, you have to #include them, which is exactly copying and pasting.

Reply Score: 3

RE[5]: Wait and see
by dionicio on Mon 30th May 2016 16:14 UTC in reply to "RE[4]: Wait and see"
dionicio Member since:
2006-07-12

#include is instancing. Could you please instance your own header files?

Reply Score: 2

RE[4]: Wait and see
by segedunum on Sun 29th May 2016 12:58 UTC in reply to "RE[3]: Wait and see"
segedunum Member since:
2005-07-06

This is outright wrong. The "method of calling a library" (whatever you may mean by this phrase) is not copyrightable. You can't enjoy copyright protection for a function name. You can't have separate copyright for a header file containing just function prototypes and trivial macros. Contrary to your statement such header file may only be subject to copyright.....

This is meaningless tripe and I can't even begin to dissect it. It's a collection of words as well as seemingly to be a complete misinterpretation of what I wrote.

You can't copyright method names. It just isn't possible even if you wanted to, and that problem was shown up in this trial even after the Supreme Court ruling. All header files are is a list of method names. There is no implementation in there whatsoever. You can't have people copyrighting get() and set() or files where they are listed. It makes zero sense.

Do you understand that issue discussed in this mail (becoming derivative work by using the API) and issue discussed in Oracle v. Google are not even related?

Yes, they are related. It's why Oracle had to talk about ridiculous terms such as APIs being 'beautiful' and comparable to literature to reinforce copyright claims. They ultimately failed.

Quite to the opposite, they claimed that Google used significant portion of copyrighted files from Java SE source in its work. Do you feel the difference between calling functions from the API and copying header files with a goal to reimplement the library providing API?

No, there is no difference - and no I don't 'feel' it ;-). Header files are a list of methods. That's it. There is nothing more to it than that. You're desperately trying to squirm and slide here but it won't make what drivel you're coming out with any less ludicrous.

Google didn't use any significant portion of the Java SE source at all - whatever that might happen to mean, because there are a few implementations. This is meaningless and absolute unadulterated crap. Oracle had to start arguing about APIs because it's all they had left, and that's what this was about, use of APIs. They lost.

FWIW I don't really understand why do you talk about FSF. Their position is not necessarily defendable in court. (Although in this particular case it is unusually reasonable.)

Because their position is how legal people have always interpreted header files, and why Alsup made his first judgement. Additionally, GPL plus Classpath renders this null and void.

The wheels have come off Oracle's action and we now have to pick up the pieces as an industry of how illogical copyrightable APIs are and get back to work. Get over it.

Reply Score: 3

RE: Wait and see
by darknexus on Fri 27th May 2016 12:16 UTC in reply to "Wait and see"
darknexus Member since:
2008-07-15

You got it, right on. This won't help as much as people seem to think. Now they can prove that their specific implementations are fair use, but that doesn't mean the judge and/or jury will agree in all cases. Small businesses will be sued into the ground over this before they can prove anything.

Reply Score: 4

Should have been patents
by jonsmirl on Fri 27th May 2016 00:32 UTC
jonsmirl
Member since:
2005-07-06

The mistake here was done in the appeals court when they said APIs were subject to copyright. The correct answer was to say that they were patentable. Functional things get patents, expressions of ideas gets copyright. APIs are functional things. The implementation code is an expression of the idea on how to implement the API so it gets copyright.

If an API is patented then it is crystal clear if it is ok to clone it or not.

The Java API is not patented and that should have been the end of the story. If you want to close an API, just file a patent on it. But now we are stuck with this fair use mess.

Reply Score: 4

RE: Should have been patents
by Poseidon on Fri 27th May 2016 01:16 UTC in reply to "Should have been patents"
Poseidon Member since:
2009-10-31

Wouldn't that imply that the Java SE then would be patented, basically making everyone steer clear from it? This would also be impossible since their own license actually allows everyone to use it even during the Sun Microsystems days.


I believe this was a deliberate plan from Oracle since before they purchased it, as a loophole on the binary code license.

/conspiracytheoryst

Reply Score: 1

RE[2]: Should have been patents
by l3v1 on Fri 27th May 2016 05:32 UTC in reply to "RE: Should have been patents"
l3v1 Member since:
2005-07-06

"Wouldn't that imply that the Java SE then would be patented..."

We're talking about APIs here, specifically the Java SE APIs, and not Java SE. Nowhere on this planet could you patent APIs, not even in the US.

Reply Score: 3

RE: Should have been patents
by galvanash on Fri 27th May 2016 02:11 UTC in reply to "Should have been patents"
galvanash Member since:
2006-01-25

The mistake here was done in the appeals court when they said APIs were subject to copyright. The correct answer was to say that they were patentable. Functional things get patents, expressions of ideas gets copyright.


What does an API do? How is something so mundane novel? How would one consider such a thing "new and useful"? How, in light that there are literally thousands of APIs in existence, could an API not be an iteration of an existing concept. How do you even describe an API for the purpose of a patent filing?

The point is if it doesn't do anything, if it isn't novel, new, and useful, your patent will be rejected.

An API is a list of functions, with parameters and return types. How is that novel? Its like trying to patent a phone book...

Patents for for "new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof" (35 U.S.C. 101) An API is none of those, and frankly there is a mountain of prior art 10 miles high for virtually anything you could dream up...

Sorry, trying to shoehorn a the patent process on APIs is even worse than copyright. I am against the idea of software patents, but at least you can point at a compression algorithm and describe what it does...

How can you do that with an API?

Reply Score: 6

RE: Should have been patents
by segedunum on Sun 29th May 2016 19:18 UTC in reply to "Should have been patents"
segedunum Member since:
2005-07-06

Indeed so. They had to go the copyright route which was messy and just wrong on so many levels.

They didn't find any implementation code that Google had copied so attention turned to the interfaces. What was funny about the Supreme Court ruling is that they appeared to know how problematic copyrighted APIs would be so they built in the 'fair use' clause and then Oracle proceeded to make ludicrous claims about what would qualify as fair use.

For example, they actually argued that because Dalvik wasn't a complete Java/JVM clone, it would have qualified for fair use if Google had copied all the APIs verbatim. The whole thing became laughable.

Reply Score: 2

Comment by rubberneck
by rubberneck on Fri 27th May 2016 02:17 UTC
rubberneck
Member since:
2009-06-16

A real jury would have convicted Google of incompetence for using Java in the first place. Android is never gonna perform right because of it.

Reply Score: 2

RE: Comment by rubberneck
by nej_simon on Fri 27th May 2016 06:27 UTC in reply to "Comment by rubberneck"
nej_simon Member since:
2011-02-11

Why? What problems with the Java language do you think exist that will prevent Android from ever preforming right?

Reply Score: 4

RE: Comment by rubberneck
by dionicio on Mon 30th May 2016 16:27 UTC in reply to "Comment by rubberneck"
dionicio Member since:
2006-07-12

;)

On Google siding at this one, Oneself use what's available at the moment, and they where totally sold into a 'Grow as Beast or Die' strategy.

Reply Score: 2

It is disaster!
by przemo_li on Fri 27th May 2016 08:45 UTC
przemo_li
Member since:
2010-06-01

This verdict is DISASTER for the industry!

Because fair use is per case consideration. So the same trolling can happen as with Patents. Both parties can know that issue is BS, but party willing to sue can use court costs as leverage to get smaller settlement cash, even though claims where BS.

Just because most companies will pay less to avoid much bigger costs associated with going to court to prove Your innocence.

Reply Score: 4

RE: It is disaster!
by Vanders on Fri 27th May 2016 11:59 UTC in reply to "It is disaster!"
Vanders Member since:
2005-07-06

The disaster happened earlier, when another court decided that the APIs were copyrightable. This result mitigates the disaster a little bit by setting the bar for proving it wasn't fair use, and the bar has been set fairly high.

Reply Score: 6

RE[2]: It is disaster!
by darknexus on Fri 27th May 2016 12:12 UTC in reply to "RE: It is disaster!"
darknexus Member since:
2008-07-15

The disaster happened earlier, when another court decided that the APIs were copyrightable. This result mitigates the disaster a little bit by setting the bar for proving it wasn't fair use, and the bar has been set fairly high.

Not high enough to prevent startups from being sued into the ground though.

Reply Score: 5

RE[3]: It is disaster!
by Alfman on Sat 28th May 2016 15:31 UTC in reply to "RE[2]: It is disaster!"
Alfman Member since:
2011-01-28

darknexus,

Not high enough to prevent startups from being sued into the ground though.


Yea, API copyrights are a brand new weapon that will be used to troll for lawsuits.

This link is a video of some youtubers being sued for parody and commentary videos, which so many people are doing and nobody expects that to result in a lawsuit.

https://www.youtube.com/watch?v=fEGVOysbC8w

While their videos are just goofing around and have nothing technically to do with APIs, I think many of the points they make about having to go to court to make a "fair use" defense are very insightful for software developers as well.

Even if you are doing things that are normal practices in the industry, you can still be sued for them. You'd need to get a lawyer and take time off to go to court to make a defense in front of a jury. Not only is a trial time consuming and expensive, but a judgement against you could be devastating to your finances and career. Even in civil matters the court has the right to send you to jail for inability/failure to pay as demanded by a court order (I know someone that's happened to; it's shocking and tragic).

The guys in the video talk about what it means settle the case by paying a small amount and not going to trial, and their concerns about how it opens up Pandora's box inviting more lawsuits.


These guys managed to get over a hundred thousand in donations for their defense, and they're using the money to start a broader defense fund for fair use rights, which is very commendable.

https://www.youtube.com/watch?v=ix4mTekl3MM

However most small software developers who don't have the benefit of 1.4M followers might not be so fortunate to get help in defending themselves.

Reply Score: 3

RE[2]: It is disaster!
by Drumhellar on Sun 29th May 2016 00:18 UTC in reply to "RE: It is disaster!"
Drumhellar Member since:
2005-07-12

Jury verdicts do not set precedent, so the verdict sets no bar. Next time this issue is brought before a court, nothing as a result of the jury verdict will prevent another trial in front of another jury, and the issue will be litigated again, and again, and again, until Congress steps in and does something.

Reply Score: 2

RE[3]: It is disaster!
by Vanders on Sun 29th May 2016 10:46 UTC in reply to "RE[2]: It is disaster!"
Vanders Member since:
2005-07-06

It may not set a legally binding precedent, but it sets a precedent (I.e. it carries some weight). If another trial were in court now, you can bet your bottom dollar the defence lawyers would be referring to this trial during the process.

Reply Score: 2

RE[4]: It is disaster!
by Drumhellar on Sun 29th May 2016 19:06 UTC in reply to "RE[3]: It is disaster!"
Drumhellar Member since:
2005-07-12

A lawyer likely wouldn't be allowed to introduce the verdict in another case, since the verdict in the other case would rely on a different set of facts. Jury verdicts are determinations of fact, not law, and different cases have different facts.

However, jury decisions can become precedent. If Oracle appeals the verdict, and the judge determines that the verdict was correct, well, then it will be a precedent.

Reply Score: 2

MyNameIsNotImportant
Member since:
2013-01-02

Oracle is already saying it is going to appeal.

A legal system in that you can "retry" your luck until you get what you want is more like a joke.

Of course higher courts trump lower courts and so on, but what is this saying to the people of the Jury who spent a considerable amount of their lives on this case?

Oracle is the worst enemy of every developer(and therefore user), Microsoft is a saint in comparison, because they wouldn't challenge the right of developers to implement an API, they haven't ever threatened WINE/ReactOS that I know of for example.

Oracle however would destroy the whole ecosystem of free alternatives/free and open developments and of interoperable solutions, just so they can make money off of everybody. They are the nightwalkers of the software world at the moment, and I'm glad they have been stopped at the wall up until now.

I'm not using Oracle software if I can help it.

Edited 2016-05-27 10:35 UTC

Reply Score: 5

Rugxulo Member since:
2007-10-09

Oracle is already saying it is going to appeal.


Five years (and counting) down the drain.

Oracle is the worst enemy of every developer(and therefore user), Microsoft is a saint in comparison, because they wouldn't challenge the right of developers to implement an API, they haven't ever threatened WINE/ReactOS that I know of for example.


Remember that MS did clone CP/M's API for the original PC-DOS (which itself was cloned many times). So presumably they know better than to fight against themselves. Then again, they have enough money to pay a fine for it and still survive (unlike new developers).

Oracle however would destroy the whole ecosystem of free alternatives/free and open developments and of interoperable solutions, just so they can make money off of everybody.


You can never have enough money (apparently).

Reply Score: 2

Drumhellar Member since:
2005-07-12

A legal system in that you can "retry" your luck until you get what you want is more like a joke.


How else, besides an appeal processes, can you be sure that a court case, whether civil or criminal, was done fairly?

Besides, that isn't the case here. Oracle appealed a ruling, that APIs weren't copyrightable. They won that appeal

That led to a trial, and a verdict.

Now, they're appealing the verdict. This is a different thing they're appealing, one that didn't exist the first time they appealed.

If they lose, that's it. They don't get another appeal.

This is exactly how a legal system should work.

Reply Score: 2

MyNameIsNotImportant Member since:
2013-01-02

I don't disagree.

The point I was trying to make is really much broader. SCO vs Linux (IBM) was a huge story. Then we also all know about patent trolls, and there're all sorts of ways of abusing a court system that you can get away with.

Every time the defendant is dragged through a long and costly process. Even when the "good" side in the end wins, free, unhampered software development loses in the sense that such ludicrous litigation became possible in the first place.

The Oracle's of this world can afford the best lawyers and it's not inconceivable that they'll be convince one court sooner or later of their position, even though it's not consistent with the letter or the spirit of the law.

If "they" win just one case, the whole software development world loses.

A huge part why this is possible is that the general public doesn't even know what an API is, or why they matter, or why patents aren't a good thing at all except for perhaps extremely limited areas (and even there it can be debated).

So "we" are always fighting an uphill battle of explaining to the public (including judges, jurys) the significance of open development in the software industry (including for hobbyists).

There shouldn't even be a debate over whether or not the API in this case was fair use. It's an API, an API should always be fair use, since it's nothing but an interface (hence its name).

Oracle is spitting on us all, while technically they have every right to an appeal, this is really nothing but a huge FU.

Do you think they won't try to influence the law in their favor if they ever get a chance? This company stinks.

In a just world cases like this would get thrown out immediately.

APIs should be covered by free speech, this debate shouldn't have ever taken place.

Same goes for the idea that you can patent software algorithms, nobody except for patent trolls really benefits from that.

The work flow of developing software has nothing to gain from patents. It's a racket.

I feel the same way about this Oracle case. It's just a racket.

Because they are targeting Google it isn't instantly obvious to an outsider who the good guy is. One might think one huge corporation was scammed by another huge corporation, who stole its property. This is what Oracle is alleging.

Although that's total bullshit, the layman observer is not unlikely to believe Oracle at first. This brings us in the position of having to explain things again and again that we never should have to explain.

This whole case is fraudulant. Not in a technical sense, as you said, they're well within their constitutional rights, they're using the system in a way it was designed to be used.

What is fraudulant about it, they're creating the illusion that APIs (which they didn't even develop, only a company they bought did so) are much more valuable than they really are and that their APIs were so invaluable that they share a lot of credit for Android's success.

Every mediocre developer can write APIs, in fact if it was possible to write software by just writing APIs, the time to write software would drop to 0,01%.

APIs are just an intermediate language (or interface), describing symbols.

What's really at the core of every system are the implementation details (and debugging), which take up close to 100% of the work.

The illusion Oracle tried to create that their APIs are worth billions of dollars is the really dangerous side effect of this case IMO. (Similar story with SCO)

Even if the complete Java API had been proprietary from the start, this case should still be decided for Google.

The alleged damages shouldn't have been more than perhaps 1000 dollars. There's really nothing you can steal with an API.

But you can damage the complete software development world by insinuating APIs are the magic sauce that's worth billions.

Edited 2016-05-30 06:05 UTC

Reply Score: 1

dionicio Member since:
2006-07-12

This in not GPL -on lack of a stronger exemplar- This is not in the interest of the industry as a whole. Most of the time neither on the best interest of Clients and Users. True Development needs money. Lots of money at some critical phases.

Go pure GPL, and contribute, and live a happier life.

Reply Score: 2

APIs are still copyrighted
by lucas_maximus on Sat 28th May 2016 12:48 UTC
lucas_maximus
Member since:
2009-08-18

The other ruling needs to be reversed now, otherwise it is for nowt.

Reply Score: 2