SCOTUS 2023: Rice pilaf from Louisiana...is that like an ISIS video?

The Something Awful Forums > Discussion > Debate & Discussion > SCOTUS 2023: Rice pilaf from Louisiana...is that like an ISIS video?

«‹›839 »

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

The discussion in that section is to explain why APIs survive section 102(b) of title 17.

quote:

(b) In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

This is in place to help separate different types of IP. It's a statutory tool to remove copyright from things that should be patented or otherwise. This section of the opinion is just explaining why the copyright in question does not fail the functionality test. The part he is quoting is just the appellate court listing facts from the copyrightabilty decision. They are merely reciting findings of fact from the previous decision to explain why the functionality does not defeat its copyright. The basic premise is there is protectable expression in the specific way things are organized, even if there is no copyrightability of the internal parts themselves.

# ? May 15, 2016 20:56

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 15:29

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

Stickman posted:

Yep, just read the district court decision, and the appeals decision left out the following sentences which reads

The lower court was wrong on that, though, which is why they don't state it. Google could have made an api that was functionally identical without directly copying.

# ? May 15, 2016 20:57

Jarmak: Jan 24, 2005

Space Gopher posted:

You have still failed to give any hints about how this can be done. You won't be able to, because what you're suggesting is nonsense.

Clean room reverse engineering is accomplished by having an outside team break the system to be reverse engineered down into a specification of functional pieces with defined inputs and outputs. That spec - which is a description of the API - is passed into the clean room, where it is implemented by developers who have never seen the original implementation before. The developers in the clean room know the API, but nothing else. When those clean room developers produce an implementation, it will be quite similar to the copyrighted implementation, because they're doing the same things, and in programming there's often only one obvious and sensible way to handle something. But, it's also not going to be perfectly identical, because there are plenty of minor details of style, 50/50 decisions that will split one way or another in two independent implementations, and so on.

If the reimplementation wasn't done in a clean room, it'd be easy for the entity who holds the rights to the original implementation to say, "well, that's so close to mine, you probably just tweaked a few variable names and other minor details, this is obviously a derivative work." The clean room proves that the new implementation was not derived from the originally copyrighted version - no derivation, no copyright infringement. But, we take it as a given in this scenario that the clean room implementation is not perfectly identical, right down to stylistic choices like variable names. If the clean room implementation and the original implementation were perfectly identical, it'd be pretty obvious that the "clean room" process was actually a fake, and it would provide no protection.

There is no equivalent for the system of organization in an API. If your clean room API isn't organized in a bit-for-bit identical fashion, it's not compatible with the original, which was the whole point of the exercise to begin with. If your clean room API is organized in a bit-for-bit identical fashion, nobody's going to believe that your clean room just so happened to independently make every single stylistic choice and settle every little organizational debate exactly as the original developers did.

It is fundamentally impossible to come up with a convincing clean-room "reimplementation" of an API.

(of course, this still has no bearing on whether APIs are actually copyrightable or not! It's just nonsense to claim that there was some kind of magical "right way" for Google to dodge this bullet. The whole reason this is a major victory for Oracle is that it lets them control any and all implementations of the Java API, whether they're done in a clean room or by copy-pasting their proprietary code)

The clean room doesn't work if some third party or parties give you every detail of what you're "reimplementing."

If you scrape other people's code that references the Java API, it contains a description of how Sun/Oracle has organized the Java API. Scrape on a wide scale (say, every Java project on Github with appropriate licenses, which would be a medium-sized hobby project or utterly trivial at Google's scale), and you've got a complete description with no creative work specific to the API organization itself. A few more lines of code could spit out lines that are identical to Oracle's original package, interface, and class definitions. What you describe adds a meaningless layer of automated indirection, and if you start with the assumption that the organization of an API is copyrightable, then your methods are just creating a derivative work.

What your missing here is that (if I understand correctly) it theoretically doesn't matter if the clean room code is 100% identical, your complaint regarding "who's going to believe that/ how will we ever know when if it has to be exactly the same" might be something the court has to address in the future but in this Google admitted to copying it so there was no need.

Tiler Kiwi posted:

