Federal court overturns Oracle v. Google

A US federal court has overturned the jury’s decision in favour of Google from 2016.

Google’s use of Java shortcuts to develop Android went too far and was a violation of Oracle’s copyrights, the U.S. Court of Appeals for the Federal Circuit ruled Tuesday. The case – first filed in 2010 – was remanded to a federal court in California to determine how much the Alphabet Inc. unit should pay. Oracle had been seeking $8.8 billion, though that number could grow. Google expressed disappointment and said it’s considering its next steps in the case.

The dispute, which could have far-reaching implications for the entire software industry, has divided Silicon Valley for years between those who develop the code that makes software steps function and those who develop software programs and say their “fair use” of the code is an exception to copyright law.

“It’s a momentous decision on the issue of fair use,” lawyer Mark Schonfeld of Burns & Levinson in Boston, who’s been following the case and isn’t involved. “It is very, very important for the software industry. I think it’s going to go to the Supreme Court because the Federal Circuit has made a very controversial decision.”

This could be one of the absolute worst legal decisions in technology history.

About The Author

100 Comments

Google will probably try to appeal to SCOTUS, yes. This particular court that issued the ruling has a tendency to tend towards copyright and patent maximalism despite SCOTUS contrary rulings.

That said, don’t hold your breath the SCOTUS will pick up the case. They aren’t required to, most cases appealed aren’t actually taken to the docket. But, I will agree this is an extremely important issue to the software industry. It depends on whether or not the SCOTUS thinks the legal issues are important enough or they believe the Court of Appeals erred in interpretations of the law for the justices to review.

I hope they take it up, but I would lay no money if they did which way it would fall.

Nothing in this article gets at the heart of the issue over the use of these “header” files, which isn’t really the source code at all. Even worse, the only quote from them is questioning the “openness” of java – it isn’t open. If Google’s lawyers aren’t able to adequately communicate the issue, then I don’t have much faith they’ll prevail wrt SCOTUS.

They seem to be confused about the legal concept of Fair Use, and the colloquial understanding of fair.

VERY confused. To two things are barely related at all…

What frustrates me about this whole case is that while it is still ongoing, its already essentially over from the perspective of legal interest to me.

I really don’t care whether Google wins or loses a Fair Use case, because they already lost the case that actually mattered – whether or not copyright should apply to APIs.

Seriously, as much as I think Google is getting the shaft, I don’t think they have a valid Fair Use case. What they did with Java is not and should not be considered Fair Use, it just doesn’t fit into the purpose or spirit of what Fair Use is. That said, it shouldn’t matter, they shouldn’t need to mount a Fair Use defense when the copyright in question should have been invalidated in the first place…

I feel for them, I really do. They got screwed big time, but they are most likely going to lose this case in the long run…

It’s already pretty well established that when it comes to technology many in the judiciary don’t really understand a thing. This is why it’s possible to patent software in the US but not mathematical algorithms, despite software just being a particular representation of a mathematical algorithm.

So you supported MSFT when they ripped off Sun with MS Java, yes? Because I hate to break the news to ya Sparky but what Google did was the exact same bit, the only thing they changed was the name which was why Android could run unaltered Java code without issue.

BTW anybody that supports the GPL might want to think about what Oracle is fighting for, because if they lose what is to keep Google or any other corp from simply stealing all the GPL code they want and make it proprietary? After all if Java is fair game so is GNU and Linux, its the same laws protecting both.

but I’m like “Really? Oracle is still in business? Who buys their products? Really, who?”

I think it’s more that people buy contracts on existing products they bought decades ago and would have trouble replacing. Oracle does, and can for many years, rest on that without ever having to sell a single new product or contract, and without ever doing anything inventive or even useful, again.

You have to remember everything google touched of Java was licensed under LGPL.

This is where fair use kind of fails.

1) LGPL from the copyright holder had granted permission to use with terms.

2) Fair use is to allow actions that you don’t have permission to perform.

So does Fair Use allow you to skip out on a license that has granted you permission to-do task with minimal cost?

This starts sound strange to allow Google Fair Usage.

4. Effect upon work’s value

The 4 test of USA copyright law is hard. Effect on the work you have used Fair Usage against. Now google did effect the value of Java.

If android API was under LGPL like Java Google would not be needing fair usage. Not using this license means dropping the LGPL requirement to release source code that does effect value of a LGPL project particular if other parties are building on it.

In some ways this current case seams like the Judges do know what they doing just it taking a lot of time.

Really Google actions would not have passed Clean Room Guidelines by anyone. Clean and dirty room is how to legally split the copyrights when you need to re-implement api google did not do this.

Really the scramble is mostly like how many parties have not really been careful enough about licensing.

A license granting you rights to do everything with quite min terms to obey truly does block Fair Usage in copyright law in most cases. Yes having to justify why you are using fair usage when you already had permission is a up hill battle.

No sane developer before Oracle vs Google would say API is patentable, nor would they say API is copyrightable.

We have this horrible, horrible conversation only because court dropped ball on that point.

And that’s supposedly in case based law regime which supposedly tries to respect established practices if law do not cover given issue.

If Oracle vs Google goes into force, expect both massive wave of copyright trolling and secondly massive wave of briberies… eee… lobbying by software industry to correct this area of law, nobody knew even existed before.

Well before Oracle vs Google we had this older case. In settlement. This prior case USL v. BSDi there were ruling where BSD license headers had to be restored in the settlement stages.

So API in header files and the like has been copyrighted the complete time and the ruling that they were was in USL v. BSDi settlement stages.

Google arguement that API was not copyright was brought underdone by Orcale referring the older ruling because google had referenced the class files java directly not used written documentation describing the API and re-implemented.

Really the court is not dropping the ball. The legal teams are digging back through the existing rulings and finding out that rules were a little different than expected.

By the way USL v. BSDi is based on older rulings and some are quite funny like where a person writing a book exactly copied the table of contents word for word and they were not chapter titles like chapter 1.

So like it or not its been insane developer who have been taking the point of view that API is not copyrighted then stretching what this means.

Particularly when you have court case after court case ruling the other way if particular things are done like directly copying out the header files or extracting from binary files and auto generating.

Like implementing posix using a posix book that documents how the API is formatted legal. Taking a header file and implementing everything else is copyright infringement.

Don’t over presume how far the fact API cannot be copyright stretches. API cannot be copyrighted does not stretch to allow you to copy someone else work.

API not being copyrighted allows you to implement your own copy of the API as long as you respect the other implementations and don’t copyright infringe by using parts from the other implementations in ways their license does not allow.

You re-implement an API you don’t copy it legally. Anything that seams like copying most likely will be in court of law.

After “sleeping on” what I’ve read of the decision, and reading your rather well reasoned discussion of it, I tend to agree. The law pretty much was leading towards explicit copying (which is what Google actually did) of non-permissive licensed code headers was going to be not fair use.

If they’d simply licensed Java at the time, which they were in talks to do, they wouldn’t have been in this kind of trouble. No, they broke off talks, took the Java header code, which they didn’t have permission to use as Java hadn’t been opened yet, and verbatim copied parts of it into their Dalvik Java implementation.

A clean room re-implementation might have saved them this headache. Just being “Not Evil” and licensing the code would have saved them this headache. Implementing another open language as Android’s user land language, would have saved them.

I don’t see this as a bad ruling for FOSS software. It’s going to do two things: closed source software is going to be more avoided by all not willing to take out a license for its code (headers included). Already open sourced and/or royalty free open standard code will maintain their dominance in the industry, and hopefully everyone will be more diligent in respecting copyrights (right or wrong) to make sure they aren’t actually copying someone else’s non-permissive code.

I agree the only naive people have been us technologists and programmers that’ve played fast and loose with US copyright law. It also clearly points out that some developers that have championed the GPL in the past while calling this a bad ruling, are being illogical. Either your code base is copyrightable and falls under your stated license, or it doesn’t in which case your license is irrelevant. You can’t have both in the US. This ruling isn’t really about the API which is an abstract concept. It’s about direct copying of software code which is not abstract. There’s a big legal difference between the two.

I can’t legally copy Intel’s C/C++ compiler’s headers, call it my own and create the rest myself because, hey! I’m just using the API right? No you’re infringing on Intel’s copyright to their code. To create a C/C++ compiler based on the standards already published and permissively licensed you start with a clean room implementation much as GNU did with gcc or Apple with LLVM/Clang.

This is largely going to come down to a legislative issue. The American electorate, and therefore Congress & the President, are going to have to revisit copyright (and patents), realize maximalism has real consequences beyond lining MPAA and big biotech pockets, and enact reasonable reform. ( I somehow managed to write that last sentence without laughing. I’m impressed. )

A clean room re-implementation might have saved them this headache. [/q]

Do you really think it would though? A header file describes facts about a software API. What does a “cleanroom implementation” of an interface that’s designed to be compatible look like? As long as two pieces of software share the same interface, the facts describing those interfaces may well be identical regardless of how they were entered/generated in the header file.

This never mattered before as copyright protection did not apply to lists, factual information, or programming languages. But this oracle case changes things. Now that function prototypes are copyrightable, do you think that trivial obfuscation (like whitespace and reordering the lines) would change the copyrightability status of a header file? I really don’t know because this is such new territory, but I suspect that in a lawsuit a corporation might successfully argue that any interface could be considered a “derived work” as long as the factual properties are the same, even if the 3rd party version of the header file has been obfuscated.

I don’t see this as a bad ruling for FOSS software. It’s going to do two things: closed source software is going to be more avoided by all not willing to take out a license for its code (headers included). Already open sourced and/or royalty free open standard code will maintain their dominance in the industry, and hopefully everyone will be more diligent in respecting copyrights (right or wrong) to make sure they aren’t actually copying someone else’s non-permissive code.

That’s quite optimistic, but I think there are some very real risks for any software that’s designed to be compatible. Take software like GNU Octave or Scilab. Previously these FOSS projects were free to develop open source alternatives to Matlab, but now with oracle’s case law on the books a legal path for them to take down FOSS alternatives in courts has opened up (not that they are necessarily seeking a confrontation, many legit businesses are more honorable than that).

