Google v. Oracle (Supreme Court Copyright Case)

[TwiceHorn 31,619]

3 minutes ago, Captainant said:

I agree and that is the crux of the issue. I don't know where to find the files to look myself, but in court filings, Google argued that in submitting the code to the court, Oracle "redacted or deleted...both expressive material and copyright headers." Google called these omissions "significant elements and features."

Edit: source for the claim, can't find the actual filing...

That doesn't seem to have continued to be an issue in the case.

As a sidenote, there can always be an issue as to exactly what is copyrighted, particularly because the US requires a copyright registration.  The rules do not require filing a copy of the entire source code as part of the copyright registration (a relic of paper filing days when the Copyright Office did not want to store reams of greenbar paper associated with copyright filings).

A smart copyright owner will archive versions of software specifically for the purpose of providing an accurate copy of what was registered at any given time.  And will make a new registration for every significant version of the code, as in 1.x, and 2.x, but forego registrations for the .x versions.

[Captainant 27,861]

Jesus fuck you lawyers. Just cryptographically sign the package with your key to prove ownership. Why do the lawyers have to get paid to make new software? Lol I think the patent lawyer just wants more blood in the water

[TwiceHorn 31,619]

4 minutes ago, Captainant said:

Jesus fuck you lawyers. Just cryptographically sign the package with your key to prove ownership. Why do the lawyers have to get paid to make new software? Lol I think the patent lawyer just wants more blood in the water

And you wonder why some of us that interface with the government on a regular basis are skeptical of government.

The issue is not so much ownership as did the copyright owner doctor the code after the fact to make it appear more similar than it actually is.

Edited September 26, 2020 by TwiceHorn

[bernorange 8,367]

6 hours ago, TwiceHorn said:

Why does it not seem like a copyright violation?  Show your work.  ...

So as you know, I'm not a lawyer and the arcane art of determining what the definition of "is" is isn't my wheelhouse.  But it seems pretty clear to my layman's sensibilities that if you literally copy a significant portion of someone else's published work, you likely violated their copyright to that work.  Now there may be issues at hand as to whether the work in question is actually copyrightable and I don't know enough about the application of copyright law to have an informed opinion on that.

6 hours ago, Captainant said:

...

If you're writing a cross-compatible runtime environment for code, there is literally no other way to accomplish that but to use the same headers ...

This is true, but ensuring Android is cross compatible with Java is a business goal.  I'm not sure that "we want our product to work like their product" is really a defense that you infringed on their intellectual property.

6 hours ago, TwiceHorn said:

If Google could have successfully provided a functional programming interface without literally copying the declaration statements, by changing a letter or two, or the order of the letters, or the structure and sequence of the variables the statements employ, then they copied it at their peril.

...

Google could definitely have taken Oracle's headers and jumbled the order of the declarative blocks to make the files literally different while functionally the same.  I'm not sure that would really be a defense against copyright infringement.  It would be like copying a book and rearranging the order the chapters and/or paragraphs.  Except a computer can read it all and interpret/understand it the same either way.

If Google had "changed a letter or two", Android would have functioned for code written specifically for it, but it would not have been cross compatible with Java (because code designed for the Oracle/original specification would be misspelled per the Google/Android specification).  So yes, changing a letter or two would have worked in the sense that Android would have been functional, but it would have failed in achieving the desired cross compatibility business goal.

I'm thinking what Google could have done that would likely have solved the copyright issue and ensured cross compatibility would have been to take Oracle's headers and create a derivative work where they created their own taxonomy that is structurally the same, but with their own nomenclature and then included aliases for Oracle's nomenclature.  I'm not sure how robust the alias feature is for header definitions across different programming languages, but I think most languages offer at least some form of it.

Edited September 26, 2020 by bernorange

[immamac 43,255]

I have a really good example of a potential ripple effect from this that will directly effect me. 

My company Percona creates open source software which maintains 100% compatibility with the upstream versions and then adds back in open source implementations of features and functionality that Oracle, MongoDB, 2nd Quadrant/EDB lock away behind paid proprietary software licenses (enterprise editions).

We also maintain 100% api compatibility there, now maybe the difference is the real clean room - no one has seen the uncompiled or the compiled version we just build it to the documentation spec. We name the variables the same, the intended behavior is the same etc. We do this and license again under GPLv2. 

The implications here are much broader than you can imagine. It would potentially wipe entire companies like this off the face of the planet virtually overnight and the FOSS movement would essentially be completely dead for any commercial entity other than the main contributor or owner of the source code. This would mean you are free to use the software, but not free to manipulate and redistribute for a price. Everything you know would be different, tech would go from very cheap to forcing everyone into a single choice for vendor for any given piece of open source software. 

The biggest companies in the world depend on this software, if they were forced to pay enterprise edition licensing it would transform the bottom lines of ALL industries that use tech enabled open source companies. This would be an additional 10-500M cost depending on size of companies using enterprise edition like features, implemented by them or someone else that now can't unless they pay for them. 

Twitter, facebook, netflix, all significantly impacted.

PayPal, Airbnb, HomeAway, palo alto networks, walmart, any health care network or provider, the list goes on and on.

I think this is pretty crazy shit and if Oracle wins it forces 1 path forward for monetized open core software. 

[Captainant 27,861]

32 minutes ago, immamac said:

My company Percona creates open source software which maintains 100% compatibility with the upstream versions and then adds back in open source implementations of features and functionality that Oracle, MongoDB, 2nd Quadrant/EDB lock away behind paid proprietary software licenses (enterprise editions).

Wait wait wait, I knew you were in the DB business but I didn't know that y'all WROTE Percona! Goddamn

[TwiceHorn 31,619]

I had a thought that perhaps explains bernorange's potential objection and comment that "it's not software."  And maybe captainant's too.

In this case, Google itself doesn't "code" or write into any software the declaration statements published in its or Oracle's API. Rather it is the app developer that actually codes the API text into software when it needs or wants to.  So, in that sense, it's not Google that is "copying," but the app developer.  Whether the declaration statements and other material must appear in Android somewhere to enable the functionality of the API, I don't know, although it seems to me likely.

That is an interesting point, but not an issue that was raised in the litigation.  There are a couple of reasons for this.  First, as tends to be typical, a software owner registers a copyright in both the source code and the documentation, which would include the API descriptions.  That is stated in the opinions to be the case here. So Google's publication of something similar to this https://docs.oracle.com/javase/7/docs/api/java/awt/Font.html#constructor_summary would infringe the copyright "for the software," whether Google actually codes any of that or not.

Second, under the doctrine of inducement of infringement when an entity like Google gives precise instructions similar to the above that "direct" app developers to copy/use the declaration statements and syntax, structure and organization of the data inputs, etc, Google becomes liable for the copyright infringement of third parties that do the actual copying.

So, this notion doesn't absolve Google of copyright infringement (but it would seem to go to damages because not every copy of Android would necessarily involve copying of the API material).

In any event, it is not an issue that is presented in the case.

[TwiceHorn 31,619]

57 minutes ago, immamac said:

I have a really good example of a potential ripple effect from this that will directly effect me. 

My company Percona creates open source software which maintains 100% compatibility with the upstream versions and then adds back in open source implementations of features and functionality that Oracle, MongoDB, 2nd Quadrant/EDB lock away behind paid proprietary software licenses (enterprise editions).

We also maintain 100% api compatibility there, now maybe the difference is the real clean room - no one has seen the uncompiled or the compiled version we just build it to the documentation spec. We name the variables the same, the intended behavior is the same etc. We do this and license again under GPLv2. 

The implications here are much broader than you can imagine. It would potentially wipe entire companies like this off the face of the planet virtually overnight and the FOSS movement would essentially be completely dead for any commercial entity other than the main contributor or owner of the source code. This would mean you are free to use the software, but not free to manipulate and redistribute for a price. Everything you know would be different, tech would go from very cheap to forcing everyone into a single choice for vendor for any given piece of open source software. 

The biggest companies in the world depend on this software, if they were forced to pay enterprise edition licensing it would transform the bottom lines of ALL industries that use tech enabled open source companies. This would be an additional 10-500M cost depending on size of companies using enterprise edition like features, implemented by them or someone else that now can't unless they pay for them. 