I mean if people are going to be arguing based on morality rather than legality, does it really matter, morally speaking, if people worked really super hard on something or not? It seems like it would benefit everyone more in the end if the whole bit of clean room theater could be done away with.

Yes, morally because you should't be able to steal other people's work and resources to profit off of it, and societal because it discourages people from spending time and money developing new things if other people can just sit back and poach it.

My read of the decision is "nothing can stop you from using your own time and effort to make something identical, but you can't just sit back and wait for someone else to do it then hit ctrl+c"

# ? May 15, 2016 21:22

Stickman: Feb 1, 2004

Kobayashi posted:

If I understand properly, and I may not, it's OK to lock some random programmers in a room, point them at https://docs.oracle.com/javase/7/docs/api/, and tell them to create Google Java. It's not OK for them to go to http://openjdk.java.net and look at the source code or poach Sun engineers to speed things up. It might also be necessary to tell the team to make sure that they also list all the classes and methods in the Java files in reverse-alphabetical order or something. Idk though, am I close?

Nope, my understanding is that this ruling specifically makes the https://docs.oracle.com/javase/7/docs/api/, off limits for clean room design, because it embodies the Structure, Sequence, and Organization of the API, which is protected under copyright law. That's why Kalman and Mr. Nice! are arguing that they should instead scrape the specification from existing Java code (though it's not clear to me how this allows you to "independently develop" the SSO of the Java APIs, since they also embody the SSO of the API, and the end result will be exactly the same as the SSO in the public specification). This is how reimplementation has been done up to this point (see, for example, url=https://www.winehq.org/docs/winedev-guide/api-docs]Wine's clean room guidelines[/url]), but because the decision makes the SSO itself subject to copyright (rather the expression of the SSO), it seems to mean that publicly available expressions of the SSO should also be off limits.

Also, my understanding is that clean rooms are not strictly necessary to avoid copyright violation, they're just helpful in arguing the case. If the code is sufficiently different, then no infringement occurred, even if the code is written by the same person! There was some case president for this in software reverse engineering (clean room implementation not strictly followed, but code was non-infringing), but I seem to have lost my tab - maybe someone else knows the case?

Edit: I'm not saying Google should be in the clear here - they did copy the 7-line rangecheck function, as well as (portions?) of the headers. The header "copying" is where the SSO copyright comes in, as the functional portion of that code is necessarily identical, and would be identical if they had gone through a "translate to English and back again" or language scraping song and dance. And both of those are simply reexpression of the SSO, so it's not clear to me how they would avoid infringement.

Stickman fucked around with this message at 21:40 on May 15, 2016

# ? May 15, 2016 21:35

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

I was reading through the discussion on SSO in the opinion and came across this.

quote:

As the former Register of Copyrights of the United States pointed out in his brief amicus curiae, �[h]ad Google reverse engineered the programming packages to figure out the ideas and functionality of the original, and then created its own structure and its own literal code, Oracle would have no remedy under copyright whatsoever.� Br. for Amicus Curiae Ralph Oman 29. Instead, Google chose to copy both the declaring code and the overall SSO of the 37 Java API packages at issue.

It's page 48. The opinion is actually pretty good if you haven't read through it all. Everything seems pretty solidly reasoned and supported.

Edit: man I wish I had just been copy and pasting things from the decision earlier.

Page 53 posted:

Fair use is an affirmative defense to copyright infringement

Mr. Nice! fucked around with this message at 22:12 on May 15, 2016

# ? May 15, 2016 22:07

Space Gopher: Jul 31, 2006; BLITHERING IDIOT AND HARDCORE DURIAN APOLOGIST. LET ME TELL YOU WHY THIS SHIT DON'T STINK EVEN THOUGH WE ALL KNOW IT DOES BECAUSE I'M SUPER CULTURED.

Mr. Nice! posted:

I was reading through the discussion on SSO in the opinion and came across this.

It's page 48. The opinion is actually pretty good if you haven't read through it all. Everything seems pretty solidly reasoned and supported.

If Google had "created its own structure and its own literal code," then the structure would not have been that of the Java API, and the Dalvik API would be incompatible by definition.