[q]I agree the only naive people have been us technologists and programmers that’ve played fast and loose with US copyright law. It also clearly points out that some developers that have championed the GPL in the past while calling this a bad ruling, are being illogical. Either your code base is copyrightable and falls under your stated license, or it doesn’t in which case your license is irrelevant. You can’t have both in the US. This ruling isn’t really about the API which is an abstract concept. It’s about direct copying of software code which is not abstract. There’s a big legal difference between the two.

Except that in practical terms an API is more factual than expressive. A class file might have methods A,B,C and take parameters X,Y,Z, etc. These lists can be formatted with different kinds of white-space or be reordered, but other than that everything has an exact functional purpose that has to match for compatibility.

Are you suggesting trivial formatting changes should allow developers to avoid copyright infringement? If so I kind of feel this is akin to suggesting I can copy source code or even a book by changing the margins, spaces, and paragraphs in order to avoid infringement… This doesn’t seem tenable; changes to inconsequential details like these shouldn’t be a justification for why something is copyrightable or not.

If on the other hand you argue that formatting changes to API declarations do not allow developers to avoid copyright infringement, then this statement of yours is wrong because you’d have to admit that developers are unable to implement the API: “This ruling isn’t really about the API which is an abstract concept. It’s about direct copying of software code which is not abstract. There’s a big legal difference between the two.”

Do you really think it would though? A header file describes facts about a software API. What does a “cleanroom implementation” of an interface that’s designed to be compatible look like? As long as two pieces of software share the same interface, the facts describing those interfaces may well be identical regardless of how they were entered/generated in the header file. [/q]

Both of these to applications are functionally identical. Reason why they are format the way you have should be explained by the source code behind it in the implementation.

There is more than 1 way to implement any API in header/class files that are functionally identical. Now when yours exactly matches someone else version you better be able to explain it without using anything that says coping.

This never mattered before as copyright protection did not apply to lists, factual information, or programming languages.

Last bit was never 100 percent true. Programming language is not different to the rules over any other language when it comes to copyright. The fact that programming languages don’t have different rules to normal languages under copyright law is down right important.

This is example of people stretching things.

That’s quite optimistic, but I think there are some very real risks for any software that’s designed to be compatible. Take software like GNU Octave or Scilab. Previously these FOSS projects were free to develop open source alternatives to Matlab, but now with oracle’s case law on the books a legal path for them to take down FOSS alternatives in courts has opened up (not that they are necessarily seeking a confrontation, many legit businesses are more honorable than that).

Not at all. Everything Octave and Scilab has done is explainable by the source code behind it. Its not a google android where stuff magically is named and order particular ways without any source code or valid documentation to explain it.

[q]Except that in practical terms an API is more factual than expressive. A class file might have methods A,B,C and take parameters X,Y,Z, etc. These lists can be formatted with different kinds of white-space or be reordered, but other than that everything has an exact functional purpose that has to match for compatibility.

You are right and wrong yes API is a factual expressive but implementation of API also have implementation details that don’t effect the functionality of the API and should be explained by the source code of the implementation. This is why you should not copy directly from header files/classes because they are formatted with that implementations details in mind.

This is the historic example of the the person who copied the table of contents of a book and then rewrote every single chapter differently. Since the table of contents did not match the contents of the book it had to have been nicked so the list restriction did not apply. So the test if a list like a table of contents/API is copyright infringing or not is if it makes sense to be that way for the contained contents of book/implementation code.

Obfuscation is one of these things when you wake up that copyright law applies even if you have translated a book into another language. You use Obfuscation to attempt to hide copyright you are legally stuffed no matter how you do it as this is classed as language to language translation so original copyright 100 percent intact even if every bit appears different.

Both of these to applications are functionally identical. Reason why they are format the way you have should be explained by the source code behind it in the implementation.

There is more than 1 way to implement any API in header/class files that are functionally identical. Now when yours exactly matches someone else version you better be able to explain it without using anything that says coping. [/q]

I disagree because adding “restrict” serves a technical purpose rather than an expressive one. So if I want to add “restrict” to my fprintf function prototype for technical reasons I’ll have to infringe on opengroup.org’s format of the declaration? Why should it matter for copyright purposes that I needed to use the restrict keyword or not? The modifiers I use should be dictated by my needs rather than copyright law.

The msdn fprintf documentation lists fprintf as the following:

“int fprintf( FILE *stream, const char *format [, argument ]…);”

But just because someone else has a matching fprintf prototype doesn’t mean I shouldn’t be able to use it in my own implementations because compatible interfaces are supposed to match, it’s not a coincidence!

You know, I could deliberately obfuscate the function prototypes by adding useless macro definitions:

A) Is this really something you want to encourage developers to do to avoid infringing?

B) It’s still likely that trivial modifications will not be sufficient to escape infringement because the modified version is still a derivation of the original, no matter the attempts to make trivial changes it’s still substantially the same. If I take a book and replace all instances of “harry potter” with “furry trotter”, it doesn’t free me from the obligations of copyright law.

What I don’t want is for this to become like the software patent situation where developers have to deliberately use subpar/confusing patterns to help defend against lawsuits. As long as we’re building our own implementations, that should be enough. Software developers should focus on the implementation rather than having to worry about whether someone else has used the same modifiers in a function declaration.

[q]Not at all. Everything Octave and Scilab has done is explainable by the source code behind it. Its not a google android where stuff magically is named and order particular ways without any source code or valid documentation to explain it.

They share the same function prototypes as Matlab, Octave aims to be fully compatible with it. It may not matter that the implementations is unique. None of us really knows how the courts are going to address these things in the future, but this case obviously puts these kinds of clones at greater risk than they used to be.

Even if we could assume that you were totally right, having this become case law is still a problem because more projects can be threatened with lawsuits. As with patent lawsuits, many small developers don’t have the legal resources to defend themselves adequately and it is cheaper to pay the aggressors than it is to defend themselves in court. API copyrights are just one more thing developers will have to worry about even when they have their own implementation as google did.

I disagree because adding “restrict” serves a technical purpose rather than an expressive one. So if I want to add “restrict” to my fprintf function prototype for technical reasons I’ll have to infringe on opengroup.org’s format of the declaration? Why should it matter for copyright purposes that I needed to use the restrict keyword or not? The modifiers I use should be dictated by my needs rather than copyright law. [/q]

The restrict keyword matches a lint tool. If you are not using lint/compiler that processes the restrict keyword you have no practical reason for your version of the API to have that word.

The msdn fprintf documentation lists fprintf as the following:

“int fprintf( FILE *stream, const char *format [, argument ]…);”

Does Microsoft compiler process the restrict keyword is no. So there is no reason for the restrict keyword to be present. So its not a key feature to inter-op right not like applications care that restrict is missing. Google case you find items like restrict that Google implementation never use and are not required for inter-op.

This is where google is in trouble Google copied more than what is required for API compatibility and had not worked out what applications in fact required. Remaking API for compatibility reasons have valid rulings in court of law. But its not open to do anything. You must be able to explain why ever bit is there.

You know, I could deliberately obfuscate the function prototypes by adding useless macro definitions:

This is really go to jail do not pass go because someone can claim that you used a filler macro in translation language to language with the translation hidden. Someone can argue in court that that filler was your translation of their term then you have to prove that you never their code and did not copy it.

If full copyright laws are applied the idea of deliberately obfuscate code will kind of disappear.

[q]Not at all. Everything Octave and Scilab has done is explainable by the source code behind it. Its not a google android where stuff magically is named and order particular ways without any source code or valid documentation to explain it.

They share the same function prototypes as Matlab, Octave aims to be fully compatible with it. It may not matter that the implementations is unique. None of us really knows how the courts are going to address these things in the future, but this case obviously puts these kinds of clones at greater risk than they used to be.

If you compare Matlab functions define to Octave functions define you will find differences. Yes the functions are functionally identical but items like restrict on posix in Mathlab code for mlint(yes Mathlab code error detection program) that Octave code does not need to copy for compatibility and have not copied.

Google wins over API with Oracle says what Octave has done is above board. Just one problem what Google has done does not match what Octave and other have done.

The reality is anything that is a independent implementation of a API you should be finding differences some will come from the compilers the API implementation is being built with.

inter-op does not extend to copy whatever. If you are coping for inter-op you better be able to explain why you copied very single bit. If you have copied 1 bit that the applications don’t need and you implementation don’t use you are up the copyright infringement creek question is how deep.

The restrict keyword matches a lint tool. If you are not using lint/compiler that processes the restrict keyword you have no practical reason for your version of the API to have that word. [/q]

Does Microsoft compiler process the restrict keyword is no. So there is no reason for the restrict keyword to be present. So its not a key feature to inter-op right not like applications care that restrict is missing. Google case you find items like restrict that Google implementation never use and are not required for inter-op.

Based on what you are saying, it seems like you are not aware that the “restrict” keyword actually has a functional purpose in defining the behavior of an interface. Adding it changes how the compiler treats aliased pointers in regards to automatic CPU register allocation. Using it is not an arbitrary thing you should tack on willy nilly without potentially creating side effects and compatibility bugs in the corner cases that the restrict attribute is designed for.

This is really go to jail do not pass go because someone can claim that you used a filler macro in translation language to language with the translation hidden. Someone can argue in court that that filler was your translation of their term then you have to prove that you never their code and did not copy it.

That’s precisely my point and I agree that copyrightability should not be determined by such gimmicks. Yet if courts ignore the filler/whitespace/obfuscation that were intentionally added for the purposes of circumventing copyright, then it means that there isn’t much a developer can do to build a compatible clone without infringing copyright on function prototypes.

If you compare Matlab functions define to Octave functions define you will find differences. Yes the functions are functionally identical but items like restrict on posix in Mathlab code for mlint(yes Mathlab code error detection program) that Octave code does not need to copy for compatibility and have not copied.