Twitter, facebook, netflix, all significantly impacted.

PayPal, Airbnb, HomeAway, palo alto networks, walmart, any health care network or provider, the list goes on and on.

I think this is pretty crazy shit and if Oracle wins it forces 1 path forward for monetized open core software. 

Well, there are certainly bad possibilities.

But, the fact remains that, until now, an API was just another piece of software in which any proprietor could assert a copyright.  None  apparently have done so, and none are likely to in the future, either.  They're just as likely to stop open source licensing and start charging money for everything else, too.

Open source licensing of APIs seems to be the common  or even universal industry practice, and, in fact the Java APIs are open source licensed, but Google could not qualify for the open source license because it was not fully compliant.  In the open source world, they wanted to have their cake and eat it too.

The entire software world could stop open source licensing tomorrow if it wanted and the results would be utter chaos.  But, that seems unlikely for precisely the reasons that the open source model has been so successful in the first place.

 

Edited September 26, 2020 by TwiceHorn

[TwiceHorn 31,619]

2 hours ago, bernorange said:

This is true, but ensuring Android is cross compatible with Java is a business goal.  I'm not sure that "we want our product to work like their product" is really a defense that you infringed on their intellectual property.

 

Actually, in this context it is a perfect defense, subject to the below.  If an "item" of software is necessary to carry out out a function (in the API case, cross-compatibility of software), and can only be done one way, by copying someone else's software (not the "functionaltity" but the actual words and syntax, structure, and organization, the "literal elements") then that indicates that the item of software is wholly functional, and employed or employs no creativity whatsoever in its authorship, and is not therefore either original or copyrightable.

2 hours ago, bernorange said:

Google could definitely have taken Oracle's headers and jumbled the order of the declarative blocks to make the files literally different while functionally the same.  I'm not sure that would really be a defense against copyright infringement.  It would be like copying a book and rearranging the order the chapters and/or paragraphs.  Except a computer can read it all and interpret/understand it the same either way.

 

The scope of protection provided by copyright varies.  "Artistic works," where the author has complete freedom of choice in color, material, size, proportions and all the various elements that make up an artistic work such as a sculpture or painting, or a book or song, get the broadest scope of protection.  "Factual works" such as news articles get less protection, because in reporting factual stories there is a limited amount of choice available to the author:  she has to include who, what, when, and where, and those items are not "thought up" or chosen by the author.

Computer programs, as "functional" things, receive the absolute narrowest protection available under the copyright law.  Verbatim copying is mostly going to be necessary to prove infringement.  So, changing up minor things would not avoid infringement in an artistic work, but it absolutely will with a computer program.  You cannot prove copyright infringement in a computer program by relying on "non literal" elements like "it's overall kind of similar, they both have good beats, I could dance to them."  It is going to require note-for-note similarity, or better stated, identity.

That Google could have done it without verbatim copying is a bad sign for Google.

Let me give you a rudimentary example.  Let's say I can prove that I am the original author of  and own the copyright in "Hello World" in C.  Let's say you write a "Hello World" in Python.  They both do the exact same thing in printing "hello world" to a screen or output device.  But the source code doesn't look anything alike, although "symbolically" they are similar within the context of C and Python.

You do not infringe my copyright in Hello World in C, even if you had a copy of my code sitting on your desk while you wrote it up in Python.  I cannot rely on the functional or symbolic similarity ("non-literal elements") between the two programs to establish infringement.  I must have that literal similarity and just the appearance of the words hello and world in the source code is not going to do it, because those are necessary to achieve the function of printing "hello world" to an output device.

Now, let's change it up a bit.  Let's say you wrote your Hello World in C, but chose some other commands and syntax to do it, so that the source code literally looks very little like mine.  I'm too rusty to propose how you would do it, but I am pretty sure you could do it.  Again, no infringement.  This is the result of the narrow scope of protection accorded to computer programs in copyright law.

A further point.  If there was only one way to write hello world in C, as is likely the case in machine code for a given processor/kernel, then my hello world program in C would be uncopyrightable because I had no choice in how to write the code, so it is not original and not copyrightable.

 

Edited September 26, 2020 by TwiceHorn

[immamac 43,255]

38 minutes ago, TwiceHorn said:

Well, there are certainly bad possibilities.

But, the fact remains that, until now, an API was just another piece of software in which any proprietor could assert a copyright.  None  apparently have done so, and none are likely to in the future, either.  They're just as likely to stop open source licensing and start charging money for everything else, too.

Open source licensing of APIs seems to be the common  or even universal industry practice, and, in fact the Java APIs are open source licensed, but Google could not qualify for the open source license because it was not fully compliant.  In the open source world, they wanted to have their cake and eat it too.

The entire software world could stop open source licensing tomorrow if it wanted and the results would be utter chaos.  But, that seems unlikely for precisely the reasons that the open source model has been so successful in the first place.

 

I'm not sure that you understand the difference and nuance here. If google can't be eligible for usage of an OSS code base because of some caveat then it isn't OSS it's source available, which is completely different. Source available you can use, potentially modify it for your own purposes, but no one else can do that for you except the owner of the license. 

It's extremely problematic and every OSS is fucking copyrighted with it's license, the idea of copyleft and OSS is that even though it's copywritten and attributed to the author there are no commercial or otherwise implications from using it. 

It's the same reason AGPL and now the SSPL are problematic licenses. 

You are positioning this like the apache vs elastic license where there are 2 distinct versions that are licensed differently but share the codebase. That's not at all what the Oracle (or sun) license for Java is or was.

OpenJDK is not JavaSE or JavaEE but it's good enough now for people not to care. The problem is here:

Quote

The only way to demonstrate compatibility with the Java specification is by meeting all of the requirements of Sun’s Technology Compatibility Kit (“TCK”) for a particular edition of Sun’s Java. Importantly, however, TCKs were only available from Sun, initially were not available as open source, were provided solely at Sun’s discretion, and included several restrictions, such as additional licensing terms and fees. In essence, although developers were free to develop a competing Java virtual machine, they could not openly obtain an important component needed to freely benefit from Sun’s purported open-sourcing of Java.

This is from Google's defense team. The spec they built the API against WAS NOT open source and that's what the issue is. (even though now it has later been made FOSS under gpl)

That's the straight up definition of copyright infringement. The reason it's problematic is because the license change after the fact we are in truly uncharted waters. The fact that it's going to the supreme court is a good thing, but I cant really say that either decision is awesome for open source. If you can rip off copyrighted not shared documentation api as OSS that is pretty fucked up. At the same time if you can't use APIs in a FOSS way then...we stifle commercial innovation.

[TwiceHorn 31,619]

Another observation.  Digging into this, the whole thing appears to be a rather specific and atypical set of facts that may be characterized by a bit of "bad behavior" on both sides.

Google wanted to use Java.  It sought to license Java, but the way it wanted to use it didn't qualify for the open source license and it and Sun couldn't come to an agreement on a more "traditional" license.  Google hauled off and did it anyway, as Google is wont to do.

Oracle comes into the picture, and perhaps violating software industry norms, sued Google for stealing its code.  The code in question is entitled to the narrowest protection available under the copyright law, but Google's copying was sufficient to make the case of copyright infringement.

Now Google wants to make a bright-line rule that copying an "API" or "API description" is never, ever copyrightable.  

That is, I think, bad juju overall, even if it may be a "just result" in this case.  

Never say never.

You can bet your fur that if Google wins this, and a bright line rule is created that an "API" is never copyrightable, infringers are going to start either calling everything an API (admittedly perhaps far-fetched), or they are going to start arguing that their infringing software is more like an API than "other software," and that it should be subject to the never copyrightable rule just as if it was an API.  

While this ruling would be ostensibly confined to APIs, it will undoubtedly weaken protection for all software, across the board.

Cuidado, amigos.

[TwiceHorn 31,619]

11 minutes ago, immamac said:

I'm not sure that you understand the difference and nuance here. If google can't be eligible for usage of an OSS code base because of some caveat then it isn't OSS it's source available, which is completely different. Source available you can use, potentially modify it for your own purposes, but no one else can do that for you except the owner of the license. 

It's extremely problematic and every OSS is fucking copyrighted with it's license, the idea of copyleft and OSS is that even though it's copywritten and attributed to the author there are no commercial or otherwise implications from using it. 

It's the same reason AGPL and now the SSPL are problematic licenses. 

You are positioning this like the apache vs elastic license where there are 2 distinct versions that are licensed differently but share the codebase. That's not at all what the Oracle (or sun) license for Java is or was.

OpenJDK is not JavaSE or JavaEE but it's good enough now for people not to care. The problem is here:

This is from Google's defense team. The spec they built the API against WAS NOT open source and that's what the issue is. (even though now it has later been made FOSS under gpl)

That's the straight up definition of copyright infringement. The reason it's problematic is because the license change after the fact we are in truly uncharted waters. The fact that it's going to the supreme court is a good thing, but I cant really say that either decision is awesome for open source. If you can rip off copyrighted not shared documentation api as OSS that is pretty fucked up. At the same time if you can't use APIs in a FOSS way then...we stifle commercial innovation.

No what I mean is that ultimately, you are going to have to rely on the commercial reasonableness of the various parties not to do something greedy and stupid that's going to fuck up everything.

Just because "they can" doesn't mean "they will."  Some assholes like Oracle might, but it may be the end of them.

And, you are neglecting the fact that today and until the Supreme Court rules against Oracle, if it does, people have been free to assert copyright in an API or API description.  Just like any other software copyright case, it would be a tough one, and moreso because of the highly functional nature of APIs.  An outcome in favor of Oracle isn't going to change this.

Said succinctly, "they could" and mostly "they didn't" for commercial reasons rather than legal ones.

[bernorange 8,367]

12 minutes ago, TwiceHorn said:

...  If an "item" of software is necessary to carry out out a function (in the API case, cross-compatibility of software), and can only be done one way, by copying someone else's software (not the "functionaltity" but the actual words and syntax, structure, and organization, the "literal elements") then that indicates that the item of software is wholly functional, and employed or employs no creativity whatsoever in its authorship, and is not therefore either original or copyrightable.

In this case, a declaration header is like a dictionary that tells a C (or C++ or whatever language the declaration was designed for) compiler how to communicate with the implementation module.  Google did not copy Oracle's implementation module.  They created their own from scratch (and everyone's assumption and what little I read of the court summary you posted indicates) which is not a copy of Oracle's code.  They copied the declaration header which *is* necessarily the same thing for carrying out the function of cross compatibility.

My comment with respect to generating their own nomeclature and using aliases for Oracle's nomenclature is a bit of a cop out IMO.  The aliased header is still going to essentially contain the original header content albeit massaged a little and dressed up for lawyers to argue over.  It is akin to Google creating a declaration header that says:

function casa(x,y)     ;Google/Android function is named casa()
alias house = casa     ;Oracle/Java function is named house() - you can use either name with Android!

while the Oracle declaration header simply says:

function house(x,y)

 

12 minutes ago, TwiceHorn said:

... Now, let's change it up a bit.  Let's say you wrote your Hello World in C, but chose some other commands and syntax to do it, so that the source code literally looks very little like mine.  I'm too rusty to propose how you would do it, but I am pretty sure you could do it.  Again, no infringement.  This is the result of the narrow scope of protection accorded to computer programs in copyright law.

A further point.  If there was only one way to write hello world in C, as is likely the case in machine code for a given processor/kernel, then my hello world program in C would be uncopyrightable because I had no choice in how to write the code, so it is not original and not copyrightable.

You can always add bloat to code to make it more inefficient, but do the same thing.  The entire purpose of computer science is to maximize efficiency for an optimal solution.  But that's more an issue for the implementing code, not the declaration headers that are the issue at play with this case.  A declaration header either is or is not (Yoda approved).  It isn't the same thing as implementation code.

[TwiceHorn 31,619]

3 minutes ago, bernorange said:

function casa(x,y)     ;Google/Android function is named casa()
alias house = casa     ;Oracle/Java function is named house() - you can use either name with Android!

while the Oracle declaration header simply says:

function house(x,y)

You can always add bloat to code to make it more inefficient, but do the same thing.  The entire purpose of computer science is to maximize efficiency for an optimal solution.  But that's more an issue for the implementing code, not the declaration headers that are the issue at play with this case.  A declaration header either is or is not (Yoda approved).  It isn't the same thing as implementation code.

Well, the absurd reality is that Google should have done something akin to, if not exactly, what you state here. And they apparently admit that they could have done so and do not argue that it would have been burdensome or inefficient.  That would have been a perfectly adequate defense.

Instead, Google wound up with the extreme defense of "APIs are never copyrightable" instead of "we should be permitted to copy this code in this particular case for functional and efficiency reasons."

I am not arguing so much in favor of Oracle winning the copyright suit as against the notion that "APIs are never copyrightable."

Bright line rules that use terms like "never" are almost always bad news and come with huge unintended consequences.  They are pretty rare in the law for good reason.

[immamac 43,255]

52 minutes ago, TwiceHorn said:

 

Actually, in this context it is a perfect defense, subject to the below.  If an "item" of software is necessary to carry out out a function (in the API case, cross-compatibility of software), and can only be done one way, by copying someone else's software (not the "functionaltity" but the actual words and syntax, structure, and organization, the "literal elements") then that indicates that the item of software is wholly functional, and employed or employs no creativity whatsoever in its authorship, and is not therefore either original or copyrightable.

The scope of protection provided by copyright varies.  "Artistic works," where the author has complete freedom of choice in color, material, size, proportions and all the various elements that make up an artistic work such as a sculpture or painting, or a book or song, get the broadest scope of protection.  "Factual works" such as news articles get less protection, because in reporting factual stories there is a limited amount of choice available to the author:  she has to include who, what, when, and where, and those items are not "thought up" or chosen by the author.

Computer programs, as "functional" things, receive the absolute narrowest protection available under the copyright law.  Verbatim copying is mostly going to be necessary to prove infringement.  So, changing up minor things would not avoid infringement in an artistic work, but it absolutely will with a computer program.  You cannot prove copyright infringement in a computer program by relying on "non literal" elements like "it's overall kind of similar, they both have good beats, I could dance to them."  It is going to require note-for-note similarity, or better stated, identity.

That Google could have done it without verbatim copying is a bad sign for Google.

Let me give you a rudimentary example.  Let's say I can prove that I am the original author of  and own the copyright in "Hello World" in C.  Let's say you write a "Hello World" in Python.  They both do the exact same thing in printing "hello world" to a screen or output device.  But the source code doesn't look anything alike, although "symbolically" they are similar within the context of C and Python.

You do not infringe my copyright in Hello World in C, even if you had a copy of my code sitting on your desk while you wrote it up in Python.  I cannot rely on the functional or symbolic similarity ("non-literal elements") between the two programs to establish infringement.  I must have that literal similarity and just the appearance of the words hello and world in the source code is not going to do it, because those are necessary to achieve the function of printing "hello world" to an output device.

Now, let's change it up a bit.  Let's say you wrote your Hello World in C, but chose some other commands and syntax to do it, so that the source code literally looks very little like mine.  I'm too rusty to propose how you would do it, but I am pretty sure you could do it.  Again, no infringement.  This is the result of the narrow scope of protection accorded to computer programs in copyright law.

A further point.  If there was only one way to write hello world in C, as is likely the case in machine code for a given processor/kernel, then my hello world program in C would be uncopyrightable because I had no choice in how to write the code, so it is not original and not copyrightable.

 

This is technically incorrect. 

It would be like writing a specific way to display hello world through the same mechanism (echo or whatever) and building a way to trigger that in a very specific syntax that needs to be provided to trigger that. That is what an API is.

 