To be compatible, APIs must be organized and structured in the same way. But, according to the decision, it is necessary to create an independent structure (as well as literal implementing code) to avoid infringement. Therefore, under this decision, Oracle has the right to control licensing of any implementation of the Java API, because any implementation is necessarily covered by Oracle's copyright on the structure of that implementation.

# ? May 15, 2016 22:21

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

Space Gopher posted:

If Google had "created its own structure and its own literal code," then the structure would not have been that of the Java API, and the Dalvik API would be incompatible by definition.

To be compatible, APIs must be organized and structured in the same way. But, according to the decision, it is necessary to create an independent structure (as well as literal implementing code) to avoid infringement. Therefore, under this decision, Oracle has the right to control licensing of any implementation of the Java API, because any implementation is necessarily covered by Oracle's copyright on the structure of that implementation.

Not necessarily. They could have literally rebuilt the api in virtually identical function and been fine.

Also the court points out that google contradicts itself here. They claim it's necessary for interoperability but then deliberately made their system incompatible with standard java.

# ? May 15, 2016 22:43

Space Gopher: Jul 31, 2006; BLITHERING IDIOT AND HARDCORE DURIAN APOLOGIST. LET ME TELL YOU WHY THIS SHIT DON'T STINK EVEN THOUGH WE ALL KNOW IT DOES BECAUSE I'M SUPER CULTURED.

Mr. Nice! posted:

Not necessarily. They could have literally rebuilt the api in virtually identical function and been fine.

Also the court points out that google contradicts itself here. They claim it's necessary for interoperability but then deliberately made their system incompatible with standard java.

The whole point of reimplementing the Java API is that you can take code written against the Java API (or whatever subset of the Java API you support), recompile it against the Google implementation, and run without further changes. That means that all the function calls must be organized the same way.

If you're using a "virtually identical" SSO that still meets the court's requirements for a distinct structure created independently, you lose that in a sea of compiler errors kicked off by references to packages, classes, and methods that don't exist where your Java API-targeted code thinks they do. Because, under the court's decision, it's necessary to come up with an independent system of SSO to avoid infringement, so your "virtually identical" necessarily can't be "identical enough to be compatible."

Finally, regardless of Google's actions and specific choices about implementing a subset of the API (which is, by the way, still compatible in that subset), what's important about this case is the standard set by the court. The standard they've chosen to set restricts any compatible reimplementation of an API, subset or not - at best, it's up to a jury's whims on fair use under a specific set of facts in a case.

# ? May 15, 2016 23:30

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

Space Gopher posted:

The whole point of reimplementing the Java API is that you can take code written against the Java API (or whatever subset of the Java API you support), recompile it against the Google implementation, and run without further changes. That means that all the function calls must be organized the same way.

If you're using a "virtually identical" SSO that still meets the court's requirements for a distinct structure created independently, you lose that in a sea of compiler errors kicked off by references to packages, classes, and methods that don't exist where your Java API-targeted code thinks they do. Because, under the court's decision, it's necessary to come up with an independent system of SSO to avoid infringement, so your "virtually identical" necessarily can't be "identical enough to be compatible."

Finally, regardless of Google's actions and specific choices about implementing a subset of the API (which is, by the way, still compatible in that subset), what's important about this case is the standard set by the court. The standard they've chosen to set restricts any compatible reimplementation of an API, subset or not - at best, it's up to a jury's whims on fair use under a specific set of facts in a case.

There were legal avenues for them to come up with 100% compatible code, but they chose not to do so. Google's compatibility argument is faulty anyways, because they didn't use the java api to be java compatible. They only used it to entice java programmers.

The bolded portion here is wrong for a number of reasons that we've discussed previously. It can be 100% functionally identical as long as it was developed independently. They would then fall under the fair use exception from both the accolade and sony cases.

Mr. Nice! fucked around with this message at 00:14 on May 16, 2016

# ? May 16, 2016 00:11

CommieGIR: Aug 22, 2006; The blue glow is a feature, not a bug; Pillbug

Really hoping that Google trounces Oracle. Oracle is a lovely company that got taken over by MBAs that are driving them into the dirt.

# ? May 16, 2016 00:31

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

CommieGIR posted:

Really hoping that Google trounces Oracle. Oracle is a lovely company that got taken over by MBAs that are driving them into the dirt.