So you say, but we really don’t know how the courts will rule. This is new ground and if google lost, it’s likely others will too over time.

[q]The reality is anything that is a independent implementation of a API you should be finding differences some will come from the compilers the API implementation is being built with.

Google had a different implementation and still lost. Arguably in hindsight they could have redecorated their copy of the function prototype listing, but back in the early 2000s they had little reason to do so because such lists were never copyrightable before. Even if google had redecorated the function lists in ways like you are suggesting, it wouldn’t cease to be a derivative of Sun’s original API. You wouldn’t claim that redecorating books exempts us from the copyrights on them, so I don’t really know why you think redecorated header would bypass copyright protection? Again, how the courts will rule is a pretty large unknown.

[/q] Go back read the page carefully. Gcc MSVC and many other compilers don’t have a restrict. So a implementation targeting those compilers with a Restrict no-op macro is questionable and legal trouble.

Now if the macro existed to link __restrict__ to restrict when the compiler was gcc. Then it functional code. Now if your version of fprintf for example does not care and you have placed that in headers you have stuffed up legally.

That’s precisely my point and I agree that copyrightability should not be determined by such gimmicks. Yet if courts ignore the filler/whitespace/obfuscation that were intentionally added for the purposes of circumventing copyright, then it means that there isn’t much a developer can do to build a compatible clone without infringing copyright on function prototypes.

Part of the copyright rules is the 4 question one being “purpose of use”. So excess garbage in your header/class copied or added for obfuscation that has no functional purpose in your implementation means you cannot explain “purpose of use” for what you copied now your complete fair usage claim fails. Same with coping a restrict statement and making it a no-op macro.

Different ones of the 4 pillars of copyright in the USA goggle automatic processing gets them into trouble.

This is something to remember about fair usage. Either all your Fair Usage claim is valid or none of it is valid. So other side finds 1 flaw in your fair usage claim then you don’t have any fair usage protection at all. This is a pure black/white section of law.

The courts rules that Google had the right to request fair usage then Google fair usage claim was dirty with stuff copied that did not have to be so no fair usage protection end of story.

There are many software copyright and book copyright cases where this has played out the same way over and over again.

Obfuscation fairly much nukes any possibility of claiming fair usage. You need to be able to present openly and cleanly before the courts when claiming fair usage. Attempting to hide you usage is basically admitting you know what you are doing is wrong.

[q]Google had a different implementation and still lost. Arguably in hindsight they could have redecorated their copy of the function prototype listing, but back in the early 2000s they had little reason to do so because such lists were never copyrightable before.

None of the google ruling are new. All ruling the google rulings are based on predate google even buying Android. Lists being copyrightable under particular conditions was the legal state way back in the early founding of the USA and before.

Fair usage has always required being able to explain why you need fair usage.

Really the ruling have not change. If you make a new version compatible of a API/ABI you better be able to document that the code is all yours all bar the stuff that you could not avoid. Then it fair usage.

All the rulings against google had been the USA courts before a single line of android had been written for other court cases.

Basically your interoperability implementation has to be clean. No excess statements. Nothing included that does not make sense for your implementation. Then the courts have always ruled fair usage.

Oracle lawyers notices that all the prior ruling required that the party who had cloned the API/ABI proved that their implementation was 100 percent their code all bar what was required for compatibility. A single non functional part always ended up with the court ruling against you. There have been many copyright cases over software and the rulings are 100 percent consistent on the USA.

When it come out what google was doing before they even released Android many parties question if it was legal because it seams to be pushing fair usage way more than it had been. It turning out Google had.

If google wins cloning windows and the like will get simpler. If google loses the rules stay exactly how they always have been and its just the courts ruling how they have always ruled in software copyright cases.

People miss that google was ruled that it could attempt for fair usage and its the deeper review that google has failed.

Go back read the page carefully. Gcc MSVC and many other compilers don’t have a restrict. So a implementation targeting those compilers with a Restrict no-op macro is questionable and legal trouble.

Now if the macro existed to link __restrict__ to restrict when the compiler was gcc. Then it functional code. Now if your version of fprintf for example does not care and you have placed that in headers you have stuffed up legally. [/q]

Frankly I think it’s a bad idea to suggest that attribute modifiers should be used for anything other than their technically intended purposes since they’ll change API semantics. Projects like reactos can’t just go adding “restrict” to APIs without introducing new kinds of bugs.

To me, telling developers that adding/removing “restrict” is like telling them to add/remove “const”, it shouldn’t be done and if you do it changes the interface. These keywords have a technical meaning and we should not be coerced into changing them for copyright reasons.

Secondly, as you yourself have suggested, deliberately adding keywords for the purposes of circumventing copyrights doesn’t change the fact that it’s still derivative. Prosecutors are likely to point out that adding decorations to a book doesn’t change the fact that it’s derivative, adding decoration to a header file shouldn’t work either. And based on this logic, I’d have to agree with the prosecution even though I’m against what they’re trying to do.

Thirdly, even if stuffing keywords were to become an accepted copyright defense, then companies like oracle could deliberately keep files with all permutations of the functions to claim that all trivial permutations of a function prototype are copyrighted. After all, this is what corporations have done with patents in order to deliberately make patent avoidance as difficult as possible.

[q]Really the ruling have not change. If you make a new version compatible of a API/ABI you better be able to document that the code is all yours all bar the stuff that you could not avoid. Then it fair usage.

Basically your interoperability implementation has to be clean. No excess statements. Nothing included that does not make sense for your implementation. Then the courts have always ruled fair usage.

You say this, and I even agree with you that it should be this way, yet this case proves that we’d be wrong to assume that copying function prototypes that are necessary for compatibility are fair usage. Unless this case gets overruled, the case law from the federal court has set the precedent for function prototypes to not be fair use and what we say here about how it shouldn’t be copyrighted or it should be fair usage is mute. Whether either of us likes it or not, the lower courts are going to use this case law as precedent on fair use, which is why it was so important for google to win this case – at the end of the day they can afford an $8B loss, but the legal consequences for the software industry are far greater than them.

Google argument that API was not copyright was brought underdone by Orcale referring the older ruling because google had referenced the class files java directly not used written documentation describing the API and re-implemented. [/q]

Yes, but you are saying this as if it is a valid argument when it simply isn’t. Yes, the circuit court sided with Oracle, that doesn’t mean they were right…

I would actually argue that having such written documentation made available to the public (which Java has in spades) essentially voids any claim to intellectual property in regards to the API itself.

The API is not the header files, nor is it the documentation, it is the subject of both of those. It is the facts described within, one for the purpose of software interop and the other for human consumption – The same facts are being described either way. Facts are not eligible for copyright protection.

I’m not saying Google didn’t copy Oracles header files. I’m not saying header files should not be applicable for copyright. What I am saying is that the API (the facts therein) are not applicable for copyright, and the damages should be limited to the losses incurred.

How much did Google gain from not reading the documentation and writing their own version of the header files at Oracle’s expense (which would end up being roughly identical)? The wages of a few interns for a few months? A few thousand dollars maybe? Fine, Oracle wins. Who cares.

Billions of dollars? That is stupid.

So like it or not its been insane developer who have been taking the point of view that API is not copyrighted then stretching what this means.

I don’t think my viewpoint stretches anything. I think the idea that copying files containing simple facts, things that doesn’t express any functionality in and of themselves and don’t not represent any significant product of work, things that are almost identical to a recipe’s list of ingredients, that such a thing might result in a multi billion dollar judgement???

THAT is a stretch.

[q]Don’t over presume how far the fact API cannot be copyright stretches. API cannot be copyrighted does not stretch to allow you to copy someone else work.

What work did they copy? That is the conundrum… The work they copied was insignificant, it is some documents describing interfaces and whatnot. It is like 1/100th of 1% of the work that went into creating Java… The damages should be proportional.

How much did Google gain from not reading the documentation and writing their own version of the header files at Oracle’s expense (which would end up being roughly identical)? The wages of a few interns for a few months? A few thousand dollars maybe? Fine, Oracle wins. Who cares. [/q]

When something is identical down to functions that are not required for API there is a big problem. These functions are not written in any existing API java documentation. This is clear evidence that someone was using files they should not be in implementation.

This short cut of google could have save them months to years of development working out how to implement those functions correctly.

[q]Don’t over presume how far the fact API cannot be copyright stretches. API cannot be copyrighted does not stretch to allow you to copy someone else work.

What work did they copy? That is the conundrum… The work they copied was insignificant, it is some documents describing interfaces and whatnot. It is like 1/100th of 1% of the work that went into creating Java… The damages should be proportional.

Google documented what they did in the class files themselves using auto generation. Not implement the 1% of an API if it keystone to functionality means 90 percent of applications coded to use that API don’t work. Yes a a lot of what Google developers copied was keystone.

The time google gained in development was time Orcale lost to alter license and other things. So yes Oracle is in their rights when stuff up like this happen to claim lost sales because they did lose sales and they did not have as much time as they should have to adjust to changing market.

The fact re-implementing an API can cause the damage means you need to be very careful to avoid copying.

Please note the media has said the ruling says API is copyrighted. The ruling does not say that at all. Its says items like classes/headers are copyrighted.

Direct copying from them is off the table. Have a dirty room team documented the API and write documentation and have a clean room implementation team rewrite the API is still perfectly legal.

When something is identical down to functions that are not required for API there is a big problem. [/q]

Yes. So damages should be calculated based on the value of those functions which were copied… What value do they have if they were not used in the API and weren’t even implemented???

This is what your missing. Its not a question of whether or not they copied headers. They did. Its a question of what parts of those headers were actually eligible for copyright.

If you write a recipe book and I copy the list of ingredients for your recipe, that is not a copyright violation. This example comes directly from guidance materials published by the US Copyright Office.

It’s not a matter of whether or not I copied something, or how I acquired the information, it is a matter of the eligibility of the source material itself. Facts are not eligible for copyright. APIs are facts concerning an implementation.