You can now build that interface however you want with whatever implementation you want. Your way is not open source and the docs are not widely distributed. Someone can't just do the same thing you are doing and offer it as a compatibility product now (oracles argument, and actually the way the law is interpreted in general right now). They can implement a brand new say to just do hello world displaying as it isn't patent protected (where patent law protections come in) Google says fuck that we can do anything we want cuz a bunch of people use that API and this method of using computers isn't patented intellectual property - which essentially means your copyright on any API ever would be invalid forever going forward and people can literally just rip off your proprietary software in a "clean room" no direct copying. 

The law is on the side of copyright because that's why the law exists to protect work. People choose to not copyright things Inna way that will prevent this behavior and allows for it intrinsically in the license (FOSS copyleft licensing). This is completely fucked for PROPRIETARY software though as it means you cant protect yourself from someone literally just building the same implemented interface and behavior and sell that or give it away for free. 

[bernorange 8,367]

1 hour ago, TwiceHorn said:

I had a thought that perhaps explains bernorange's potential objection and comment that "it's not software."  And maybe captainant's too.

In this case, Google itself doesn't "code" or write into any software the declaration statements published in its or Oracle's API. Rather it is the app developer that actually codes the API text into software when it needs or wants to.  So, in that sense, it's not Google that is "copying," but the app developer.  Whether the declaration statements and other material must appear in Android somewhere to enable the functionality of the API, I don't know, although it seems to me likely. ...

A long time ago, M$ encouraged developers writing software for Windows to modularize their code into executable libraries (DLLs - dynamic link libraries).  DLLs were (are) compiled code.  They are essentially a set of functions.  Any software can interface with a given DLL *if* the software knows how to talk to it.  The Windows operating system itself is comprised of a lot of DLLs.  The CreateWindowEx() page I referenced earlier is M$ technical documentation explaining the correct way to talk to the Windows DLL containing that function to call that function.

When M$ developed Windows, they developed a lot of DLLs that contain functions to create and manipulate "controls".  Controls are things like clickable buttons, drop down lists, boxes where end users can type text, etc.  While M$ included a lot of controls in Windows that any programmer can use (by invoking the appropriate M$ DLL using the correct format as described in the corresponding header declaration), they didn't create every possible control that programmers might like to incorporate into their user interfaces (GUIs).  So a cottage industry of 3rd party controls developed.

As a developer, I wanted to incorporate a spreadsheet/"grid" control into one of my applications.  Developing a robust grid control from scratch is a massive endeavor, so I opted to license one from a 3rd party developer.  The license included the DLL (implementing, compiled code) and the declaration header for the DLL.  The declaration header was written for use with C and C++.  I wasn't using C or C++ however, so I had to translate the header from C/C++ to the language I was using.  I did this (and it was a pain the ass, but not nearly as much as developing a control [implementation code] from scratch would have been).    My translated header was the key to using  the DLL with the language/compiler that I was using.  Without it, I could not call/invoke the functions within the DLL.  Did I violate the copyright on the C/C++ header?  I don't think so, but honestly, I'm not sure.

I ended up contacting the 3rd party company and giving them my translated copy of their declaration header in case any other programmers using the compiler I was using wanted to buy a license.  When I talked about the 3rd party's control on a programmer's forum (specific to the compiler I was using), I would mention to folks that I'd translated the header and given a copy to the company, so they should ask for it if they bought a license.

I posted this tl;dr experience so you might have a better technical understanding of a library (implementing code/Java runtime/Dalvik VM) and the declaration header (reference of the implementation code for a programming language compiler to talk to it).  If Google had developed the Dalvik VM (Android system) and told developers, "you have to create your own declaration headers, but it should be easy - it's just like Java!", well, ain't nobody got time for that.

[TwiceHorn 31,619]

27 minutes ago, immamac said:

This is technically incorrect. 

It would be like writing a specific way to display hello world through the same mechanism (echo or whatever) and building a way to trigger that in a very specific syntax that needs to be provided to trigger that. That is what an API is.

 

You can now build that interface however you want with whatever implementation you want. Your way is not open source and the docs are not widely distributed. Someone can't just do the same thing you are doing and offer it as a compatibility product now (oracles argument, and actually the way the law is interpreted in general right now). They can implement a brand new say to just do hello world displaying as it isn't patent protected (where patent law protections come in) Google says fuck that we can do anything we want cuz a bunch of people use that API and this method of using computers isn't patented intellectual property - which essentially means your copyright on any API ever would be invalid forever going forward and people can literally just rip off your proprietary software in a "clean room" no direct copying. 

The law is on the side of copyright because that's why the law exists to protect work. People choose to not copyright things Inna way that will prevent this behavior and allows for it intrinsically in the license (FOSS copyleft licensing). This is completely fucked for PROPRIETARY software though as it means you cant protect yourself from someone literally just building the same implemented interface and behavior and sell that or give it away for free. 

I'm not quite sure what you're saying here, or why my examples are technically incorrect.  Do you mean legally incorrect or "software" incorrect? You're bouncing back and forth between patent and copyright and I dunno.

A curious thing about licensing that I have observed over the years.  The ability to license anything presumes that you own some aspect of what it is you are licensing.  That ownership, in the software context, could include copyright, trade secret, or patent rights or any combination thereof.  

In most licensing negotiations, it is simply assumed by the parties that the licensor owns what it is attempting to license.  Except in the patent context, there is rarely a whole lot of back and forth over what it is that the licensor owns, it's just a good faith assumption that if push came to shove, the licensor could take legal action against a potential licensee who uses the technology at issue, but there's not a whole lot of "Show me your fucking copyright!"  And even in the patent context, the issue is not so much what the patent covers but what information beyond the patent, including and especially "know how" and associated information can the licensor provide and in turn what is that worth.

Every situation is a little different, though.

[TwiceHorn 31,619]

27 minutes ago, bernorange said:

A long time ago, M$ encouraged developers writing software for Windows to modularize their code into executable libraries (DLLs - dynamic link libraries).  DLLs were (are) compiled code.  They are essentially a set of functions.  Any software can interface with a given DLL *if* the software knows how to talk to it.  The Windows operating system itself is comprised of a lot of DLLs.  The CreateWindowEx() page I referenced earlier is M$ technical documentation explaining the correct way to talk to the Windows DLL containing that function to call that function.

When M$ developed Windows, they developed a lot of DLLs that contain functions to create and manipulate "controls".  Controls are things like clickable buttons, drop down lists, boxes where end users can type text, etc.  While M$ included a lot of controls in Windows that any programmer can use (by invoking the appropriate M$ DLL using the correct format as described in the corresponding header declaration), they didn't create every possible control that programmers might like to incorporate into their user interfaces (GUIs).  So a cottage industry of 3rd party controls developed.

As a developer, I wanted to incorporate a spreadsheet/"grid" control into one of my applications.  Developing a robust grid control from scratch is a massive endeavor, so I opted to license one from a 3rd party developer.  The license included the DLL (implementing, compiled code) and the declaration header for the DLL.  The declaration header was written for use with C and C++.  I wasn't using C or C++ however, so I had to translate the header from C/C++ to the language I was using.  I did this (and it was a pain the ass, but not nearly as much as developing a control [implementation code] from scratch would have been).    My translated header was the key to using  the DLL with the language/compiler that I was using.  Without it, I could not call/invoke the functions within the DLL.  Did I violate the copyright on the C/C++ header?  I don't think so, but honestly, I'm not sure.

I ended up contacting the 3rd party company and giving them my translated copy of their declaration header in case any other programmers using the compiler I was using wanted to buy a license.  When I talked about the 3rd party's control on a programmer's forum (specific to the compiler I was using), I would mention to folks that I'd translated the header and given a copy to the company, so they should ask for it if they bought a license.

I posted this tl;dr experience so you might have a better technical understanding of a library (implementing code/Java runtime/Dalvik VM) and the declaration header (reference of the implementation code for a programming language compiler to talk to it).  If Google had developed the Dalvik VM (Android system) and told developers, "you have to create your own declaration headers, but it should be easy - it's just like Java!", well, ain't nobody got time for that.

No you didn't violate the copyright because you were licensed.

But even if you were not licensed, the lack of similarity between the declaration headers in the "language you were using" versus the C/C++ headers would have absolved you of infringement.