Google is going to lose hard. Oracle may be lovely, but Google in this case is the deliberately bad actor. The appellate court has already indicated that it doesn't believe that Google has any valid fair use argument but there are fact specific questions still in the air that need to be decided at trial level.

# ? May 16, 2016 00:47

Condiv: May 7, 2008; Sorry to undo the effort of paying a domestic abuser $10 to own this poster, but I am going to lose my dang mind if I keep seeing multiple posters who appear to be Baloogan.

With love,
a mod

RuanGacho posted:

I think a lot of people are probably getting hung up on the fact that it seems incredibly farcical that the method you come up with to do the exact same thing that someone else has already done is treated as some sort of unique innovation that they deserve to get paid for indefinitely. Software is ephemeral as it is and if it was outside a courtroom people would be rolling their eyes at this as ridiculous silicon Valley nonsense potentially.

If this case were at this stage 15 years ago I think people would be a lot less worked up about it. I'm sure someone will disagree for any number of reasons but it comes across as Oracle rent seeking. Java has not exactly been cared for well since they took it over from Sun Microsystems.

java's actually doing very well under oracle. java 9 is going to have modules, java 8 added support for anonymous funtions and added a better date time lib based off joda time, etc. java languished at java 6 for a long time under sun, and development has really ramped up again since oracle took over

# ? May 16, 2016 00:56

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Stickman posted:

Nope, my understanding is that this ruling specifically makes the https://docs.oracle.com/javase/7/docs/api/, off limits for clean room design, because it embodies the Structure, Sequence, and Organization of the API, which is protected under copyright law. That's why Kalman and Mr. Nice! are arguing that they should instead scrape the specification from existing Java code (though it's not clear to me how this allows you to "independently develop" the SSO of the Java APIs, since they also embody the SSO of the API, and the end result will be exactly the same as the SSO in the public specification). This is how reimplementation has been done up to this point (see, for example, url=https://www.winehq.org/docs/winedev-guide/api-docs]Wine's clean room guidelines[/url]), but because the decision makes the SSO itself subject to copyright (rather the expression of the SSO), it seems to mean that publicly available expressions of the SSO should also be off limits.

Also, my understanding is that clean rooms are not strictly necessary to avoid copyright violation, they're just helpful in arguing the case. If the code is sufficiently different, then no infringement occurred, even if the code is written by the same person! There was some case president for this in software reverse engineering (clean room implementation not strictly followed, but code was non-infringing), but I seem to have lost my tab - maybe someone else knows the case?

Edit: I'm not saying Google should be in the clear here - they did copy the 7-line rangecheck function, as well as (portions?) of the headers. The header "copying" is where the SSO copyright comes in, as the functional portion of that code is necessarily identical, and would be identical if they had gone through a "translate to English and back again" or language scraping song and dance. And both of those are simply reexpression of the SSO, so it's not clear to me how they would avoid infringement.

Hmm. I thought I understood but I guess I don't. I thought "the API" was just what was defined in the actual source code and that Mr. Nice! said the javadoc URL was a "specification" that the clean room team could work against. I don't care either way, I just think the discussion is interesting. I admit I have no idea what I'm talking about.

# ? May 16, 2016 01:11

WhiskeyJuvenile: Feb 15, 2002; by Nyc_Tattoo

Condiv posted:

java's actually doing very well under oracle. java 9 is going to have modules, java 8 added support for anonymous funtions and added a better date time lib based off joda time, etc. java languished at java 6 for a long time under sun, and development has really ramped up again since oracle took over

yeah lambda functions are hot poo poo

Mr. Nice! posted:

Edit: man I wish I had just been copy and pasting things from the decision earlier.

I agree, under current caselaw, that is the case.

WhiskeyJuvenile fucked around with this message at 01:19 on May 16, 2016

# ? May 16, 2016 01:12

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

So what hypothetical system would you want to see in place to replace the current set up? I think it's less than ideal now for sure but I don't have a good answer.

# ? May 16, 2016 01:31

WhiskeyJuvenile: Feb 15, 2002; by Nyc_Tattoo

burden on copyright-holder that use isn't fair as part of case in chief

# ? May 16, 2016 01:36

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