[q]Google documented what they did in the class files themselves using auto generation. Not implement the 1% of an API if it keystone to functionality means 90 percent of applications coded to use that API don’t work.

But the keystone of functionality (the parts that are required for interop) are exactly the parts that should NOT be eligible for copyright. Damages should be calculated on the parts there WERE eligible for copyright (which was essentially nothing).

When something is identical down to functions that are not required for API there is a big problem.

Yes. So damages should be calculated based on the value of those functions which were copied… What value do they have if they were not used in the API and weren’t even implemented???

[/q]

Damages on books is calculated on value of book sales disrupted. Its not calculated on volume copied. So why should programs be a special case.

If you write a recipe book and I copy the list of ingredients for your recipe, that is not a copyright violation. This example comes directly from guidance materials published by the US Copyright Office.

Its not that straight forwards. If that list has spelling errors and you attempt to rewrite and hide that is the same recipe this is infringement. Just coping the list is fine. Copying the list and attempting to remake recipe you can be in copyright infringement.

The idea of not eligible for copyright does exist in copyright law. Conditions where copyright does not apply exists. Problem is you go out side those conditions and copyright comes back.

[q]But the keystone of functionality (the parts that are required for interop) are exactly the parts that should NOT be eligible for copyright. Damages should be calculated on the parts there WERE eligible for copyright (which was essentially nothing).

Key words is required for interop google copied more than what was required for functional interop. Google copied information their implementation core never used.

You you can think google case as a recipe lists that don’t match recipe example would be tools list and you notice that in the list of tools there are tools the recipe does not use that there is no practical reason for tools to be there. Only reason why those tools are their is the the list was copied verbatim from someone else recipe or the recipe has a prior version you contact the person who wrote the recipe and they admit coping from someone else.

Due to the high damaged with keystone stuff you should be very careful. Make sure that everything has valid reason and that you have not copied anything you don’t need.

Damages on books is calculated on value of book sales disrupted. Its not calculated on volume copied. So why should programs be a special case. [/q]

Please show me a sale Oracle lost due to this. Oracle (then Sun) did not sell Java. They still don’t. There were no sales to disrupt. They are not calculating damages on lost sales, they are (trying) to calculate damages on Google’s advertising gains, which is pretty ridiculous and more than likely won’t work anyway. But that is besides the point.

Its not that straight forwards. If that list has spelling errors and you attempt to rewrite and hide that is the same recipe this is infringement.

This is absolutely false. The list is simply ineligible for copyright. It may be part of a larger work that is, but the list itself is not. You can copy it (verbatim, with the spelling errors) and reuse it as much as you would like. You can even copy the directions, as long as they are limited to simple direct instructions (not including any creative flair or prose).

This is, btw, in a case where the accusation that the recipes were copied was essentially accepted as fact…

You make it sound as if copying such ineligible things is ok, but only as long as the “crime” cannot be proven. That isn’t how it works, it is not a crime in the first place. Its is perfectly legal – there is mountains of case law backing that up.

That is the law. It has been for decades…

My argument is simply that APIs are conceptually the same thing. They are statements of facts (names and types and whatnot, like a list of ingredients) and the bare minimum to describe the interface (the parameter ordering and return behavior, like a recipe’s directions). If that is true (and I personally think it is) then they are ineligible for copyright, which means you can legally copy them. Not recreate them through subterfuge (which is stupid), but copy them.

Also, you kept bringing up USL v. BSDi in your previous comments. That was a settled case – it never even went to trial. Nothing whatsoever happened in that case to establish an precedent. It is irrelevant to this entire discussion from a legal perspective. I’m only bringing this up because the problem is that there is simply no case law prior to this case concerning API copyright, which is my whole point – I was hoping this case would actually establish some.

It sort of did, just the wrong way…

[q]You you can think google case as a recipe lists that don’t match recipe example would be tools list and you notice that in the list of tools there are tools the recipe does not use that there is no practical reason for tools to be there. Only reason why those tools are their is the the list was copied verbatim from someone else recipe or the recipe has a prior version you contact the person who wrote the recipe and they admit coping from someone else.

What you are describing is almost exactly what happened in Publications International, Ltd. v. Meredith Corp. (which I linked to above). The plantiff lost that case…

THIS! … with one exception. I don’t think there should be ANY damages for copying the interface if your underlying implementation is different. You made it public for others to use. Any other entity (company, individual, etc) should be to use the same IF they rewrite the implementation from scratch in a clean room type environment.

I think some word choices and understandings are being conflated somewhere.

I think the original comment, to which you were replying, was not talking about whether or not developers are saying API *IS* legally copyrighted. Rather, I think the comment was more about whether developers believe APIs *should* be copyrightable.

Courts of law may say “Yes” they *should* be copyrightable, but I think many developers, including myself, would say “Absolutely NOT”. But, to clarify, when I say “API” I mean the *interface*, not the *implementation*. After all, API stands for “Application Programming Interface”. When I call `someAction(params);` in an API, I’m not copying the someAction() function, rather I’m invoking it to do some desired action on my behalf. This is the part I believe should NEVER be copyrightable. And that would include copying headers* (in the case of a language like C or C++) for the purpose of reimplementing the API myself. At that point, I’m copying the *interface*, not the underlying implementation (unless for some reason the original implementer put their implementation in the header for some weird reason).

* Again I’m talking about what *should* be legal, not necessarily what *is* legal.

I think some word choices and understandings are being conflated somewhere.

I think the original comment, to which you were replying, was not talking about whether or not developers are saying API *IS* legally copyrighted. Rather, I think the comment was more about whether developers believe APIs *should* be copyrightable.

Courts of law may say “Yes” they *should* be copyrightable, but I think many developers, including myself, would say “Absolutely NOT”. [/q]

This is where people stuff up. If a form of work like a text document is covered by copyright it covered until the copyright expired. The question is if the content of the document is enforceable under copyright law.

So everything about code is under copyright. The question is that copyright enforceable.

But, to clarify, when I say “API” I mean the *interface*, not the *implementation*. After all, API stands for “Application Programming Interface”. When I call `someAction(params);` in an API, I’m not copying the someAction() function, rather I’m invoking it to do some desired action on my behalf. This is the part I believe should NEVER be copyrightable.

Courts agree that copyright does not apply to API being Application Programming Interface. Problem here is API define in court is very tight.

[q]And that would include copying headers* (in the case of a language like C or C++) for the purpose of reimplementing the API myself.

You have now dived into the pit of legal trouble

By the courts headers/classes are implementation not interface. Sections inside a header file are Application Programming Interface these are the bits the Application linked against that header are are using and the library/implementation application code it being linked to.

Really legal takes word serous-ally.

Application first word of API this set context that is what the application users. Programming is that there is a implementation and and Interface is there something in the middle that is required.

Lot of places teaching programming and the like have be saying that a header file is a interface. Legally interfaces are in header files but header files themselves are not Interfaces but files owning to the implementation. Just like java class defines.

You think about it stdio.h from glibc and you attempt to use it unmodified with microsoft libc things don’t go right. Why because the stdio.h from glibc has stuff for that implementation. Same if you attempt the reverse.

Header files contents are a mixture of interfaces and implementation details. The law only allows you to take the interfaces anything else in the header files that are implementation details you have not copy unless the license allows you to.

The courts have not changed where they have ruled the lines are. Just there has been a major education problem. Counts have stricter define of interface and implementation.

Straight up coping headers is what part of what USL v. BSDi was about. Of course USL took it one step more by deleting BSDi copyright comment off the header files because in their point of view they were not copyright-able. Yes they got their head put on a spike for that one and came a no more company. This was one of the early cases that show there was a clear difference between implementation and interface and it was not define by header files or class files but define by what applications and implementation used.

Correction I forgot BSDi at the time was also delete USL copyright notices off of header files as well.

The settlement at the end of that case they had to put correct copyright notices back on header files.

So fairly much the idea that header files are not copyrighted has exploded in who ever face has believed that when it enters court.

There were a set of rulings that were public record before settlement in USL v. BSDi case. Request for court clarifications. Happened in 1992 and are public record and were public record that year.

What is API what is covered if you get those clarifications turn out to be defined 1960 or before.

These clarifications lead you back the the IBM cases over parties cloning the bios chip. Columbia Data Products was the first one to clone a bios without being sued out of the market by IBM due to using clean room methods. Eagle that release first clone 12 months after IBM TX release used dirty methods and was forced out the market due to copyright infringement. So 1982 is another year of repeated rulings some IBM won some IBM lost. The wins and loses in 1982 also tells us how you should clone a API/ABI. There was not the media coverage.

This has been the universal thing the courts are ruling the same way over and over again over API/ABI but how the courts have been ruling have been getting zero media coverage.

Fun part is go back to 1972 and you find another set of API/ABI court rulings and that was with DEC and PDP and its clones. So there are 3 set of rulings 10 years apart that are all ruling the same ways. Yes each of these groups parties win and lose on fair usage and what is acceptable and not acceptable has not changed at all in the courts eyes.

Issue here we have not been educating ourselves on how the court have ruled. Instead people take the point of view that it has to be random because 1 case wins and other loses and by the rough over view they are same.

There were a set of rulings that were public record before settlement in USL v. BSDi case. Request for court clarifications. Happened in 1992 and are public record and were public record that year. [/q]

I dont see what that has to do with the settlement details, nor why it matters one wit, but whatever.

What is API what is covered if you get those clarifications turn out to be defined 1960 or before.

I don’t know what this means.

These clarifications lead you back the the IBM cases over parties cloning the bios chip.

A bios is not an API. It does stuff. It has implementation code in it (LOTS of implementation code). You keep bringing up red herrings…

Columbia Data Products was the first one to clone a bios without being sued out of the market by IBM due to using clean room methods. Eagle that release first clone 12 months after IBM TX release used dirty methods and was forced out the market due to copyright infringement.

I don’t dispute that doing clean room reverse engineering is a way to skirt copyright law. What Im saying is in the case of an API it should be entirely unnecessary, because copyright shouldn’t be applicable to it…