Taking For Whom The Bell Tolls and translating it into Urdu infringes the copyright in the English-language work, despite the lack of literal similarity because that is the broad scope of copyright accorded to literary/artistic works.

Porting software from C to Visual Basic, while also a "translation," does not infringe a copyright because of the narrow scope of copyright accorded to computer programs.

Also, I believe that I understand the technicalities sufficiently to analyze this case from a copyright perspective.

I'm not sure any of you understand copyright law sufficiently to grok what I am saying about this case despite my efforts to explain it.  It's a very esoteric area.

Edited September 26, 2020 by TwiceHorn

[immamac 43,255]

Your technical example of what an API was incorrect I just modified your example to clarify the added commentary around the implications

[Amos Moses 795]

I can’t help but think that the Federal Circuit got this one right.  Which of course sets the case up nicely for a tortured Roberts opinion going in some unimagined direction.  Regardless, my hope is the industry sees the writing on the wall in that the end result seems to set up nicely for a good old fashioned FRAND solution.

[TwiceHorn 31,619]

27 minutes ago, immamac said:

Your technical example of what an API was incorrect I just modified your example to clarify the added commentary around the implications

I was not using the hello world thing to imitate or analogize to an API.  It was just an example of how copyright works for the general case of software.

Without a bright line rule against copyrighting APIs, an API is going to be difficult to prove copyrightability/infringement because much of what an API contains is dictated by external considerations:  the two software packages that it interfaces between.

But if you have the freedom/ability to rewrite the declaration statements, or other API material, even just a little bit and do not do so and instead copy it verbatim, you are likely to get in trouble if someone calls you on it.  And I think the bolded is a key consideration for how this affects the industry.

It is also becoming apparent to me that Google may have fucked up their defense pretty good.  Or, the trial judge, William Alsup, who seems again and again to be pretty far out of his depth on technical issues, may have misinterpreted things and given fucked up decisions that fucked up the whole thing.  Also, the appeal comes from two different jury decisions and the nature of jury decisions, "yes" or "no" answers to written questions, can create a big mess, too.

In either case, it seems that Google made some strange and very damaging admissions about the nature of the Java APIs.  That may be forcing them to take the extreme position that "an API is never copyrightable" because their other defenses failed.  Or it could be part of their long-term strategy of weakening IP protection for software.

I think based on what people have said here, that there should be good defenses to infringement that do not require the extreme position that an API is never copyrightable.  Namely: 

• an API is a highly functional piece of software with limited ability to change declaration statements and syntax, structure, and organization (SSO) while maintaining compatibility with the software packages it interfaces between
• to change the declaration statements and SSO from Java's API would have been burdensome and introduced inefficiency into the API
• as a result of the above two, what little similarity there is between the Java and Google APIs is dictated by the functional requirements of the API and the amount and nature of copying done is insufficient to prove copyright infringement

For whatever reasons, Google lost on this defense if it made it, even, and is forced to resort to advocating the bright line rule, to which I am opposed.

Edited September 26, 2020 by TwiceHorn

[TwiceHorn 31,619]

3 minutes ago, Amos Moses said:

I can’t help but think that the Federal Circuit got this one right.  Which of course sets the case up nicely for a tortured Roberts opinion going in some unimagined direction.  Regardless, my hope is the industry sees the writing on the wall in that the end result seems to set up nicely for a good old fashioned FRAND solution.

Yeah if Oracle or anyone else gets shitty about this, that would seem to be the solution.

Open Source licenses are kind of a crude facsimile of a FRAND thing, with FRAND being zero coupled with other conditions.  Or maybe it's analogous to the paid-up, royalty-free total portfolio cross-license.

Anyway, beyond the scope of this discussion.

[bernorange 8,367]

1 minute ago, TwiceHorn said:

... I think based on what people have said here, that there should be good defenses to infringement that do not require the extreme position that an API is never copyrightable.  Namely: 

• an API is a highly functional piece of software with limited ability to change declaration statements and syntax, structure, and organization (SSO) while maintaining compatibility with the software packages it interfaces between
• to change the declaration statements and SSO from Java's API would have been burdensome and introduced inefficiency into the API

I'd like to see the legal definition for "API."  The way you are using it is confusing (likely because of my background).  I take your use of "API" to mean both the declaration header and implementing code module as two parts of a library package (not fondled by South Austin's mom).  For me, a layman with a background in programming, an API is a design schema.  It's not code at all (though a declaration header is concise expression of it).

Your bullet points seem to confuse the issue of using a library package vs. (re)creating one.  In my tl;dr post above, I related how I translated a declaration header from C/C++ to work with a different compiler.  The vendor's original declaration header is specific to their implementation module and the C/C++ languages.  But the vendor could update their implementation module and declaration header and change anything they wanted.  This in fact, happened with the grid control that I licensed.  When they released a new version with new features and such, they did make substantive changes to existing code.  I had to rewrite the translated declaration header for my compiler.  But the point is, the vendor can change their own code pretty much without limitation.  The limitation exists on the party that is trying to develop a cross platform compatible "analogy" of the solution.  That party is limited to the existing/published design.  Their implementing code can be their own (maybe more efficient/better, maybe worse), but the header declaration is necessarily the same to effect cross platform compatibility.

Changing the declaration statements would not have introduced inefficiency - it would have negated cross platform compatibility.  What we were talking about early in this thread was differences in the implementation code (which really isn't an issue with this suit as I understand it).

[atomheartbevo 89,856]

9 hours ago, TwiceHorn said:

No what I mean is that ultimately, you are going to have to rely on the commercial reasonableness of the various parties not to do something greedy and stupid that's going to fuck up everything.

There's some judges in East Texas that will be more than glad to help some of those companies do really greedy and stupid shit that could fuck up everything.

[atomheartbevo 89,856]

9 hours ago, bernorange said:

A long time ago, M$ encouraged developers writing software for Windows

Do you use Linux?

[TwiceHorn 31,619]

I'd like to see the legal definition for "API."  The way you are using it is confusing (likely because of my background).  I take your use of "API" to mean both the declaration header and implementing code module as two parts of a library package (not fondled by South Austin's mom).  For me, a layman with a background in programming, an API is a design schema.  It's not code at all (though a declaration header is concise expression of it).

There is no legal definition of API, which is going to be one of the problems with a bright line rule against copyrighting one.  I see your point that it is a "Schema" and tried to explain why that was still a copyright problem in post 157.  It appears that in addition to whatever programming Google needed to do to incorporate the Java API into Android (unless I am mistaken, something in Android is going to have to respond to the declaration statement and invoke an instance and pass data to the Dalvik VM for the API to operate), which probably involved copying some or all of the schema.  Google also apparently copied the API description documentation, which was copyrighted along with the code per se.

Also, a key point that you may be missing in copyright:  the function is not protected except to the extent that it results from the compiled and executed source code.  Only source code is compared for textual similarity, along with "syntax, structure, and organization."  You just don't consider whether it works the same or not.

Your bullet points seem to confuse the issue of using a library package vs. (re)creating one.  In my tl;dr post above, I related how I translated a declaration header from C/C++ to work with a different compiler.  The vendor's original declaration header is specific to their implementation module and the C/C++ languages.  But the vendor could update their implementation module and declaration header and change anything they wanted.  This in fact, happened with the grid control that I licensed.  When they released a new version with new features and such, they did make substantive changes to existing code.  I had to rewrite the translated declaration header for my compiler.  But the point is, the vendor can change their own code pretty much without limitation.  The limitation exists on the party that is trying to develop a cross platform compatible "analogy" of the solution.  That party is limited to the existing/published design.  Their implementing code can be their own (maybe more efficient/better, maybe worse), but the header declaration is necessarily the same to effect cross platform compatibility.

My bullet points are almost entirely legal in nature and apply only to analysis of software.  Nothing "API" specific.  You could substitute "Linux" or "Windows" or "MacOS, or "ProEngineer" or "AutoCAD" for API in them.