So maintain copyright as the IP mechanism but have a standing presumption of fair use? Even still I think google would lose hard in this situation with that as the standard.

I don't know that I like that, personally. I think that fair use works best as an affirmative defense.

Mr. Nice! fucked around with this message at 01:51 on May 16, 2016

# ? May 16, 2016 01:49

Chuu: Sep 11, 2004; Grimey Drawer

Mr. Nice! -- do you program? I keep wondering this as I see your replies, because I keep seeing statements like this:

Mr. Nice! posted:

Not necessarily. They could have literally rebuilt the api in virtually identical function and been fine.

and it makes me wonder if you actually have used an API before. Because "virtually identical" isn't good enough. If it's not identical in terms of signature, it's not going to work.

# ? May 16, 2016 01:57

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

Chuu posted:

Mr. Nice! -- do you program? I keep wondering this as I see your replies, because I keep seeing statements like this:

and it makes me wonder if you actually have used an API before. Because "virtually identical" isn't good enough. If it's not identical in terms of signature, it's not going to work.

By virtually identical I mean they could put a closing brace on the same line right after a semi colon instead of on a new line. Those little differences would be present in independently created versions even if the line by line code ends up the same. And yes, this would be an extensive and costly project, but it isn't at all impossible and similar things have been done in the past. If they really wanted to independently build a compatible API, they could. The point of the matter is the reason behind google's copying in the first place is bogus. They weren't using it to be interoperable with Java. They stole it to entice Java developers.

# ? May 16, 2016 02:19

CommieGIR: Aug 22, 2006; The blue glow is a feature, not a bug; Pillbug

Mr. Nice! posted:

By virtually identical I mean they could put a closing brace on the same line right after a semi colon instead of on a new line. Those little differences would be present in independently created versions even if the line by line code ends up the same. And yes, this would be an extensive and costly project, but it isn't at all impossible and similar things have been done in the past. If they really wanted to independently build a compatible API, they could. The point of the matter is the reason behind google's copying in the first place is bogus. They weren't using it to be interoperable with Java. They stole it to entice Java developers.

Which doesn't matter because Oracle doesn't make money off Java. So what if Google was out to entice developers of an open source free language?

# ? May 16, 2016 02:31

WhiskeyJuvenile: Feb 15, 2002; by Nyc_Tattoo

Chuu posted:

Mr. Nice! -- do you program? I keep wondering this as I see your replies, because I keep seeing statements like this:

and it makes me wonder if you actually have used an API before. Because "virtually identical" isn't good enough. If it's not identical in terms of signature, it's not going to work.

It will work, though. Like there's no functional difference, just a practical one of needing refactoring

# ? May 16, 2016 02:33

Stickman: Feb 1, 2004

Mr. Nice! posted:

By virtually identical I mean they could put a closing brace on the same line right after a semi colon instead of on a new line. Those little differences would be present in independently created versions even if the line by line code ends up the same. And yes, this would be an extensive and costly project, but it isn't at all impossible and similar things have been done in the past. If they really wanted to independently build a compatible API, they could. The point of the matter is the reason behind google's copying in the first place is bogus. They weren't using it to be interoperable with Java. They stole it to entice Java developers.

