|
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 |
|
|
# ? May 17, 2024 19:03 |
|
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 |
|
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. 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 |
|
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 |
|
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 |
|
Mr. Nice! posted:I was reading through the discussion on SSO in the opinion and came across this. 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 |
|
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. 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 |
|
Mr. Nice! posted:Not necessarily. They could have literally rebuilt the api in virtually identical function and been fine. 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 |
|
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. 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 |
|
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 |
|
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 |
|
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. 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 |
|
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. 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 |
|
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 |
|
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 |
|
burden on copyright-holder that use isn't fair as part of case in chief
|
# ? May 16, 2016 01:36 |
|
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 |
|
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 |
|
Chuu posted:Mr. Nice! -- do you program? I keep wondering this as I see your replies, because I keep seeing statements like this: 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 |
|
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 |
|
Chuu posted:Mr. Nice! -- do you program? I keep wondering this as I see your replies, because I keep seeing statements like this: It will work, though. Like there's no functional difference, just a practical one of needing refactoring
|
# ? May 16, 2016 02:33 |
|
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 |
|
Stickman posted:
Rewriting application code to use non-copyright API calls (i.e. System.console.printLine instead)
|
# ? May 16, 2016 03:05 |
|
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). 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 |
|
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 |
|
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 |
|
Mr. Nice! posted:They claim it's necessary for interoperability but then deliberately made their system incompatible with standard java. 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 |
|
Kilroy posted:Because Dalvik won't run .class files? Why does that matter? 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 |
|
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 |
|
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 |
|
I thought Aereo was wrongly decided for sure
|
# ? May 16, 2016 07:12 |
|
https://twitter.com/SCOTUSblog/status/732215092352274432 https://twitter.com/SCOTUSblog/status/732215169238085632
|
# ? May 16, 2016 15:26 |
Slate Action posted:https://twitter.com/SCOTUSblog/status/732215092352274432 Three boxes full of punts today, looks like.
|
|
# ? May 16, 2016 15:27 |
|
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 |
|
Slate Action posted:Or to put it another way: 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" evilweasel fucked around with this message at 15:44 on May 16, 2016 |
# ? May 16, 2016 15:42 |
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 |
|
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 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 |
|
Mr. Nice! posted:The discussion in that section is to explain why APIs survive section 102(b) of title 17. It's not working very well 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 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 |
|
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 |
|
|
# ? May 17, 2024 19:03 |
|
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 |