The alternative to my bullet points is, and what Google advocates, is:  an API is not copyrightable, without considering any aspect of the API itself, or how or why it was copied.

 With respect to the bold/italic, it has not been made clear until that statement, so if that is accurate, that is problematic for a piece of software.  Any piece of software.  If there is only one set of source code to accomplish any function in the software, whether it is interfacing with another software or solving the quadratic equation, then in 99% of cases, if not all of them, copying the portion that performs that function will not result in infringement.

Changing the declaration statements would not have introduced inefficiency - it would have negated cross platform compatibility.  What we were talking about early in this thread was differences in the implementation code (which really isn't an issue with this suit as I understand it).

Ok, now I have had another epiphany.  Google wrote its own implementation code to run not in Java Java, but a bastard Java, the Dalvik VM.  But it used the Java Java API schema to interface Android with the bastard Java Dalvik VM.

Therefore, it had the option of making a similar, but not verbatim copy of, API/description/schema because it didn't need to work with Java Java, but rather its own bastard Java.  That changes up the game, again, in a bit of a weird way.

In the ordinary case, an API is going to be used between two software packages and is going to be authored by one of the owners of the software packages to make its software more useful and more commercially adopted.  In that sense, there's no commercial motivation to license the API separately from the underlying software package, whether the API is copyrightable or not.

Here, though, Google owned both software packages:  Android and the Dalvik VM.  It had COMPLETE CONTROL of the source code of both of them.  Yet it copied an API/description/schema from a third party program, Sun/Oracle Java, to interface between them.  It wasn't functionally necessary to do that, it had complete freedom to redo the API/description/schema.  It could have made it close to the Java one, so it was still familiar to Java programmers, but not a verbatim copy.  Had it done so, we wouldn't be here.

If the API/description/schema were being used to interface between Android and Sun/Oracle Java, what I call Java Java, there would be less of a leg for Oracle to stand on because it would, in fact be necessary to copy the API if you want/need compatibility with Sun/Oracle Java.

As pointed out above, this is a very factually strange case.  Which to me indicates even more that it is a bad basis for a bright line rule that an API, however defined, should be treated any differently than any other software.

Bad cases make bad law.  And, never say never.

I will go ahead and say that the Supreme Court generally doesn't like bright line rules, either, so they are probably going to come out more for Oracle than Google, but they may take some swipes at the infringement question.

Edited September 28, 2020 by TwiceHorn

[bernorange 8,367]

36 minutes ago, TwiceHorn said:

...  Ok, now I have had another epiphany.  Google wrote its own implementation code to run not in Java Java, but a bastard Java, the Dalvik VM.  But it used the Java Java API schema to interface Android with the bastard Java Dalvik VM. ...

It's my understanding that Google's Dalvik VM *is* their clean room built implementation code.  Their goal was to build a Java compatible runtime simulator/engine into the Android system (so programmers could write and use Java language programs on their Android operating system).

[TwiceHorn 31,619]

1 hour ago, bernorange said:

It's my understanding that Google's Dalvik VM *is* their clean room built implementation code.  Their goal was to build a Java compatible runtime simulator/engine into the Android system (so programmers could write and use Java language programs on their Android operating system).

Right, but it would be typical to write your own API for your own software, even if that software is imitative or semi-compatible with a third party's.

It's a little bit kooky, from a factual standpoint, to copy a third party's API not for use with the third party's software, but with your own.  It is a little bit "appropriative" or thefty.  Is it thefty enough to be addressed by the copyright law?  I don't know.

Whereas, normally, an API is published by a proprietor for use with it's own software and is the ONLY way to interface with that software.  Copying that is not appropriative, that's doing what you have to do to achieve that function and should be prohibited, if at all, by patent rights, not by copyright.

 

Edited September 28, 2020 by TwiceHorn

[TwiceHorn 31,619]

Stated real simply.  In the usual case of "copying" of an "API," the copier is going to be able to say, "hey, if I am going to use your software with mine or someone elses, I have to use your API."  And most of the time that's going to provide a near-perfect defense to copyright infringement.

In this particular case, it's one party saying "I copied your API to use my software with  . . . my software, which is outwardly an imitation of your software."  I have no doubt that Google was candid that it wasn't actually Java, so there's not the element of deception, but there is an element of appropriation here that isn't present in the usual API case. And it wasn't absolutely necessary to use Java's API verbatim. It could have been changed a bit and avoid the whole thing.  All of these facts make it different from the usual API case, and the the immediately preceding two sentences makes it waaaay different.

Because this case presents a deviation from the usual case, it is a terrible vehicle for a bright-line rule and even demonstrates why you don't want one.  Google maybe should have won it even on the weird facts, but it didn't.

Nonetheless, none of this changes my conviction against a bright line rule against copyrighting APIs.

Edited September 28, 2020 by TwiceHorn

[bernorange 8,367]

6 hours ago, TwiceHorn said:

...

In this particular case, it's one party saying "I copied your API to use my software with  . . . my software, which is outwardly an imitation of your software."  I have no doubt that Google was candid that it wasn't actually Java, so there's not the element of deception, but there is an element of appropriation here that isn't present in the usual API case. And it wasn't absolutely necessary to use Java's API verbatim. It could have been changed a bit and avoid the whole thing.  ...

Your last two posts are in line with my understanding of the situation.  However, your above comment is really ironic/funnny when you consider that Google tried to license Java from Oracle, but Oracle's main objection to a deal was Google's insistence on the right to change it a bit.  For a licensing deal, Oracle wanted the Google implementation to be 100% exact.  I haven't delved into the details, but I suspect that the Dalvik VM did in fact change quite a bit of the overall API from a full Java copy.  That's why the lawsuit alleges that Google only copied part of the API - not the entire thing.

[TwiceHorn 31,619]

1 hour ago, bernorange said:

Your last two posts are in line with my understanding of the situation.  However, your above comment is really ironic/funnny when you consider that Google tried to license Java from Oracle, but Oracle's main objection to a deal was Google's insistence on the right to change it a bit.  For a licensing deal, Oracle wanted the Google implementation to be 100% exact.  I haven't delved into the details, but I suspect that the Dalvik VM did in fact change quite a bit of the overall API from a full Java copy.  That's why the lawsuit alleges that Google only copied part of the API - not the entire thing.

Thanks for staying engaged with me and clarifying the necessity of copying of an API in the general case.

It took me a minute to be able to articulate what was hitting me weird about this case.

Apparently it was actually Sun that balked at the license, not Oracle, but that seems to be consistent with what the court opinions say.

And apparently Google has 168 API "packages," but only 37 were copied, which is strange. ““Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.” ” Oracle Am., Inc. v. Google Inc., 750 F.3d 1339, 1350 (Fed. Cir. 2014).  

Why those 37?  And why not just make them kind of similar, but change it just a little, when the other 131 are not subject to copying allegations?

Another oddity.  The Federal Circuit decided the infringement/copyrightablity issue six years ago.  Google petitioned for cert then and it was denied.  I'm kind of interested why the Supreme Court would grant cert on it now? 

The fair use part of it, which I am almost positive is a loser for google, is the part that stayed a live issue since 2014, but the infringement/copyrightablity question has been settled the whole time.  It would not surprise me a bit if the Supreme Court said cert was improvidently granted on the broad API question and ruled only on the fair use.

Edited September 28, 2020 by TwiceHorn

[bernorange 8,367]

Those 37 were "core".  They were the important one for cross platform compatibility.  I don't know real numbers, but it is essentially the 80/20 rule.  That 20% of the overall Java api enables 80% of existing java code to work (on Dalvik VM).  Adjust %s as needed, but that is the gist of it.

[TwiceHorn 31,619]

1 minute ago, bernorange said:

Those 37 were "core".  They were the important one for cross platform compatibility.  I don't know real numbers, but it is essentially the 80/20 rule.  That 20% of the overall Java api enables 80% of existing java code to work (on Dalvik VM).  Adjust %s as needed, but that is the gist of it.

I believe the opinions reflect that "core" functionality. Not sure how/whether this really affects the analysis.

[bernorange 8,367]

Oh, I wasn't trying to offer legal analysis.  I was answering your question as to why Google copied those 37 exactly.  It was necessary for an acceptable threshold of cross compatibility.

[TwiceHorn 31,619]

A general observation about copyright.  

What a copyright "covers" is dependent not only on the material copyrighted, but what allegedly infringing material is copied from it and how.  That is, the validity and scope of protection of the copyright is closely tied to the infringement question.

That is true to some degree in trademark infringement ("strength" of the mark will govern what degree of imitation is infringement) and somewhat less true of patent infringement (for the most part, the scope of the patent is determined independently of the infringement question).

It makes things a little extra confusing.

[Captainant 27,861]

Twice, if you have a spare moment you should read this article about Judge Alsup and how he informed himself on this case. It's got some good anecdotes about the case and on the plaintiff and defendant - some excerpts below:

Quote

In order to be compatible with Java, certain calls to certain APIs should look about the same. For example, the method that finds that maximum value in a set of numbers is quite sensibly named java.lang.Math.max. Oracle argued that Google could have just called it java.lang.Arith.larger. Google argued that the Java APIs were similar to the QWERTY keyboard layout. Sure, a keyboard could be organized any other way, but keyboard manufacturers keep making QWERTY keyboards, because people are used to that setup.

Languages build on top of other languages, and part of that means that their APIs look similar. The Java regular expression API is a reimplementation of Perl 5 and the Java string formatting API is a reimplementation from C. This is one of the reasons why programmers get up in arms about Oracle v. Google; it just doesn’t make any sense to police Google for something that everyone else has been doing for forever. There is a general consensus among software developers that Oracle was wrong: that APIs are meant to be used, that to restrict their usage would subvert their purpose.

Indeed, even Oracle had a hard time being consistent about its own position. In 2015, a corporate witness for Oracle said in a deposition that the Java APIs and the Java language — which is free to use — were “inseparable,” only to backtrack after his lunch break while sweating profusely.

 

Quote

“It was the kind of thing I had done many times myself in QuickBASIC,” he says, five years after that hearing. (The judge uses Microsoft’s QuickBASIC, which is an integrated development environment and compiler for BASIC, to program in). “And if you had given me that problem in QuickBASIC, I was certain I could go back within an hour and I would have a working QuickBASIC model of that.”

When we spoke, the judge was careful when talking about Oracle v. Google, since a second appeal is still pending at the Federal Circuit. But it seemed like he was still irritated with Oracle’s attempts to cast the copied lines of rangeCheck as a “big deal.” The coder in him may have even felt a little sorry for the beleaguered author of rangeCheck. The incident bothered Alsup so much that he spent an entire section of his opinion on it. “Oracle has made much of nine lines of code that crept into both Android and Java. This circumstance is so innocuous and overblown by Oracle that the actual facts, as found herein by the judge, will be set forth below for the benefit of the court of appeals.” (The nine lines of code never came up again in the case.)

Alsup’s 2013 opinion in Oracle v. Google is, as Grimmelmann says, “the most detailed, most difficult, most nuanced engagement” that the judiciary has ever had with software copyright. He teaches Oracle v. Google to his own IP class. “It’s a framing of this is how Java works, this is what the different elements of source code are… it’s not just judging the case before him. It’s a piece of writing that’s pedagogical.”

I haven't taken the time to read his opinion, but I will - I think it'll help to frame these technical issues in a way that will be more your language than mine Twice lol

[TwiceHorn 31,619]

6 minutes ago, bernorange said:

Oh, I wasn't trying to offer legal analysis.  I was answering your question as to why Google copied those 37 exactly.  It was necessary for an acceptable threshold of cross compatibility.

I understood.  Mostly thinking out loud about how that might affect the analysis of infringement/copyrightability.

[Captainant 27,861]

Found the decision and judge's opinion - it's very accurate technically and worth a read. I'll post the first few paragraphs below

Quote

All agree that everyone was and remains free to program in the Java language itself. All agree that Google was free to use the Java language to write its own API. While Google took care to provide fresh line-by-line implementations (the 97 percent), it generally replicated the overall name organization and functionality of 37 packages in the Java API (the three percent). The main issue addressed herein is whether this violated the Copyright Act and more fundamentally whether the replicated elements were copyrightable in the first place.

This leads to the first holding central to this order and it concerns the method level. The reader will remember that a method is like a subroutine and over six thousand are in play in this proceeding. As long as the specific code written to implement a method is different, anyone is free under the Copyright Act to write his or her own method to carry out exactly the same function or specification of any and all methods used in the Java API. Contrary to Oracle, copyright law does not confer ownership over any and all ways to implement a function or specification, no matter how creative the copyrighted implementation or specification may be. The Act confers ownership only over the specific way in which the author wrote out his version. Others are free to write their own implementation to accomplish the identical function, for, importantly, ideas, concepts and functions cannot be monopolized by copyright.

To return to our example, one method in the Java API carries out the function of comparing two numbers and returning the greater. Google — and everyone else in the world — was and remains free to write its own code to carry out the identical function so long as the implementing code in the method body is different from the copyrighted implementation. This is a simple example, but even if a method resembles higher mathematics, everyone is still free to try their hand at writing a different implementation, meaning that they are free to use the same inputs to derive the same outputs (while throwing the same exceptions) so long as the implementation in between is their own. The House Report, quoted above, stated in 1976 that "the actual processes or methods embodied in the program are not within the scope of the copyright law." H.R. REP.

Much of Oracle's evidence at trial went to show that the design of methods in an API was a creative endeavor. Of course, that is true. Inventing a new method to deliver a new output can be creative, even inventive, including the choices of inputs needed and outputs returned. The same is true for classes. But such inventions — at the concept and functionality level — are protectable only under the Patent Act. The Patent and Trademark Office examines such inventions for validity and if the patent is allowed, it lasts for twenty years. Based on a single implementation, Oracle would bypass this entire patent scheme and claim ownership over any and all ways to carry out methods for 95 years — without any vetting by the Copyright Office of the type required for patents. This order holds that, under the Copyright Act, no matter how creative or imaginative a Java method specification may be, the entire world is entitled to use the same method specification (inputs, outputs, parameters) so long as the line-by-line implementations are different. To repeat the Second Circuit's phrasing, "there might be a myriad of ways in which a programmer may ... express the idea embodied in a given subroutine." Computer Associates, 982 F.2d at 708. The method specification is the idea. The method implementation is the expression. No one may monopolize the idea.8

To carry out any given function, the method specification as set forth in the declaration must be identical under the Java rules (save only for the choices of argument names). Any other declaration would carry out some other function. The declaration requires precision. Significantly, when there is only one way to write something, the merger doctrine bars anyone from claiming exclusive copyright ownership of that expression. Therefore, there can be no copyright violation in using the identical declarations. Nor can there be any copyright violation due to the name given to the method (or to the arguments), for under the law, names and short phrases cannot be copyrighted.

It's effectively summed up by these sentences: "The method specification [the API] is the idea. The method implementation is the expression." 

Edited September 28, 2020 by Captainant

[TwiceHorn 31,619]

22 minutes ago, Captainant said:

Found the decision and judge's opinion - it's very accurate technically and worth a read. I'll post the first few paragraphs below

It's effectively summed up by these sentences: "The method specification [the API] is the idea. The method implementation is the expression." 

In the ordinary case of the API, that is true.  I agree that 99/100, copying of an API, even verbatim, should not constitute copyright infringement because it is a functional necessity.  But you can't create from that a bright line rule that an API is never copyrightable.  It needs to be 100/100, or better yet 1,000,000/1,000,000.

But when the API is used not with the API author's software, but a third party's software (not Sun/Oracle Java, but Google's Dalvik VM) that changes things quite a bit from the usual case.

As stated above, because Google wasn't using Sun/Oracle Java, but instead an "implementation" of Java written wholly from scratch and "clean roomed," it had complete freedom not to copy Sun/Oracle's API, instead just making it sufficiently similar to be familiar.  Instead it copied it.  These things are implicit in the Federal Circuit's opinion.

Another thing from reading that article:  Google's defense seemed to be focused on whether the elements of the API were copyrightable rather than whether the copying they did constituted infringement.  Subtle but important distinction, given the blended nature of copyrightability and infringement.

I think they would have been better off arguing in terms of "there's no infringement despite the copying" rather than "what we copied is not copyrightable."  And Alsup would have been better off framing his opinion in those terms.

Edited September 28, 2020 by TwiceHorn

[Captainant 27,861]

4 minutes ago, TwiceHorn said:

As stated above, because Google wasn't using Sun/Oracle Java, but instead an "implementation" of Java written wholly from scratch and "clean roomed," it had complete freedom not to copy Sun/Oracle's API, instead just making it sufficiently similar to be familiar.  Instead it copied it.

Google did not copy Sun/Oracle's API implementation - they copied the API specification. 

[TwiceHorn 31,619]

Reiterating.  This is such a factually oddball case that even a ruling in favor of Oracle will not create any broad precedent that APIs are infringed when used as intended.  It is going to be confined to its unusual facts.

[TwiceHorn 31,619]

2 minutes ago, Captainant said:

Google did not copy Sun/Oracle's API implementation - they copied the API specification. 

Doesn't matter.  It could have changed up the specification and didn't.

[Captainant 27,861]

4 minutes ago, TwiceHorn said:

Doesn't matter.  It could have changed up the specification and didn't.

Copying the exact specification is necessary and unavoidable to ensure cross-compatibility with already written Java code. People with pre-existing projects simply will not use a new platform if it requires them to change the signature of EVERY function call. The functional outcome of that thinking is that Oracle would indeed own the right to the very idea of that functionality - not just their implementation.

EDIT: for fucks sake, I highlight and bolded the relevant portion from the opinion authored by the judge. Twice, you're really not making an effort to even acknowledge or consider anyone's opposing opinion on this.

EDIT 2: here it is so it's not buried in a quote block:

"To carry out any given function, the method specification as set forth in the declaration must be identical under the Java rules (save only for the choices of argument names). Any other declaration would carry out some other function. The declaration requires precision. Significantly, when there is only one way to write something, the merger doctrine bars anyone from claiming exclusive copyright ownership of that expression. Therefore, there can be no copyright violation in using the identical declarations. Nor can there be any copyright violation due to the name given to the method (or to the arguments), for under the law, names and short phrases cannot be copyrighted."

Edited September 28, 2020 by Captainant

[bernorange 8,367]

From what I've read, Judge Alsup got it right the first time.

[TwiceHorn 31,619]

11 minutes ago, Captainant said:

Copying the exact specification is necessary and unavoidable to ensure cross-compatibility with already written Java code. People with pre-existing projects simply will not use a new platform if it requires them to change the signature of EVERY function call. The functional outcome of that thinking is that Oracle would indeed own the right to the very idea of that functionality - not just their implementation.

It would be if it were using Java.

But since they weren't using Java, but their own warez, with 131 different, ie not copied, API packages, it's a different case.

This is NOT A GOOD CASE FOR THE GENERAL PROPOSITION THAT COPYING AN API/API DESCRIPTION IS OR IS NOT A COPYRIGHT INFRINGEMENT.

People are trying to generalize something from the facts of this case that you can't really generalize from because they are weird.

And, there is considerable doubt about the wisdom of GOOGLE's proposed bright line rule that is a question completely independent of the facts of this case.

Google might should have won this case, but at this point that is irrelevant.  The case is at the Supreme Court on a broad general rule that I think would be a policy mistake.  The issue is beyond whether Google should have won.

Edited September 28, 2020 by TwiceHorn

[Captainant 27,861]

7 minutes ago, TwiceHorn said:

It would be if it were using Java.

But since they weren't using Java, but their own warez, with 131 different API packages, it's a different case.

This is NOT A GOOD CASE FOR THE GENERAL PROPOSITION THAT COPYING AN API/API DESCRIPTION IS OR IS NOT A COPYRIGHT INFRINGEMENT.

Your argument is circular - you are saying that the only way to avoid violation of Oracle's (farcical/nonexistent) copyright for API syntax for Java is to write it in Java.

The functional outcome of your thinking is that Oracle now owns the exclusive right to run any code written in java - because you're not allowed to write any compatibility code. Even with a compatibility layer those same API and method/class definitions would need to exist because they are a functional requirement for execution - not solely a creative aspect.

Edited September 28, 2020 by Captainant

[TwiceHorn 31,619]

13 minutes ago, Captainant said:

Your argument is circular - you are saying that the only way to avoid violation of Oracle's (farcical/nonexistent) copyright for API syntax for Java is to write it in Java.

The functional outcome of your thinking is that Oracle now owns the exclusive right to run any code written in java - because you're not allowed to write any compatibility code. Even with a compatibility layer those same API and method/class definitions would need to exist because they are a functional requirement for execution - not solely a creative aspect.

It's not really circular.

An API is written by a software proprietor for cross-compatiblity with software X.  Is is the X API.

Any use/copying of the X API for compatibility with X is not going to constitute copyright infringement.  It is a functional necessity or requirement of interfacing X with other software.

But if the proprietor of Y software copies the X API to make Y cross compatible, that is a different deal.  It is not a functional necessity.  It is purely optional choice by the proprietor of Y.

It is the functional necessity that makes the copying of X API not infringement (I am characterizing it this way to avoid the issue of not copyrightable).  When the functional necessity goes, so does the defense to infringement.

The fact that software Y is imitative of software X adds a layer of weirdness to the whole thing.

As this case stands, with Oracle having won, it is an unusual case that has a fact pattern that seems highly unlikely to ever be repeated.  It's a weird little one-off.

Edited September 28, 2020 by TwiceHorn

[Captainant 27,861]

1 minute ago, TwiceHorn said:

Not what I am saying.

An API is written by a software proprietor for cross-compatiblity with software X.  Is is the X API.

Any use/copying of the X API with X is not going to constitute copyright infringement.  It is a functional necessity or requirement of interfacing X with other software.

But if the proprietor of Y software copies the X API to make Y cross compatible, that is a different deal.  It is not a functional necessity.  It is purely optional choice by the proprietor of Y.

It is the functional necessity that makes the copying of X API not infringement (I am characterizing it this way to avoid the issue of not copyrightable).  When the functional necessity goes, so does the defense to infringement.

Software X is NOT the API. The API is a declarative interface to the functionality of software X.

You are consistently making this fallacious inference in your logic. Stop.

[TwiceHorn 31,619]

28 minutes ago, Captainant said:

Copying the exact specification is necessary and unavoidable to ensure cross-compatibility with already written Java code. People with pre-existing projects simply will not use a new platform if it requires them to change the signature of EVERY function call. The functional outcome of that thinking is that Oracle would indeed own the right to the very idea of that functionality - not just their implementation.

EDIT: for fucks sake, I highlight and bolded the relevant portion from the opinion authored by the judge. Twice, you're really not making an effort to even acknowledge or consider anyone's opposing opinion on this.

EDIT 2: here it is so it's not buried in a quote block:

"To carry out any given function, the method specification as set forth in the declaration must be identical under the Java rules (save only for the choices of argument names). Any other declaration would carry out some other function. The declaration requires precision. Significantly, when there is only one way to write something, the merger doctrine bars anyone from claiming exclusive copyright ownership of that expression. Therefore, there can be no copyright violation in using the identical declarations. Nor can there be any copyright violation due to the name given to the method (or to the arguments), for under the law, names and short phrases cannot be copyrighted."

Yes I am.

And, I acknowledge the usual purpose of an API.

I have said it a dozen times on this thread:  IN THE USUAL CASE OF COPYING OF AN API, THERE WILL BE NO COPYRIGHT INFRINGEMENT.

THIS IS NOT THE USUAL CASE.

 

Edited September 28, 2020 by TwiceHorn

[TwiceHorn 31,619]

5 minutes ago, Captainant said:

Software X is NOT the API. The API is a declarative interface to the functionality of software X.

You are consistently making this fallacious inference in your logic. Stop.

Goddammit.  That's what I said.

X API is associated with software X.  It is a functional necessity for compatiblity with software X.

When you copy X API for compatiblity with software Y, that is not a functional necessity.  It is a choice.  It is a necessity to make software Y semi-compatible with software X, but it is not an absolute functional necessity.