This has been the universal thing the courts are ruling the same way over and over again over API/ABI but how the courts have been ruling have been getting zero media coverage.

NONE of those case involved APIs…

Fun part is go back to 1972 and you find another set of API/ABI court rulings and that was with DEC and PDP and its clones.

Again, NOT about APIs…

So there are 3 set of rulings 10 years apart that are all ruling the same ways. Yes each of these groups parties win and lose on fair usage and what is acceptable and not acceptable has not changed at all in the courts eyes.

I really don’t see how you are conflating the disputes over firmware with the copying of an API. One is an implementation of software and one isn’t. One does stuff and one doesn’t. None of those lawsuits were about APIs (or even ABIs) they were about copyright violation of actual software.

[q]Issue here we have not been educating ourselves on how the court have ruled.

Again, show me the case where the courts have ruled on about copyright violation concerning an API (not copying firmware, not cloning hardware, not license disputes, not fair use bullshit, an actual case where the defense tries to dispute the validity of the copyright on APIs themselves). To my knowledge the only one that has ever been ruled on in US court is Oracle v Google…

Again, show me the case where the courts have ruled on about copyright violation concerning an API (not copying firmware, not cloning hardware, not license disputes, not fair use bullshit, an actual case where the defense tries to dispute the validity of the copyright on APIs themselves). To my knowledge the only one that has ever been ruled on in US court is Oracle v Google…

The BIOS is a API. IBM compatible computer firmware exposed API. How you can clone this API so operating systems that depend on it can work are the early cases in courts. Yes firmware cases also attempted to claim the firmware API copyright validity in the same ways the Oracle vs Google case did. There is nothing new here.

The BIOS is a API. IBM compatible computer firmware exposed API. How you can clone this API so operating systems that depend on it can work are the early cases in courts. Yes firmware cases also attempted to claim the firmware API copyright validity in the same ways the Oracle vs Google case did. There is nothing new here.

Wait, hold the bus a minute. The BIOS *has* an API, but it also has an implementation! I’m seriously surprised that you are conflating these. Everyone absolutely needs a strong grasp of this distinction before going into the details of how each is affected by copyright otherwise the whole topic is going to be extremely murky.

All IBM PC compatible clones copied the BIOS API in order to be compatible, but this did not fall afoul of copyright law so long as they had their own implementations.

All IBM PC compatible clones copied the BIOS API in order to be compatible, but this did not fall afoul of copyright law so long as they had their own implementations.

One of the most collectable IBM PC compatible is the Eagle brand they are very limit numbers they made the same mistake as Google just did by reversing the IBM bios and implementing internal structures that applications never used. They lost their case back in 1982. Eagle IBM PC clones are collectable because there was only 1 batch of them.

Eagle mistake is they did not have two development teams. Team one reversing and documenting then team two using documentation and implementing. Result was the single team reversing and implementing copied the exact way IBM had done the internals result was in 1982 they lost in court and the court passed a very savage ruling that they could not make another IBM PC clone ever.

In a clean and dirty room setup the ones in the dirty room job is to make sure nothing enters the documentation that those working in the clean room should not know about.

At this point Oracle being paid billions is a very soft punishment. Oracle could have gone for that Google was forbid from making or supply another phone OS forever.

Historic rules warn you that making this mistake may have a ruling against you forbid you access to a market forever.

Yes two groups cloned the IBM PC bios in 1982. Columbia Data Products did it by proper clean room and most of the current PC bios trace to it. The other was Eagle. Both faced IBM legal team the clean room done by Columbia Data Products won fair usage and Eagle lost completely. Both were full implementations.

Having your own implementation does not mean you are safe if you have copied stuff that is not protected by interoperability requirements. This is what the 1982 court case against Eagle displayed. I can go back older.

Eagle mistake is they did not have two development teams. Team one reversing and documenting then team two using documentation and implementing. Result was the single team reversing and implementing copied the exact way IBM had done the internals result was in 1982 they lost in court and the court passed a very savage ruling that they could not make another IBM PC clone ever.

In a clean and dirty room setup the ones in the dirty room job is to make sure nothing enters the documentation that those working in the clean room should not know about.

…

Having your own implementation does not mean you are safe if you have copied stuff that is not protected by interoperability requirements. This is what the 1982 court case against Eagle displayed. I can go back older.

Copying the implementation was always grounds for copyright infringement, however all clones copied the API by necessity! Regardless of our opinions on cloning, this is a fact: prohibiting the copying of APIs is equivalent to banning clones since they could not function as clones without copying the API. Software would fail to function, it wasn’t a matter of creative choice protected by copyrights.

So do you have any examples where someone was found guilty of infringement for copying just the API rather than the creative pieces of the underlying implementation? If not, then maybe you can agree with us that this case does break ground for copyright protection of APIs.

Copying the implementation was always grounds for copyright infringement, however all clones copied the API by necessity! Regardless of our opinions on cloning, this is a fact: prohibiting the copying of APIs is equivalent to banning clones since they could not function as clones without copying the API. Software would fail to function, it wasn’t a matter of creative choice protected by copyrights.

So do you have any examples where someone was found guilty of infringement for copying just the API rather than the creative pieces of the underlying implementation? If not, then maybe you can agree with us that this case does break ground for copyright protection of APIs.

So Google has not copied just the API they have copied extras on top of the API. This is Eagle PC all over again. [/q]

Except in this case they had allegedly they copied parts of the implementation. Google only copied the API, a fact which nobody is contesting. Both galvanash and I asked you to find a case where just copying an API (and nothing more) resulted in loosing a copyright case, APIs have always been outside of the scope of copyright until this case.

[q]The judgement is quite clear. Google has been caught copying more than what they were legally allowed to just like Eagle did with BIOS.

Again, you keep shifting between things that are APIs and things that are not and conflating them in order to make your arguments, but unfortunately this does not help support the arguments you are making, unfortunately. If you want to find a case that is just about APIs, then please do that, but I’m not going to accept your cases if parts of an implementation were copied. Obviously we already know those are infringing uses.

Problem the court documents clearly say that Google did not copy only the API. Read the court documents and stop moving the goal posts to that Google only copied the API when that is not the case.

Google copied the API + the ways it was expressed + some implementation details when they copied the API areas verbatim.

It is undisputed that Google copied Oracleâ€™s declaring code and SSO for the 37 API packages verbatim.

Nobody’s moving the goal posts or contesting that google copied the header file, however it had always been explicitly out of copyright scope. Copyright law is explicitly not intended to cover trivial and non-creative variations “Mere variations of typographic ornamentation, lettering, or coloring” and “Mere listings of ingredients or contents”. They knew the trouble this would cause, but the problem (for google) is that nobody expects the court to ignore the government’s own guidance on the matter.

Nobody’s moving the goal posts or contesting that google copied the header file, however it had always been explicitly out of copyright scope.

Find the ruling that said header files where out of scope. You will find the ruling does not exist

There has been a problem with FSF and others saying header files were not copyright protected when the SSO ruling said they were or at least suggest they were since 1986 and confirmed 1992 to current. You are basically written made up garbage. Of course the FSF does not want to admit that they had it wrong because it has far reaching effects on how viral GPL and LGPL copyrights are.

All the statements that headers are not protected by copyright are not backed by a single court ruling stating that.

Yes 1992 a test was defined that you could apply to header file or source file or class file and work out if what you were coping was legal or not. The test make no separation between header file and any other form of source.

Any Source file could be declared all facts by the AFC test and if it was all facts there is no copyright to protect same with the other rules in the AFC test.

This is the big thing the courts give no special separation to if something is a header file, source file, class…. its all about what is the result after the AFC test. The AFC test was made to make processing cases like the 1985-6 case simpler and make it simpler to understand where you stood.

Find the ruling that said header files where out of scope. You will find the ruling does not exist

There has been a problem with FSF and others saying header files were not copyright protected when the SSO ruling said they were or at least suggest they were since 1986 and confirmed 1992 to current. You are basically written made up garbage. Of course the FSF does not want to admit that they had it wrong because it has far reaching effects on how viral GPL and LGPL copyrights are.

All the statements that headers are not protected by copyright are not backed by a single court ruling stating that. [/q]

For the record, I’d like to point out that your own AFC link agrees with the longstanding view that APIs are not copyrightable.

[q]Eliminating elements dictated by external factors is an application of the scÃ¨nes Ã faire doctrine to computer programs. The doctrine holds that elements necessary for, or standard to, expression in some particular theme can not be protected by copyright.[11] Elements dictated by external factors may include hardware specifications, interoperability and compatibility requirements, design standards, demands of the market being served, and standard programming techniques.

Obviously the whole entire reason an API and header files exist is interoperability.

Lists and facts were always outside of the scope of copyright especially since the government explicitly excluded the ideas, methods, lists and facts of which an API is comprised. Obviously you are of the mindset that it should be copyrightable, and that’s your prerogative, but the fact remains it was never copyrightable in the past. Unless you are able to find another case, this case with oracle is possibly the first where using function prototypes/header files (and not the implementation) were deemed to be copyrightable and infringing. All of your other cases and arguments thus far have referred to implementation infringement. I’m still open to your citing such a case where implementation was not infringed and only the API was, but every post that goes by without your producing one leads me to conclude that you aren’t able to.

That what you have just listed is what the AFC test in the first two stages removes. If there is anything left over its not pure API you have picked up extras.

1992 Computer Associates Int. Inc. v. Altai Inc

This case does into fact go into header files. Please note I have not once said that API is covered.

Google coping verbatim resulted in them coping more than the API. This is what results in Google losing.

The reality you have not challenged the ruling against google that have have breached the AFC test.

Also you have missed Structure, sequence and organization (SSO). SSO is a evil part of copyright law. So even if ever part you have copied is excluded and you have copied and presented them in exactly the same way with all the excluded parts there is still an identical structure left.

So remove ideas, methods, lists and facts from what google copied and you still have a identical structure google copied that has no functional requirement to be ordered that way. Result of identical structure of this form is copyright infringement on that structure.