Those sorts of of changes may avoid infringement on the copyright of the code (though they are superficial and likely wouldn't hold up in court - I'm looking for the case reference now!), but they don't do anything to avoid infringing the SSO of the API. That's why Kalman has been putting forth the idea of constructing the API specification by scraping existing code (which I also think doesn't necessarily avoid infringing the SSO copyright, and is also a pretty ridiculous automated added step).

Edit: Couldn't find the specific case, but it undoubtedly falls under "Derivative work" if you're simply changing whitespace/non-coding sections.

WhiskeyJuvenile posted:

It will work, though. Like there's no functional difference, just a practical one of needing refactoring

What do you mean by "refactoring" though? If you mean "translating to the original API", i.e. providing a wrapper, then sorry, now you're copying the API SSO!

Kobayashi posted:

Hmm. I thought I understood but I guess I don't. I thought "the API" was just what was defined in the actual source code and that Mr. Nice! said the javadoc URL was a "specification" that the clean room team could work against. I don't care either way, I just think the discussion is interesting. I admit I have no idea what I'm talking about.

That was the understanding the software developers had been working from - that the code itself is copyrighted, but the that the specification is a specification of a "method of operation" and thus not subject to copyright protections. Hence, projects like Wine and Linux (heck any language compiler not written by the language creator) could reimplement the computing functionality of an API starting from the API documentation without fear of infringement. This decision changes that by making the structure and organization of the API subject to copyright protection.

Stickman fucked around with this message at 03:06 on May 16, 2016

# ? May 16, 2016 02:42

WhiskeyJuvenile: Feb 15, 2002; by Nyc_Tattoo

Stickman posted:

What do you mean by "refactoring" though? If you mean "translating to the original API", i.e. providing a wrapper, then sorry, now you're copying the API SSO!

Rewriting application code to use non-copyright API calls (i.e. System.console.printLine instead)

# ? May 16, 2016 03:05

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

Stickman posted:

Those sorts of of changes may avoid infringement on the copyright of the code (though they are superficial and likely wouldn't hold up in court - I'm looking for the case reference now!), but they don't do anything to avoid infringing the SSO of the API. That's why Kalman has been putting forth the idea of constructing the API specification by scraping existing code (which I also think doesn't necessarily avoid infringing the SSO copyright, and is also a pretty ridiculous automated added step).

Edit: Couldn't find the specific case, but it undoubtedly falls under "Derivative work" if you're simply changing whitespace/non-coding sections.

What do you mean by "refactoring" though? If you mean "translating to the original API", i.e. providing a wrapper, then sorry, now you're copying the API SSO!

You misunderstand. By creating an independent version even if it is 100% functionally identical, Google would have the ability to claim fair use under accolade and Sony. This would be a defense for all of the infringement.

# ? May 16, 2016 03:05

WhiskeyJuvenile: Feb 15, 2002; by Nyc_Tattoo

Existing Java applications are derivative works of Oracle's APIs, and therefore aren't amenable to use in clean room reverse engineering

# ? May 16, 2016 03:09

Stickman: Feb 1, 2004

Mr. Nice! posted:

You misunderstand. By creating an independent version even if it is 100% functionally identical, Google would have the ability to claim fair use under accolade and Sony. This would be a defense for all of the infringement.

Presumably if you are changing braces in the headers, then you are working from the the API specification and/or headers? How are you claiming that you have created an "independent version"? Previously, you could create an independent version of the implementing code simply by working from the specification. The headers may end up exactly the same, but you wouldn't be infringing. Now you would need to create an "independent" version of the specification (that is, the SSO of the API). And I'm not seeing how moving braces are helping you to create and independent version of the specification (and how did you know to move the braces in the first place?)

Edit: Our point is that no one has put forth a convincing approach to developing an "independent version" of the API. It's also more than just "100% functionally identical". The SSO of the API will be 100% exactly identical (up to the point that interoperability is desired), and the functional components of the headers will likely be 100% identical (since they are simple a literal 1-1 translation of the API specification into the host language). You're right that that's beside the point if it's independently developed, it's just not clear that independent development is possible. It does make showing that someone copied/didn't copy those components more difficult, and makes the whole "independent development" component more ridiculous, when the end result is 100% identical to the original specification.

WhiskeyJuvenile posted:

Existing Java applications are derivative works of Oracle's APIs, and therefore aren't amenable to use in clean room reverse engineering

Yeah, I think that's Space Gopher's argument as to why code scraping wouldn't work for legal clean room reimplementation of an API. I'm not sure if "derivative work" would hold up here - the creators of Java certainly cannot claim copyright on code you've written in Java! On the other hand, a lot of code does seem like it would encompass derivation of parts of the SSO of the API (inheritance, etc.).

WhiskeyJuvenile posted:

Rewriting application code to use non-copyright API calls (i.e. System.console.printLine instead)

Our point is that this ruling precludes (or makes extremely convoluted) reimplementation of APIs and programming languages, either for interoperability or for reuse of existing code. So yeah, "use a different API" may need to be the answer, but it means that using an API locks your code to the API developer, and prevents extension or reimplementation (unless the appeal find fair use?) Also, just renaming methods is likely not enough to protect you from infringing on the SSO of the API.

Stickman fucked around with this message at 03:33 on May 16, 2016

# ? May 16, 2016 03:12

Kilroy: Oct 1, 2000

Mr. Nice! posted:

They claim it's necessary for interoperability but then deliberately made their system incompatible with standard java.

Because Dalvik won't run .class files? Why does that matter?

Again, dx works on .class files. You cannot make a .dex file for use with the Dalvik VM, without making a .class file first, which is runnable in Java itself.

# ? May 16, 2016 03:47

Mr. Nice!: Oct 13, 2005; c-spam cannot afford

Kilroy posted:

Because Dalvik won't run .class files? Why does that matter?

Again, dx works on .class files. You cannot make a .dex file for use with the Dalvik VM, without making a .class file first, which is runnable in Java itself.

I'm just talking about what the court said. Google cannot have its cake and eat it too. They cannot argue they infringed for interoperability reasons when they deliberately made their system incompatible.

# ? May 16, 2016 04:01

SurgicalOntologist: Jun 17, 2004

Is the idea that you could come up with the API structure by trial and error? Keep renaming function until the tests pass. It failed with your "open a file" function being called open? Try calling it open_file. Repeat ad nauseum and eventually you could duplicate the API.

It's kind of like 1000 monkeys on typewriters thought experiment. If you have a routine that will tell you whether a string matches the complete works of Shakespeare, it's now [theoretically] possible to come up with a clean-room reimplementation of the works of Shakespeare.

# ? May 16, 2016 04:02

Chuu: Sep 11, 2004; Grimey Drawer

SurgicalOntologist posted:

Is the idea that you could come up with the API structure by trial and error? Keep renaming function until the tests pass. It failed with your "open a file" function being called open? Try calling it open_file. Repeat ad nauseum and eventually you could duplicate the API.

There are lots of ways to do this in a "clean room' fashion, depending on how pedantic the courts are. I mean, is just downloading the jvm and scraping the documentation programmatically considered reverse engineering? How about using just the documentation for the .class file layout which is not part of the API -- but would let you trivially extract the entire API sans documentation?

It reminds me a lot of the Aereo case, which I'm surprised isn't brought up more. Trying to stick to the letter of the law to do something that is against the sprit of the law. The real problem here that irks so many people is the sprit of the law in this case is pretty much a 180 from how professional programmers wish it would work, and no technical workaround will fix that.

# ? May 16, 2016 04:59

WhiskeyJuvenile: Feb 15, 2002; by Nyc_Tattoo

I thought Aereo was wrongly decided for sure

# ? May 16, 2016 07:12

Slate Action: Feb 13, 2012; by exmarx

https://twitter.com/SCOTUSblog/status/732215092352274432
https://twitter.com/SCOTUSblog/status/732215169238085632

# ? May 16, 2016 15:26

NinjaDebugger: Apr 22, 2008

Slate Action posted:

https://twitter.com/SCOTUSblog/status/732215092352274432
https://twitter.com/SCOTUSblog/status/732215169238085632

Three boxes full of punts today, looks like.

# ? May 16, 2016 15:27

Slate Action: Feb 13, 2012; by exmarx

Or to put it another way:

https://twitter.com/BreakingNews/status/732215810501017600

e: yeah they deleted it. I was making fun of how they CNN'ed it.

Slate Action fucked around with this message at 15:46 on May 16, 2016

# ? May 16, 2016 15:28

evilweasel: Aug 24, 2002

Slate Action posted:

Or to put it another way:

https://twitter.com/BreakingNews/status/732215810501017600

I think this is wrong (edit: so do they, they deleted the tweet :v:

). The order is here, it's very short: http://www.supremecourt.gov/opinions/15pdf/14-1418_8758.pdf

In essence, it reads "we know that you cockgoblins can come to some understanding and we all know if you don't it's going to be a 4-4 mess with a circuit split over what a federal law means, so go back to the courts of appeals and settle this loving mess without us". It's a unanimous opinion so it's clear neither side won.

Ginsburg and Sotomoyer also filed a concurring opinion saying "seriously, no opinion on the merits, do not loving quote this as expressing an opinion on the merits"

evilweasel fucked around with this message at 15:44 on May 16, 2016

# ? May 16, 2016 15:42

Shifty Pony: Dec 28, 2004; Up ta somethin'

NinjaDebugger posted:

Three boxes full of punts today, looks like.

Yeah Spokeo got punted as well, although flipping through the the opinion it kind of reads that Spokeo is going to be in trouble at the when it makes it back.

# ? May 16, 2016 15:59

Kalman: Jan 17, 2010

evilweasel posted:

I think this is wrong (edit: so do they, they deleted the tweet ). The order is here, it's very short: http://www.supremecourt.gov/opinions/15pdf/14-1418_8758.pdf

In essence, it reads "we know that you cockgoblins can come to some understanding and we all know if you don't it's going to be a 4-4 mess with a circuit split over what a federal law means, so go back to the courts of appeals and settle this loving mess without us". It's a unanimous opinion so it's clear neither side won.

Ginsburg and Sotomoyer also filed a concurring opinion saying "seriously, no opinion on the merits, do not loving quote this as expressing an opinion on the merits"

And even in the remand order they were pretty clear about not disturbing a loving thing for the majority of people with the order.

"Nothing in this opinion, or in the opinions or orders of the courts below, is to affect the ability of the Government to ensure that women covered by petitioners� health plans �obtain, without cost, the full range of FDA approved contraceptives.�"

# ? May 16, 2016 16:13

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Mr. Nice! posted:

The discussion in that section is to explain why APIs survive section 102(b) of title 17.

This is in place to help separate different types of IP. It's a statutory tool to remove copyright from things that should be patented or otherwise. This section of the opinion is just explaining why the copyright in question does not fail the functionality test. The part he is quoting is just the appellate court listing facts from the copyrightabilty decision. They are merely reciting findings of fact from the previous decision to explain why the functionality does not defeat its copyright. The basic premise is there is protectable expression in the specific way things are organized, even if there is no copyrightability of the internal parts themselves.

It's not working very well :smith:

Mr. Nice! posted:

I'm just talking about what the court said. Google cannot have its cake and eat it too. They cannot argue they infringed for interoperability reasons when they deliberately made their system incompatible.

So everyone's pretending API compatibility is a binary thing? Oh what a strange and surreal parallel universe they're litigating from over there.

evilweasel posted:

I think this is wrong (edit: so do they, they deleted the tweet ). The order is here, it's very short: http://www.supremecourt.gov/opinions/15pdf/14-1418_8758.pdf

In essence, it reads "we know that you cockgoblins can come to some understanding and we all know if you don't it's going to be a 4-4 mess with a circuit split over what a federal law means, so go back to the courts of appeals and settle this loving mess without us". It's a unanimous opinion so it's clear neither side won.

Ginsburg and Sotomoyer also filed a concurring opinion saying "seriously, no opinion on the merits, do not loving quote this as expressing an opinion on the merits"

The Court has a great deal more optimism in thinking that the petitioner's meritless crankery will simply melt away if they keep arguing over it than I do!

# ? May 16, 2016 16:40

esquilax: Jan 3, 2003

Munkeymon posted:

The Court has a great deal more optimism in thinking that the petitioner's meritless crankery will simply melt away if they keep arguing over it than I do!

According to the government, the petitioners significantly narrowed their claims when the case went to SCOTUS. In the new briefs, the government put forward a process that appears to comply with the petitioner's narrowed requests. There's a pretty fair chance that this compromise will work.

# ? May 16, 2016 17:03

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 15:29

evilweasel: Aug 24, 2002

esquilax posted:

According to the government, the petitioners significantly narrowed their claims when the case went to SCOTUS. In the new briefs, the government put forward a process that appears to comply with the petitioner's narrowed requests. There's a pretty fair chance that this compromise will work.

It won't because the petitioners will be replaced by new petitioners who challenge the new rules. Remember, the actual issue here is that the petitioners don't like obamacare or don't like contraception, an the government isn't giving away either of those.

# ? May 16, 2016 17:49

The Something Awful Forums > Discussion > Debate & Discussion > SCOTUS 2023: Rice pilaf from Louisiana...is that like an ISIS video?

«‹›839 »