Copyright does not protect facts, ideas, systems, or methods of operation, although it may protect the way these things are expressed.

Also stop ignoring you own quote. Way these things are expressed is a copyright death trap that google has walked straight into.

The rule of law does not in fact have any special rule for API so attempt to ask for cases API unique is just being a legal idiot.

That what you have just listed is what the AFC test in the first two stages removes. If there is anything left over its not pure API you have picked up extras.

1992 Computer Associates Int. Inc. v. Altai Inc

This case does into fact go into header files. Please note I have not once said that API is covered.

Google coping verbatim resulted in them coping more than the API. This is what results in Google losing.

Well, it doesn’t help your case that your own reference agrees with me and google did not infringe copyrights under those standards.

Edit: I’m still waiting on you to produce a case where the defendant lost just for copying an API/header files. If you can’t, then maybe it’s time for you to admit this is a new precedent for copyrights.

Well, it doesn’t help your case that your own reference agrees with me and google did not infringe copyrights under those standards. [/q]

No this is just you being clueless. You keep on ignoring you own quote.

Copyright does not protect facts, ideas, systems, or methods of operation, although it may protect the way these things are expressed.

[q]Edit: I’m still waiting on you to produce a case where the defendant lost just for copying an API/header files. If you can’t, then maybe it’s time for you to admit this is a new precedent for copyrights.

I started with a case where parties lost for copying header files. The reality is most of the cases I have referenced parties did copy header files and the ruling did them over for that as well as other parts.

In the 1990 case of Lotus v. Paperback the U.S. District Court for Massachusetts decided that Paperback’s VP-Planner software violated the copyright of Lotus’s 1-2-3 spreadsheet program since it had the same user interface, even though the underlying code was completely different.

This 1990 case shows how structure is nasty. Because everything they copied to lose is exactly the same stuff you said API is fine doing. SSO is far reaching.

So for your statement to protect google SSO cases would had to have been loses instead of wins.

Basically its legal to reimplement a API as long as you write you own header files/classes instead of copying them. Its legal to reimplement an API its not legal to copy it exactly if the license does not allow.

No this is just you being clueless. You keep on ignoring you own quote.

Copyright does not protect facts, ideas, systems, or methods of operation, although it may protect the way these things are expressed. [/q]

I did quote it and I would quote it again because it reflects exactly what I’ve been saying, only expressions can be copyrighted. And only those that are meaningful since copyright does not cover mere variations of typographic ornamentation, lettering, or coloring.

[q]In the 1990 case of Lotus v. Paperback the U.S. District Court for Massachusetts decided that Paperback’s VP-Planner software violated the copyright of Lotus’s 1-2-3 spreadsheet program since it had the same user interface, even though the underlying code was completely different.

That’s some serious overreaching, you are talking about “user interfaces”, other than sharing the word “interface”, you have to admit this has nothing to do with APIs.

No this is just you being clueless. You keep on ignoring you own quote.

Copyright does not protect facts, ideas, systems, or methods of operation, although it may protect the way these things are expressed.

I did quote it and I would quote it again because it reflects exactly what I’ve been saying, only expressions can be copyrighted. And only those that are meaningful since copyright does not cover mere variations of typographic ornamentation, lettering, or coloring. [/q]

Let say a header has 20 functions. If these functions were order A-Z you could argue that this is a normal ordering. If the functions are not order A-Z it the choice of the implementer to order them that way so making a copyright-able organization.

Any choice in ordering of stuff that does not effect the functionality of the api you better be able to explain.

Lets say the header file you are coping from has the following.

int fgetc(FILE *stream);

int getc(FILE *stream);

Yours has.

int getc(FILE *stream);

int fgetc(FILE *stream);

They are functionally identical from API point of view. But under copyright law they are a different sequence so independent works.

SSO gets tricky. Now if I did not want to alter the sequence I could attribute in a comment where I got the sequence from and go for Fair Use and by prior cases win 100 of the time. Google did not do this.

Google copied the sequence no attribute. But this is not google worst problem.

[q]In the 1990 case of Lotus v. Paperback the U.S. District Court for Massachusetts decided that Paperback’s VP-Planner software violated the copyright of Lotus’s 1-2-3 spreadsheet program since it had the same user interface, even though the underlying code was completely different.

That’s some serious overreaching, you are talking about “user interfaces”, other than sharing the word “interface”, you have to admit this has nothing to do with APIs.

API does not exist in copyright law. So why do you keep on referring it.

This example fails the AFC test the same way google does with the Java API coping.

Alfman I have a very big problem calling what google took API. Just look at that sample. Note all the private values that are internal use only declared with the same names in the same order…??? There is a problem here.

So google not only copied the API being the Application program interface but also copied the private internal values of the implementation.

Class files are not cleanly API they are a mix of API and Implementation. So when you are re-implementing a class you have to very careful to cut away the implementation.

See google worst problem they copied the Implementation as well as the API.

For the next few years most, but not all, circuit courts accepted the Whelan decision on SSO in one form or another.[13] This resulted in a period of tight protection for software, since almost everything other than the broad purpose of a software work would be protected. The only exception was where the functionality could only be achieved in a very small number of ways. In these cases there could be no protection due to the merger doctrine, which applies when the expression and the idea are inextricably merged.

Given that APIs are a very concise definition for a functional interface, APIs were clearly not intended to be covered under SSO either.

API does not exist in copyright law. So why do you keep on referring it.

That’s actually a fair question, APIs aren’t excluded from copyrightability by name, however they have been repeatedly excluded from copyrightability by their characterization, be it by copyright law’s exclusion of lists and facts, and indeed by subsequent case law.

[q]So google not only copied the API being the Application program interface but also copied the private internal values of the implementation.

Class files are not cleanly API they are a mix of API and Implementation. So when you are re-implementing a class you have to very careful to cut away the implementation.

Well, my concern here is with the expansion of copyright to include APIs. Just to be clear though: APIs refer to the structures and function prototypes necessary for interoperability, however inline code is part of the implementation and not part of the API. Maybe this has been the crux of our disagreement? Would you agree now that APIs explicitly barring inline code should not be copyrightable?

For the next few years most, but not all, circuit courts accepted the Whelan decision on SSO in one form or another.[13] This resulted in a period of tight protection for software, since almost everything other than the broad purpose of a software work would be protected. The only exception was where the functionality could only be achieved in a very small number of ways. In these cases there could be no protection due to the merger doctrine, which applies when the expression and the idea are inextricably merged.

Given that APIs are a very concise definition for a functional interface, APIs were clearly not intended to be covered under SSO either. [/q]

Due to API not being a legal term. The problem we have is parties define API slightly differently. So an API documentation might reference the existence of internal parts. So there is a audit process if you are going to duplicate a API.

[q]API does not exist in copyright law. So why do you keep on referring it.

That’s actually a fair question, APIs aren’t excluded from copyrightability by name, however they have been repeatedly excluded from copyrightability by their characterization, be it by copyright law’s exclusion of lists and facts, and indeed by subsequent case law.

So google not only copied the API being the Application program interface but also copied the private internal values of the implementation.

Class files are not cleanly API they are a mix of API and Implementation. So when you are re-implementing a class you have to very careful to cut away the implementation.

Well, my concern here is with the expansion of copyright to include APIs. Just to be clear though: APIs refer to the structures and function prototypes necessary for interoperability, however inline code is part of the implementation and not part of the API. Maybe this has been the crux of our disagreement? Would you agree now that APIs explicitly barring inline code should not be copyrightable?

USA law does not have not copyrightable. Everything is copyrightable the question is if the copyright is enforceable.

Pure API with without any implementation has normally been excluded there is two exception to be aware of.

Sega v Accolade causes a problem. Trademark Security System (TMSS) was part of the Sega console API/ABI. Just because it part of API/ABI does not mean you have the legal right to use it know how to avoid it and using that section of the API/ABI will display fraudulent information.

Exception two:

Something excluded from copyright protection does not magically give you the right to admit to straight up copying it and not including attribution. If straight up copying can be proven with any attribution to author then the SSO/”AFC test” can be skipped. Why skipped as this can move to a Counterfeit.

The fact the google ruling is mentioning SSO issue that by the processing of SSO compare would remove a pure API the ruling against google is not over a pure API.

Really need to drop the idea of non copyrighted. Everything is copyrighted. Even public domain is copyrighted that is the wacky law for you. Public domain everyone is the owner of the copyrighted work its a little hard to enforce copyright against owner.

So the reality is APIs have always been covered by copyright. SSO and AFC test are copyright enforcement limitations. Majority of what makes up an API will fall into the camp of copyright not enforceable. This does not mean you can blindly just copy.

Like if the list of functions in the header file makes sense for their implementation but the way you have implemented yours that order does not and you copy it hello trouble. This means if you are asked to justify why you are kind of stuffed counts of law can always ask you to explain your actions. One of the common question will be > “did you consider other ways this could be implemented?” You do want to answer yes to this. Then the following question will be “Why did you implement it that way?” and you better have good answer and that is not I copied it.

The big rule is with copyright verbatim copying without explainable reason/attribution will breach copyright.

The current copyright laws include the ones just used against google if you do your job properly don’t prevent you from re-implementing API. Merger doctrine correct used will always protect those correctly re-implementing API/ABIs. Yet to claim Merger doctrine in court you do need to be able to properly explain why in any of the questionable areas where re-implementation matches original in sequence and the like. Every time a party has done this properly re-implementation API and other things have been deemed either fair usage or copyright not enforceable.

The reality here is the current google v orcale case used existing rules that have been on the books for at decades in one form or other. The courts have not ruled anything new. The problem is Google has not done there implementation properly instead tried to buff though that what they did fell under the Merger Doctrine that no way in hell it does. Then attempted for fair usage without an attribution for what they copied.

Reality google was attempt to win automated regeneration of java/binaries. Googles automated tools were not copyright law conforming. It would be possible to make a tool that properly extracted only the legal API bits from a class.

USA law does not have not copyrightable. Everything is copyrightable the question is if the copyright is enforceable. [/q]

You are really dragging your feet here, to everyone else it is clear “copyrightable” means copyright is enforceable and “not copyrightable” means copyright is not enforceable.

So the reality is APIs have always been covered by copyright. SSO and AFC test are copyright enforcement limitations. Majority of what makes up an API will fall into the camp of copyright not enforceable. This does not mean you can blindly just copy.

Not for nothing but you still haven’t produced a case where API copyrights were “enforceable” in the past.

USA law does not have not copyrightable. Everything is copyrightable the question is if the copyright is enforceable.

You are really dragging your feet here, to everyone else it is clear “copyrightable” means copyright is enforceable and “not copyrightable” means copyright is not enforceable.

So the reality is APIs have always been covered by copyright. SSO and AFC test are copyright enforcement limitations. Majority of what makes up an API will fall into the camp of copyright not enforceable. This does not mean you can blindly just copy.

Not for nothing but you still haven’t produced a case where API copyrights were “enforceable” in the past.

The big rule is with copyright verbatim copying without explainable reason/attribution will breach copyright.

This is just not true, it doesn’t matter if something is copied verbatim when it falls “into the camp of copyright not enforceable”. The government guidance has been very clear on this.

When you get in court. If something fails the AFC test/not SSO this is explainable reason why you copied it. If you are challenged for copyright infringement does not matter to the courts if what you have been challenged on is legally allowed or not. Instead it is can you prove its legally allowed did you know it was legally allowed when you did it. Copyright enforcement is mostly guilty until proven innocent.

The other thing you have to remember is the copyright holder might choose to take you in a country with moral rights or equal in their copyright laws this is Australia, Germany and more where attribution is not optional. Just because something is legally allowed to be copied by it being copyright non enforceable does not mean it legal to-do world wide without attribution.

This ruling that API is not copyrighted in the Google v Oracle case still stands. The current ruling is under closer inspection what Google copied was not just API.

One of the problems with look for legal cases about API means there are not many. If you look at the legal cases about books they show examples when lists of stuff that would normally be a copyright non enforceable are enforceable. Big one you find in those cases is lack of attribution causes breach even in the USA.

[q]Not for nothing but you still haven’t produced a case where API copyrights were “enforceable” in the past.

This is basically the wrong question. API does not exist to the courts.

API is just texted. Ruling in any text case can be applied in API case and rulings in API cases apply to text. To get copyright non enforceable is win fair usage.

Over the years there have been a lot of made up rules not backed by the courts over copyright. Like if you copy less than 10% your fine this was never backed by the courts.

Same with the idea of copyright non enforceable so I can copy it. Instead you will find the courts rule copyright non enforceable due to fair usage or copyright non enforceable due to public domain/being the owner. Something is never ruled in a court as copyright non enforceable alone.

So in courts copyright non enforceable is a statement of outcome not a legal allowance. The legal allowance is fair usage and its the terms of fair usage that your actions have to conform to.

This is the big problem people think because something in the past has been ruled copyright non enforceable this gives them the right to copy it without considering the restrictions of fair usage.

1) any created work has copyright. This includes APIs.

2) If you can copy the work comes down to if you have legal right due to ownership rights, license or fair usage. There are only 3 option for legal copying.

Do note API are not special. As soon as you know this the outcome against google was always going to happen. There was no way to justify what google did under fair usage. Google was able to bluff the courts a lot more than they should have been able to.

Most court cases with reverse engineering and other software things have rule fair usage but all these old case give attribution. To find cases of non attribution like google v orcale one you have to go to books/other copyright protected media and those ruling do apply to source code when its the same automatically allow fair usage from copyright rule.

This is why I question why asking about API. API does not exist to the courts. What exists to the courts is this Fair usage or not.

Please do note I say structure would to be not protected if there was a functional reason.

If google have include clear attribution include source and license basically straight up going for fair usage have the same structure would not be a problem as reason the structure matches is a functional one to allow comparing with original.

Also covers a header file. Also rules that header copyright-able so had to go for fair usage assessment. Accolade wins that one on fair usage but header was also attributed the complete time to sega.

Also note that Accolade never distributed that header file of questionable license to any other party.

Sega v Accolade case is a pure ass as well with the TMSS that Sega wins on. This case clearly showed that you better be 100 percent sure that items you think you must use are in fact required.

Please note Accolade would not have won at all if the method of avoiding TMSS was public. In the end Accolade still loses and has to license from Sega. This case is purely about 1 header file and how it contents effect final binary.

Fuchsia is using Dart for application development, with a mix of C++, Rust and Go underneath.

It remains to be seen how much Dart love they will managed to get, now with Flutter being targeted to Android as well.

Given that Brillo was going to have Android Frameworks ported to C++, and instead they decided to reboot it into Android Things with Android Java Frameworks, they seem to think they will still get their way.

Ifeel that there’s waaay too much choice when it comes to programming languages today. Choice is good, mostly, but it can cause confusion and fragmentation. Sure, if language A has features that language B doesn’t support, choose language A, but don’t choose it because it’s “hip” and “popular”, because once upon a time Fortran was “hip”, and i don’t think there’s many people around who can fluently code in that anymore.

Ifeel that there’s waaay too much choice when it comes to programming languages today. Choice is good, mostly, but it can cause confusion and fragmentation. Sure, if language A has features that language B doesn’t support, choose language A, but don’t choose it because it’s “hip” and “popular”, because once upon a time Fortran was “hip”, and i don’t think there’s many people around who can fluently code in that anymore.

I would turn that logic around and say we shouldn’t use C/C++ just because it’s so popular for low level work. Yet most of us are guilty of doing it.

C++ inherits many of the flaws of C. By embracing the best parts and ditching the worst, D solves many of the most frustrating aspects of C/C++, but alas we keep using C/C++ out of habit and network effects.

You may be right about there being too many choices, but for better or worse C/C++ will likely continue to dominate low level development in spite of its longstanding problems.

They officially support Kotlin now, as of last year’s Google IO. And they switched to OpenJDK in Android Nougat. I gotta think both moves are because of this case, at least a big part of the decisions.

If you write a computer program about smashing sticks with rocks, you could indeed receive a Copyright for it. Ditto a poem about smashing sticks with rocks, or even photograph someone smashing sticks with rocks… that is all covered by Copyright.

And if someone wrote a novel, “Smashing Sticks with Rocks,” and you read a paragraph of that novel in a YouTube review, you are covered by Fair Use.

But if you steal a chorus from someone’s “Smashing Sticks with Rocks” song to use in your own song, that is not covered by Fair Use. You would owe the original author some money, as decided by a court.

Copyrighted interfaces meant that developers couldn’t legally re-implement software independently without a license or a fair use exception. Now that google lost the fair use exception under the latest ruling, it means that a whole lot of open source software may not have a legal right to exist without obtaining a license.

Consider wine, a project who’s goal is to be explicitly compatible with windows by independently implementing the code from scratch. The interface however has to remain the same out of necessity in order to be compatible. If software developers won’t be allowed to use existing interfaces without a license, then it also means that software compatibility is not allowed a license.

This whole legal case between oracle and google has been bad for the little guys since now the most powerful corporations have more legal methods to effectively block competitors and enforce their monopolies and oligopolies. There will be many negative repercussions from this and few, if any, positive ones.

If this same standard were applied to physical products, it would mean 3rd parties couldn’t sell aftermarket goods like car headlights or phone cases because they copied the “interface” of the original. Keep in mind this is irrespective of patents, merely using a compatible interface becomes infringement regardless of the implementation.

Copyright Law is it’s own thing. Your attempt to relate it to physical consumer products is moot, as those are covered by entirely different laws.

Obviously this doesn’t apply to physical products, but I wasn’t suggesting it does. It wasn’t a legal argument, it was a logical one. Consider that it would be unlikely for the same judges to deprive consumers of physically compatible products built by 3rd parties simply because they share an “interface”, yet this is exactly what they’ve done with respect to software built by 3rd parties.

Moreover, federal judges aren’t supposed to extend the law themselves, rather they’re supposed to enforce laws passed by legislators in congress. This case clearly increases the scope of copyright, the new case law has wide-ranging implications for the legality of software compatibility. I honestly think the judges were confused here and failed to apply common sense.

Moreover, federal judges aren’t supposed to extend the law themselves, rather they’re supposed to enforce laws passed by legislators in congress. This case clearly increases the scope of copyright, the new case law has wide-ranging implications for the legality of software compatibility. I honestly think the judges were confused here and failed to apply common sense.

The concept behind Fair Use, including specific examples, is spelled out in Copyright Law that has been passed by the Legislature and further clarified in policy by the United States Copyright Office.

Google’s use of Oracle’s copyrighted material clearly are outside the intended scope of Fair Use, which generally consists of limited reproduction for non-profit, educational, journalism, or even for a satire or parody.

If Google wrote an article about Oracle’s API, and quoted a bit of the API as an example or preview, that is the intended purpose of Fair Use.

The concept behind Fair Use, including specific examples, is spelled out in Copyright Law that has been passed by the Legislature and further clarified in policy by the United States Copyright Office.

Google’s use of Oracle’s copyrighted material clearly are outside the intended scope of Fair Use, which generally consists of limited reproduction for non-profit, educational, journalism, or even for a satire or parody.

I’m not arguing that header files should be fair use (the subject of this final lawsuit), rather the factual information about the API contained in the header files should have never been copyrightable in the first place. This is what galvanash has been saying. The moment they deemed function prototypes to be copyrightable is the moment the scope of copyright expanded to include list/facts rather than expressions as originally spelled out in the laws by congress.

You need a broader search over phone books. Its another case where some parties have won that its not enforceable copyright infringement and others have been done for copyright infringement.

This is kind of difference between interface and implementation.

The ones who lost copyright cases over phonebooks basically straight up copied the facts and the formatting. Its legal to copy the facts its not legal to copy the formatting as well. Formatting is like implementation details in header files.

So you cannot legally copy a phone-book as is. But you can make a new phone-book with new formatting using all the details contained in the phone-book. And that is the law.

To be correct plagiarism is in fact part copyright law. It falls under Fair Use allowance in copyright law. If you do not have permission from the Author/owner of a copyright work to put snippets under you own name this is in fact copyright infringement because fair usage does mandate that you acknowledge what you took.

Please note academic Plagiarism is stricter than copyright law Fair Usage equal due to the fact it does not allow a person to give you permission to use their work under you name.

So not correctly attribute the source of the information can get you into copyright legal hot water.

The ones who lost copyright cases over phonebooks basically straight up copied the facts and the formatting.

Exactly. The formatting is a publishing detail, a creative flair. Copyright applies to that, not the facts.

Do we agree on that?

APIs don’t have formatting. They don’t have fonts or font sizes or any means to convey a creative flair. The only exception is whitespace and how you name things. You can’t copyright names, and you can mechanically eliminate the whitespace issue easily. Any trace of creative flair, poof. Gone.

Its legal to copy the facts its not legal to copy the formatting as well. Formatting is like implementation details in header files.

This is the root of the argument, and you so far have been adamantly avoiding it.

If the implementation details (as Oracle calls it the structure, sequence, and organization) are eligible for copyright, then it is impossible to use reverse engineering techniques skirt around them. The problem is with an API, the structure, sequence, and organization are required to be identical for interoporability.

The fact is if you agree with this ruling, you are agreeing that reverse engineering of APIs, no matter how “cleanly” its done, is strictly illegal. If that is what you believe your entitled to it, but that is not going to be a healthy environment for the software industry…

[q]To be correct plagiarism is in fact part copyright law. It falls under Fair Use allowance in copyright law. If you do not have permission from the Author/owner of a copyright work to put snippets under you own name this is in fact copyright infringement because fair usage does mandate that you acknowledge what you took.

That is literally shit you just made up… There is no requirement whatsoever that you attribute anything. It s certainly a good idea, it will be taken into account in a Fair Use defense, but it is not required at all. Fair Use isn’t about attribution, its about how you use the thing you copied. When people use their DVR to record a TV Show (which is a violation of copyright), do they have to attribute the copyright holder before watching it in order to claim Fair Use? When you link to an article on the internet and include an small excerpt, do you have to include an attribution?

No you don’t, because those particular usages have been exempted.

Id rather not even discuss Fair Use, because almost no one understands what it is or what it means and I don’t even thing it should apply to APIs in the first place. I don’t want a Fair Use exemption on APIs, I want a classification of them as exempt (like recipes).

The ones who lost copyright cases over phonebooks basically straight up copied the facts and the formatting.

APIs don’t have formatting. They don’t have fonts or font sizes or any means to convey a creative flair. The only exception is whitespace and how you name things. You can’t copyright names, and you can mechanically eliminate the whitespace issue easily. Any trace of creative flair, poof. Gone.

[/q]

That is the problem there is creative flair in a header file with comments and other things. So an item like header file that is not a pure API.

If the implementation details (as Oracle calls it the structure, sequence, and organization) are eligible for copyright, then it is impossible to use reverse engineering techniques skirt around them. The problem is with an API, the structure, sequence, and organization are required to be identical for interoporability.

Google copied more than what was required to be identical for interoporablity.

There are other implementations of java done under other license.

Google picked up parts like Oracle java internal exception handling structures. Google used a set of automated tools that end up coping items that were outside the define of the Java API.

Note API starts with Application. If applications don’t use a part and you go and copy that structure identically and it comes non functional garbage as it came in google android you have a problem.

Processing a java binary class file also can contain extras added for the particular implementation that no application using the Java API will ever interface with. These structures are creative flair because anyone implementing Java API is free to use a different solution. Some of what has killed google is the existence of gnu class-path that had implemented some of the classes google used automated tools on the gnu classpath class don’t have some of the structures google copied yet been API neutral/Application did not see the difference so proven the extra bits google copied was creative flair optional formatting.

This is the problem with a class or a header you need process both carefully to make sure you are only taking the API. Take more be in google location without fair usage protection.

[q]To be correct plagiarism is in fact part copyright law. It falls under Fair Use allowance in copyright law. If you do not have permission from the Author/owner of a copyright work to put snippets under you own name this is in fact copyright infringement because fair usage does mandate that you acknowledge what you took.

That is literally shit you just made up… There is no requirement whatsoever that you attribute anything. It s certainly a good idea, it will be taken into account in a Fair Use defense, but it is not required at all. Fair Use isn’t about attribution, its about how you use the thing you copied. When people use their DVR to record a TV Show (which is a violation of copyright), do they have to attribute the copyright holder before watching it in order to claim Fair Use?

There have been cases over fair usage of videos in education settings where the credits had been cut of video so fair usage did not hold.

I did not make stuff up. You don’t to attribution you are running high risk if you are challenged on fair usage. I am in Australia we have a Moral rights in our fair usage/ fair dealing with copyright clauses. The Moral Rights clauses means attribution is mandatory. Australia is not the only one with mandatory attribution to claim fair usage. Something to be aware of if the item you copy in the USA and attempt to claim fair usage on owns to Australian the Australian has the rights to take USA cit though Australian courts due to the copyright treaties between USA and Australia. I am answers what is worst case for USA.

Copyrighted interfaces meant that developers couldn’t legally re-implement software independently without a license or a fair use exception. Now that google lost the fair use exception under the latest ruling, it means that a whole lot of open source software may not have a legal right to exist without obtaining a license.

None of the rulings have effected re-implementing API/ABI by the clean/dirty room method. Clean and dirty room method does not need fair use exception.

Some rulings have effected using some blackbox method in some countries. Blackbox being test cases and auto generating probing test cases can be on the wrong side.

The ruling effect directly coping and using auto generation.

Most open source software has obeyed the rules. There will be some that have overstepped.

Reality here if you have properly obeyed the legal rules that have been in effect for over 100 years you are in no trouble. If you have attempt to stretch those rules you are in trouble.

You have to look at code like it is a book if what you were doing was not legal to with a book its not legal to do with source code either.

Absolutely. If two people were told to photograph the Eiffel Tower, their photographs would each be protected by copyrighted (automatically in fact, no registration necessary). But if one person copied someone else’s photograph instead of taking their own, that would be a Copyright Violation.

My point, software Copyrights aren’t different from other copyright-protected materials. You can’t copy someone else’s code, (or text or photos or logos or music), and distribute it as your own. And if you use someone else’s code (or text or photos…), you should expect to be sued for Copyright Violation in District Court especially if you used their copyrighted materials for commercial use.

My point, software Copyrights aren’t different from other copyright-protected materials. You can’t copy someone else’s code, (or text or photos or logos or music), and distribute it as your own. And if you use someone else’s code (or text or photos…), you should expect to be sued for Copyright Violation in District Court especially if you used their copyrighted materials for commercial use.

But they are different now because of this oracle case!

If I copy a list of ingredients in a recipe, I am allowed to do that because it’s not protected. However if I take a list of function prototypes in a header file, I am not allowed to copy it any longer because the oracle case has expanded the scope of copyright.

Copyright, a form of intellectual property law, protects original works of authorship including literary, dramatic, musical, and artistic works, such as poetry, novels, movies, songs, computer software, and architecture. Copyright does not protect facts, ideas, systems, or methods of operation, although it may protect the way these things are expressed. See Circular 1, Copyright Basics, section “What Works Are Protected.”

The API defines a system of names&methods that a caller must use to invoke functionality. Moreover it does so succinctly with very little creativity/individuality (other than comments, which could be copyrighted, and trivial things like whitespace, which are a “mere variation”). It’s crystal clear that copyright legislators never intended for copyright to be used to block other implementations of an idea. It also should be plainly obvious to anyone familiar with software and who isn’t lying that copyrighting an API does block other implementations, which is completely contrary to what copyright law intended to do.

Who knows if either congress or the supreme court will have the time to overturn this, but this case law, as it stands, is a huge expansion of copyright for software.

The judgement is quite clear. Google has been caught copying more than what they were legally allowed to just like Eagle did with BIOS.

There is absolutely no shift in law.

Copyright does not protect facts, ideas, systems, or methods of operation, although it may protect the way these things are expressed.

This is the very problem. Google copied the exact way Sun developers expressed 37 java interfaces. Now Orcale acquired sun.

Google has lost because they have the exact same expression worse they admitted they straight up copied it. Its not the case that the expression is the same because they attempted to reimplement the API and it just turned out it had to be that way.

There is just no way Google should be allowed to win this.

Everything on the list copyright does not protect is protected if you copy it in a photocopier because you are copying the way is expressed.

Alfman it was one of the very bits you highlighted that should have had alarm bells ringing there are limitations on how you can copy an API, list… what ever without getting into copyright infringement.

Its really simple to forget copyright protects expression of ideas. The method of Expression of API also come into what are called implementation details/differences because you have things like company style guides, company mandatory commenting, implementation internal features and more and they all fall under this generic tittle and google guilty of stomping over this stuff.

Using someone’s Copyrighted material to create a competing commercial product… I don’t see how that would ever be considered Fair Use under Copyright Law.

I completely agree. If the original ruling (which was correct) wouldn’t have been overturned, there would be no copyrighted material in the first place, Oracle would have lost, and we would be in a far better place legally.

Fair Use shouldn’t have even been brought up in this case, Google just pivoted out of desperation after Oracle won their appeal…

I’d say that 99% of folks think “fair use” covers more than it actually does. The definition is actually quite narrow and doesn’t cover much at all (at least nothing that 99% of people are interested in).

You really really really have to twist things to get “fair use” to cover whatever “violation” you’re attempting. And certainly, we’ve seen some of those creative twists in the past.

I’d encourage everyone to read up on it. You’ll wonder how anything is actually covered under “fair use”.

Therefore, I would not argue this case using “fair use”. You should lose that one (depends on what the courts are smoking at the time though).

Does Oracle deserve to die? Absolutely. Not a nice company. Who will win this war? I have no idea.