|
ulmont posted:Have you read the opinion? Did you see the part where the court rejects Google's attempt to apply the short phrases doctrine to defeat the copyright ability of the declaring code? The declaring code is explicitly noted to be copyright able separately from the arrangement of the APIs. I'm not going to even pretend this is an area of the law I know a drat thing about but Kalman's explanation is pretty straightforward and makes perfect sense and you're responding like he's speaking Greek.
|
#
?
May 15, 2016 05:21
|
|
|
|
| # ? May 17, 2024 21:02 |
|
|
Jarmak posted:I'm not going to even pretend this is an area of the law I know a drat thing about but Kalman's explanation is pretty straightforward and makes perfect sense and you're responding like he's speaking Greek. I haven't argued with Kalman's "as a whole" note. The Federal Circuit opinion, however, addresses the 7,000 lines of "declaring code" and their copyrightability separately from the organization of the APIs. As another example: quote:it is undisputed here that the declaring code and the structure and organization of the API packages are both creative and original.
|
|
#
?
May 15, 2016 05:31
|
|
|
ulmont posted:I haven't argued with Kalman's "as a whole" note. The Federal Circuit opinion, however, addresses the 7,000 lines of "declaring code" and their copyrightability separately from the organization of the APIs. Read my post two prior addressing exactly this issue, idiot. Wait, are you hung up n the word both? Both is describing both creative and original, which is clear if you look at other places it was used (eg slip op at 21.). Need to be both for copyright and originality was conceded, so the issue was whether it was creative. Kalman fucked around with this message at 05:45 on May 15, 2016 |
|
#
?
May 15, 2016 05:40
|
|
|
http://www.al.com/news/index.ssf/2016/05/us_supreme_court_rules_in_vern.html Scalia's death is the gift that keeps on giving. Apparently the jury found him guilty and wanted life without parole but since Alabama's a shithole of a state the judge sentenced him to death instead.
|
|
#
?
May 15, 2016 05:51
|
|
|
Kalman posted:Wait, are you hung up n the word both? Both is describing both creative and original, which is clear if you look at other places it was used (eg slip op at 21.). Need to be both for copyright and originality was conceded, so the issue was whether it was creative. Yes. The opinion describes and refers to the declaring code and the structure, selection and organization separately all the way through. In the slip opinion at 21, while "both" is used in "the API packages are both creative and original", the declaring code is commented as "the declaring code and the structure and organization of the Java API packages are original." If "the declaring code" and "the structure and organization of the Java API packages" were synonymous, there would be no need to separate them. This is consistent throughout: 6: "the declaring code and the structure, sequence, and organization of the API packages are entitled to copyright protection" 9: "The second option is the Specification License, which provides that the licensee can use the declaring code and organization of Oracle’s API packages but must write its own implementing code." 13, when discussing the opinion, below, the Federal Circuit separates discussions of declaring code from the overall structure: "On May 31, 2012, the district court issued the primary decision at issue in this appeal, finding that the replicated elements of the Java API packages—including the declarations and their structure, sequence, and organization—were not copyrightable. As to the declaring code, the court concluded that “there is only one way to write” it, and thus the “merger doctrine bars anyone from claiming exclusive copyright ownership of that expression.” Copyrightability Decision, 872 F. Supp. 2d at 998. The court further found that the declaring code was not protectable because “names and short phrases cannot be copyrighted.” Id. As such, the court determined that “there can be no copyright violation in using the identical declarations.” Id. As to the overall structure, sequence, and organization of the Java API packages, the court recognized that “nothing in the rules of the Java language . . . required that Google replicate the same groupings even if Google was free to replicate the same functionality.”" 15: "Instead, it is undisputed that Google copied 7,000 lines of declaring code and generally replicated the overall structure, sequence, and organization of Oracle’s 37 Java API packages." 22 (again discussing the opinion below): "The court found, however, that neither the declaring code nor the SSO [sequence / structure / organization] was entitled to copyright protection under the Copyright Act." 26 (note how Oracle separates these and the Federal Circuit agrees: "Specifically, Oracle argues that the district court erred when it: (1) concluded that each line of declaring code is uncopyrightable because the idea and expression have merged; (2) found the declaring code uncopyrightable because it employs short phrases; (3) found all aspects of the SSO devoid of protection as a “method of operation” under 17 U.S.C. § 102(b); and (4) invoked Google’s “interoperability” concerns in the copyrightability analysis. For the reasons explained below, we agree with Oracle on each point." 27 (noting that Oracle's claims of literal copying of the declaring code are separate from the SSO claims): "While Google is correct that the jury instructions and verdict form focused on the structure and organization of the packages, we agree with Oracle that there was no need for the jury to address copying of the declaring code because Google conceded that it copied it verbatim...That the district court addressed the declaring code in its post-jury verdict copyrightability decision further confirms that the verbatim copying of declaring code remained in the case." 37 (see how the declaring code is disjunctive from the SSO): "For these reasons, the trial court was correct to conclude that the scenes a faire doctrine does not affect the copyrightability of either the declaring code in, or the SSO of, the Java API packages at issue." 39: "it is undisputed here that the declaring code and the structure and organization of the API packages are both creative and original." 48: "Instead, Google chose to copy both the declaring code and the overall SSO of the 37 Java API packages at issue." 51: "Although this competitive objective might be relevant to the fair use inquiry, we conclude that it is irrelevant to the copyrightability of Oracle’s declaring code and organization of the API packages." 52-53: "Instead, it chose to copy Oracle’s declaring code and the SSO to capitalize on the preexisting community of programmers who were accustomed to using the Java API packages."
|
|
#
?
May 15, 2016 06:01
|
|
|
Go read my earlier post, it shows why everything you just posted is irrelevant to the argument you think you're making.
|
|
#
?
May 15, 2016 06:05
|
|
|
Jarmak posted:I'm not going to even pretend this is an area of the law I know a drat thing about but Kalman's explanation is pretty straightforward and makes perfect sense and you're responding like he's speaking Greek. The reason people keep acting like Kalman and Discendo Vox are speaking Greek is that they keep posting that people are misinterpreting the decision when they say that "APIs are now copyrightable", as if the statement wasn't true. I also can't pretend to know much of anything about copyright law / fair use, but I can see how Kalman's explanation (and the discussion of the last 10 pages) misses the point from a programmer's prospective. I can't say 100% what tekz meant, when I say "APIs are now copyrightable", it means that the relevant form and functionality of the API is protected by copyright law. One cannot implement an API designed to provide the same interface as an existing API without infringing upon the copyright claimed on the existing API. In turn, this means that it is not possible to provide an independent API that works with existing code without licensing the original. So far as I can tell, that is exactly what the decision says about the copyrightability of the "Structure, Sequence, and Organization" of API packages. The decision's wording is: quote:The court further explained that Google could have offered the same functions in Android by “rearranging the various methods under different groupings among the various classes and packages.” That is, Google could have changed the class and method structures and/or names in order to not infringe upon the SSO of the API. But doing so would result in a different API, one that is not compatible with existing code (if the goal is portability) or requires learning new structures (if the goal is provide a unified interface to users of the competing APIs, as it appears was Google's goal). That's why all the "clean environment reverse engineering" talk in the past 10 pages is nonsensical to the programmers in the discussion. Sure, you can clean room an implementation of the API (as Google [mostly] did), but the you clean room the API then you lose interoperability and ease of use. With the copyrightability of APIs, my understanding is that the current undecided question whether such unlicensed reimplementation falls under fair use. Regardless of whether this decision is legally sound, the end result is for programmers is that if you use an API in your code, you are stuck with using the implementation provided by the copyright holder (barring licensed reimplementations). If the copyright holder's implementation fails for some reason (no longer provides updates, buggy code, etc.), then, so far as I can tell, it is infringement to implement the API myself to ensure continued functionality of my code. It also makes clear that actions like Google's are likely not permissible - unlicensed reimplementation of an API in order to provide interoperability and/or ease of use. What's not clear to me right now is how different an API would need to be to avoid infringement. From the decision, it sounds like the structure and names would need to be independently developed to provide the same functionality. Anyway that's why Kalman's explanations don't always make sense to me. He's arguing from the perspective that APIs are somehow separable from there "structure, sequence, and organization" and that people think that ruling means you can be sued for using APIs. Kalman posted:I think a lot of people are confusing the ruling ("the structure, sequence, and organization of a set of APIs can be copyrighted") for the shorthand ("APIs are copyrightable!"), and it's leading to bad predictions of effects, like developers being worried they'll be sued for developing using the APIs a language presents. I haven't found any blogs/posts claiming that you can be sued for APIs. Instead the EFF has been saying that you can be sued for reimplementing or extending an existing API. This seems to be exactly what the decision says, and it's an activity that is perhaps more important than Kalman or DV realize? None of Kalman or Discendo Vox's posts have helped me understand why that isn't the case or why they believe APIs are not copyrightable. It also doesn't help that they take a very confrontational approach to addressing comments/questions about the issue. E: I do see Kalman's point about the short phrases. It's possible that Google's arguments in the case where inadequate, and that the decision was correct given current IP law (though I wasn't convinced by the courts reasoning on the API SSO as a "method of operation"). That doesn't preclude it's consequences in the software development field. Stickman fucked around with this message at 06:45 on May 15, 2016 |
|
#
?
May 15, 2016 06:35
|
|
|
Stickman posted:The reason people keep acting like Kalman and Discendo Vox are speaking Greek is that they keep posting that people are misinterpreting the decision when they say that "APIs are now copyrightable", as if the statement wasn't true. I also can't pretend to know much of anything about copyright law / fair use, but I can see how Kalman's explanation (and the discussion of the last 10 pages) misses the point from a programmer's prospective. I can't say 100% what tekz meant, when I say "APIs are now copyrightable", it means that the relevant form and functionality of the API is protected by copyright law. One cannot implement an API designed to provide the same interface as an existing API without infringing upon the copyright claimed on the existing API. In turn, this means that it is not possible to provide an independent API that works with existing code without licensing the original. bolded part is wrong and it's because a lot of people don't understand how copyright works. You can still absolutely implement an API that mirrors an extant one so long as you either properly licensed it or developed it independently of the other. Google is hosed because they blatantly disregarded the legal avenues they had in front of them and deliberately chose to infringe. Copyrights are not patents and they don't work the same way. This decision isn't the end of the world and isn't really going to screw things up too much. I do agree, though, that there should be some other sort of statutory structure for software IP but gently caress if I know what it should be.
|
|
#
?
May 15, 2016 06:43
|
|
|
Mr. Nice! posted:bolded part is wrong and it's because a lot of people don't understand how copyright works. You can still absolutely implement an API that mirrors an extant one so long as you either properly licensed it or developed it independently of the other. Google is hosed because they blatantly disregarded the legal avenues they had in front of them and deliberately chose to infringe. We're not disagreeing at all. If you license the software you can reimplement an API. You need a license because the SSO of the API (which is exactly what a software developer means when he/she says "API) is covered by copyright. You can also independently develop an API that provides the programmatic functionality of the existing API. This independently developed API will never provide the same interface (bolded from the bit you quoted) as the original, and thus will not provide interoperability. That's my whole point. Google didn't copy the SSO of the Java APIs out of lazyness (well not totally), they did it so that existing code would be easy to port to their system and so that programmers would not need to learn new APIs in order to use their alternative software system. There now is literally no (unlicensed) way to accomplish that goal without infringing Oracle's copyright. Hence, "the API is protected by copyright" seems relevant shorthand, given the developer's meaning of "the API". Edit: Well, we're disagreeing on what an "API" is and what "implementing an API" means. I believe you are arguing from the perspective of that "the API" means it's semantic functionality; that is, what it accomplishes. I.e. I could write a new API that provides classes for windows and text boxes etc. that doesn't look anything like the Windows API or Java's windows API. To a developer, the syntax of the API is also relevant when using the API. My new windows API would not be and implement of Windows API to a programmer, because it provides a different interface. Code written for the Windows API would not be compatible with my new API, so it is not an "implementation" of the Windows API from the perspective of programming functionality, despite provide the same end functionality. Stickman fucked around with this message at 07:03 on May 15, 2016 |
|
#
?
May 15, 2016 06:54
|
|
|
Yes there is. They could have wrote code that functionally was identical to the java api with the same function calls etc if they had wrote it independently. They did write a bunch of it themselves, but deliberately chose not to in some instances. It is absolutely ok to reverse engineer things and rebuild interfaces that are the same and not run afoul of copyright so long as it's done in a proper manner. This is the part that evilweasel is most upset about.
|
|
#
?
May 15, 2016 06:59
|
|
|
Mr. Nice! posted:Yes there is. They could have wrote code that functionally was identical to the java api with the same function calls etc if they had wrote it independently. They did write a bunch of it themselves, but deliberately chose not to in some instances. When you say "functionally identical to the Java API", do you mean that code written for the Java API would work with the newly reverse engineered interface? How do you think such a reverse implementation would work? How would it look any different from the code that Google produced? The decision says that the APIs contain "37 packages, with over six hundred classes, with over six thousand methods". If Google changed the name or structure of any of those packages, classes, or methods, they would break the interoperability of existing code (and thus be developing a new API, not reimplementing the Java API). The structure and syntax of those packages, classes, and methods is defined in the header files. If, by some miracle of God, Google managed to reproduce this interface, those header files would look exactly the same as if they had been copied. Barring comments and English commentary, of course. Does anyone know if those were actually copied? Comments are irrelevant, regardless, because the decision specifically says that Google would have needed different structure and names to avoid infringement.
|
|
#
?
May 15, 2016 07:13
|
|
|
The point ulmont seems to be missing is that the declaring code copyright is bound up in the structural copyright - I.e., reimplementing a couple of lines for a couple of calls isn't copyrighted (because short phrases would apply) but when you reimplemented a significant chunk of the full API, you lose that protection. The example the decision uses is helpful. Dickens' Bleak House is a succession of short phrases. Each one individually isn't enough for copyright - the copyright attached to the work as a whole. Similarly, a given line of declaring code can be protected or not protected depending on whether it's part of a larger set of APIs or not.
|
|
#
?
May 15, 2016 07:14
|
|
|
Stickman posted:When you say "functionally identical to the Java API", do you mean that code written for the Java API would work with the newly reverse engineered interface? How do you think such a reverse implementation would work? How would it look any different from the code that Google produced? yes they could have reverse engineered something that was functionally identical and been in the clear. That's been the rule basically since sega v accolade. This is the clean room process that evil weasel is talking about. This, of course, takes a lot more man hours and work, but there's nothing stopping them from doing it. The other alternative is to license the original code from the source.
|
|
#
?
May 15, 2016 07:20
|
|
|
Stickman posted:When you say "functionally identical to the Java API", do you mean that code written for the Java API would work with the newly reverse engineered interface? How do you think such a reverse implementation would work? How would it look any different from the code that Google produced? You document the method by which you produced it to show it truly was independently composed. In contrast, Google admitted to copying the declaring code. (And you reverse it by looking at code that others have written to run on Java. You just need to not look at anything from Sun/Oracle. Difficult but not impossible. Then again, writing it in the first place was difficult, so why should you be allowed to benefit from their successes?)
|
|
#
?
May 15, 2016 07:22
|
|
|
Kalman posted:The point ulmont seems to be missing is that the declaring code copyright is bound up in the structural copyright - I.e., reimplementing a couple of lines for a couple of calls isn't copyrighted (because short phrases would apply) but when you reimplemented a significant chunk of the full API, you lose that protection. This make sense to me from a legal. It still leaves it unclear as to how much of an API you can reimplement and use the "short phrases" defense, and highlights why using copyright to protect functional code is such a "square peg" situation. The real-world reasons for and consequences of "copying" all or part of an API declaration are very different from the reasons for and real-world consequences of copying bits or all of Bleak House (though I guess now that's totally up for grabs?).
|
|
#
?
May 15, 2016 07:22
|
|
|
Kalman posted:You document the method by which you produced it to show it truly was independently composed. Exactly. It doesn't matter if the code google created looked 100% like the java api so long as they were able to demonstrate that they had actually independently created it. They deliberately chose not to and hoped they could win in court.
|
|
#
?
May 15, 2016 07:24
|
|
|
Stickman posted:This make sense to me from a legal. It still leaves it unclear as to how much of an API you can reimplement and use the "short phrases" defense, and highlights why using copyright to protect functional code is such a "square peg" situation. The real-world reasons for and consequences of "copying" all or part of an API declaration are very different from the reasons for and real-world consequences of copying bits or all of Bleak House (though I guess now that's totally up for grabs?). The real world reasons for copying an API declaration so you can reimplemented it are generally to benefit from work someone else did, so forgive me for not crying for the uncertain. Again: writing code that makes API calls to someone else's implementation isn't at stake here.
|
|
#
?
May 15, 2016 07:25
|
|
|
Stickman posted:This make sense to me from a legal. It still leaves it unclear as to how much of an API you can reimplement and use the "short phrases" defense, and highlights why using copyright to protect functional code is such a "square peg" situation. The real-world reasons for and consequences of "copying" all or part of an API declaration are very different from the reasons for and real-world consequences of copying bits or all of Bleak House (though I guess now that's totally up for grabs?). This goes to the issue of licensing. There is a mechanism already to sort out how to deal with when you can use another's code. You simply follow whatever license is available or negotiate with the property owner. Otherwise you have to write it yourself.
|
|
#
?
May 15, 2016 07:27
|
|
|
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.
|
|
#
?
May 15, 2016 07:36
|
|
|
Are people saying that doing what amount to a mechanical translation of declarations into a different form and back again has legal significance? ... And what if this translation is done entirely by a machine?
|
|
#
?
May 15, 2016 07:46
|
|
|
Mr. Nice! posted:yes they could have reverse engineered something that was functionally identical and been in the clear. That's been the rule basically since sega v accolade. This is the clean room process that evil weasel is talking about. This, of course, takes a lot more man hours and work, but there's nothing stopping them from doing it. The other alternative is to license the original code from the source. Kalman posted:You document the method by which you produced it to show it truly was independently composed. Okay, I see where you are coming from now on clean rooms and headers - I haven't read the bits about Google clean room approach, so I'm willing to take your word that it wasn't ideal. But, and here's the big but, the "functional specification" that the dirty room team would have sent to the clean room team is basically exactly the API specification (the SSO). The case decision says that the SSO of the API is copyrightable, and thus not possible to send to a clean room. That is, even if the headers were rewritten in English - i.e. "there is a class Foo with method Bar taking an int Baz and character string Bleh. This function returns a character that is the Bazth character of Bleh" - the functional specification (taken together with all other such specificiations) still replicates the SSO of the API. I've not done on dirty/clean room development, but from brief, this sort of functional specification has been standard practice for API reimplementation. The wording of the Google decision seems to make it necessary to abstract this a step further, which you suggest could be done using pure clean room testing to tease out the syntax of the API. Does this match your assessment of the ruling? Did the ruling actually mention Google's clean room practices? I can't see it anywhere. Since the semantics of the API are not subject to such strict regulation (they can be obtained from documentation/decompilation/public source codes and translated to functional form), it seems put such strict regulation on the syntax and structure simply because they already are "the functional form". Regardless, this is very different from Sega v. Accolade. As for why others benefiting from your work, remember that reverse-engineering is allowed for a reason. Interoperability has already been estabilished as a valid goal of reverse engineering, and that reverse engineering can use publicly available specifications. Even the literal book on Application Software Reengineering says that clean room reverse engineered software can be developed using publicly available specifications. This ruling seems to go beyond saying that Google's literal copying of headers was off limits by saying that the SSO of the API is off limits and suggesting that Google should have changed the SSO (rather than your suggestion of hard-core clean rooming of the SSO). So developers seeing this as problematic hardening of the rules (with potential chilling effects on interoperability and code reuse) makes sense to me. Here's another question (that I'd love for someone more knowledgeable than me to answer). If, when developing and interoperable device, the dirty-room coders reverse engineer a closed API or protocol, can they write specifications based on that protocol for the clean room development team? That seems like that protocol would now be subject to copyright and thus off limits. Edit: Regardless, is your problem with the EFF's interpretation ("APIs are copyrightable!", "We can't reimplement APIs anymore") simply that you believe that API SSO and specification details themselves have previously been subject to copyright protection, and thus have never been fair game for a proper clean-room reimplementation (which you seem to believe can be achieved with some extra hoop jumping, but I'm still skeptical)? Stickman fucked around with this message at 11:03 on May 15, 2016 |
|
#
?
May 15, 2016 10:11
|
|
|
Mr. Nice! posted:yes they could have reverse engineered something that was functionally identical and been in the clear. That's been the rule basically since sega v accolade. This is the clean room process that evil weasel is talking about. This, of course, takes a lot more man hours and work, but there's nothing stopping them from doing it. The other alternative is to license the original code from the source. 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) Kalman posted:
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.
|
|
#
?
May 15, 2016 10:17
|
|
|
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?
|
|
#
?
May 15, 2016 16:05
|
|
|
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? They didn't poach Sun engineers, they hired a guy who left Sun when it became apparent Oracle was going to buy them out, and they not only hired just any engineer, but the primary creator of Java itself. Sun specifically said that regardless if Google was hammering out an agreement over Java, they believed they didn't have grounds to go after Google for Java either way. Oracle is specifically being litigious for the sake of scraping some value out of their purchase of Sun.
|
|
#
?
May 15, 2016 16:12
|
|
|
Y'know, it's entirely possible that both parties in this internet argument are right, and anyone who wants to develop a API without liscencing it from the original company has a clearly defined simple legal path to do so that is technically impossible. It wouldn't be the first time that a law ended up doing the exact opposite of what it was intended to do.
|
|
#
?
May 15, 2016 16:15
|
|
|
Are you trying to tell me it's impossible to reverse engineer a compatible form of java? That's ludicrous. It's absolutely possible and it is also demonstrable that it was created in a legally allowed method. Is it time consuming? Absolutely. Is it impossible? Absolutely not. Edit: Here's a crude method that would be allowable. Google could have taken a java program they had written that used the api they want to implement. The have their own source and the output when it is ran on the oracle jvm. They then write their own api that takes the same input and gives the same output in the dalvik jvm. With enough time and testing, they will have built an api that is 100% compatible with java even though they didn't take oracle's intellectual property. This is what accolade did decades ago. Sega wouldn't give you the api access for their console without paying some big up front fees. Accolade was already making games for other purposes and just reverse engineered the entire sega console spec so their games would play. Google could have done the same thing, but chose not to do so. Mr. Nice! fucked around with this message at 17:33 on May 15, 2016 |
|
#
?
May 15, 2016 17:22
|
|
|
How is it possible to make a reversed-engineered API with the same non-semantic details like names of functions without having access to the names of the functions in the first place?
|
|
#
?
May 15, 2016 17:30
|
|
|
SurgicalOntologist posted:How is it possible to make a reversed-engineered API with the same non-semantic details like names of functions without having access to the names of the functions in the first place? Because you already have code that runs on a java vm and gives an expected output. Make something that gives the same output when you run that code on it.
|
|
#
?
May 15, 2016 17:38
|
|
|
Google isn't prevented from using the same names, function calls, etc. That isn't what the issue in the case has been. Had google spent the time to make their own implementation, even if it ended up with virtually identical code, they would have been 100% in the clear. Everyone seems hung up about that part. It's perfectly fine for the dalvik api to look exactly like the java api. The part that courts care about is the process to get to that point.
|
|
#
?
May 15, 2016 17:42
|
|
|
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.
|
|
#
?
May 15, 2016 17:59
|
|
|
I am definitely not trying to paint Oracle in a good light. It's just google is so wildly in the wrong in this case.
|
|
#
?
May 15, 2016 18:03
|
|
|
Mr. Nice! posted:I am definitely not trying to paint Oracle in a good light. It's just google is so wildly in the wrong in this case. I won't comment on the validity of the case itself, just that Oracle is probably felt to be wrong in benefitting its legal stance because Android itself feels to many tech inclined people like Jon Val Jon stole the bread of Java and then fed not only his family but an entire starving nation with it. At some point one is given pause to wonder if some laws are a real societal benefit despite their unflawed execution and adherence. That is probably the source of most contention amongst those whom are law trained and not in this thread these days.
|
|
#
?
May 15, 2016 18:15
|
|
|
I just can't feel sympathy for a flagrant theft of IP.
|
|
#
?
May 15, 2016 18:20
|
|
|
RuanGacho posted:I won't comment on the validity of the case itself, just that Oracle is probably felt to be wrong in benefitting its legal stance because Android itself feels to many tech inclined people like Jon Val Jon stole the bread of Java and then fed not only his family but an entire starving nation with it. Java was GPLed. Google could always have actually abided by the license terms and released their code under the GPL if they wanted to take advantage of it. They didn't, because they thought they could get away with it. Turns out they were wrong, but my sympathy isn't with the person who has a perfectly reasonable free option available to them and choose not to take advantage. (And it's Jean Valjean, FYI.)
|
|
#
?
May 15, 2016 18:26
|
|
|
Kalman posted:Java was GPLed. Google could always have actually abided by the license terms and released their code under the GPL if they wanted to take advantage of it. They didn't, because they thought they could get away with it. Turns out they were wrong, but my sympathy isn't with the person who has a perfectly reasonable free option available to them and choose not to take advantage. Thanks, was phone posting couldn't be arsed to make my searches weirder by googling Les Miserables. To be clear I'm not trying to defend Google's behavior or anything in this case, just trying to rationalize why people feel so strongly about it, its more anti-Oracle than pro law breaking I'm pretty sure. Though I'm sure those same people would say the law should be reformed which I'm inclined to agree with.
|
|
#
?
May 15, 2016 18:30
|
|
|
Kalman posted:Java was GPLed. Google could always have actually abided by the license terms and released their code under the GPL if they wanted to take advantage of it. They didn't, because they thought they could get away with it. Turns out they were wrong, but my sympathy isn't with the person who has a perfectly reasonable free option available to them and choose not to take advantage. Exactly. For all the wringing of hands about how to exactly reverse engineer Java, there was actually an explicitly free option on the table. Edit I should put free in quotes because the GPL is a virus with its own host of issues, but it was still a zero raw dollar cost option that Google had available.
|
|
#
?
May 15, 2016 18:30
|
|
|
Stickman posted:So far as I can tell, that is exactly what the decision says about the copyrightability of the "Structure, Sequence, and Organization" of API packages. The decision's wording is: Wait, where is that from? I skimmed the decision but didn't notice the court substituting an alternate reality for ours in there.
|
|
#
?
May 15, 2016 18:31
|
|
|
Munkeymon posted:Wait, where is that from? I skimmed the decision but didn't notice the court substituting an alternate reality for ours in there. It's from the 2014 appeals decision, in the section about the Structure, Sequence, and Organization of APIs. Here's the uscourts.gov link (it's the same document that was linked from its EFF mirror earlier): http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/13-1021.Opinion.5-7-2014.1.PDF The quote is from the end of the section, pages 44-45. Stickman fucked around with this message at 20:42 on May 15, 2016 |
|
#
?
May 15, 2016 19:34
|
|
|
Stickman posted:It's from the 2014 appeals decision, in the section about the Structure, Sequence, and Organization of APIs. Here's the uscourts.gov link (it's the same document that was link from its EFF mirror earlier): So they're selectively quoting to make a totally different, willfully ignorant argument that the original opinion didn't. I guess it's not just for Scalia 
|
|
#
?
May 15, 2016 19:52
|
|
|
|
| # ? May 17, 2024 21:02 |
|
|
Munkeymon posted:So they're selectively quoting to make a totally different, willfully ignorant argument that the original opinion didn't. I guess it's not just for Scalia Yep, just read the district court decision, and the appeals decision left out the following sentences which reads quote:They would not, however, be interoperable. Specifically, code written for one API would not run on an API organized differently, for the name structure itself dictates the precise form of command to call up any given method. The appeals court rejected that this had any bearing, because they argue that interoperability is a commercial goal that has no bearing on whether the SSO is protected by copyright. And perhaps they are right under current law, but it does mean that API reimpelementation is now held to a much stricter (and perhaps unattainable) standard than clean-room reverse engineering in other fields, since the specification itself (not just the specific documentation of the specification) is protected by copyright. Or maybe this is applicable to all fields now? Can a corporation make a copyright claim on, say, the specification of the diameter and thickness of a water pipe so that a third party creating a water meter would be in violation of that copyright if they used publicly available documentation of the water pipe rather than measuring the pipe? Stickman fucked around with this message at 21:09 on May 15, 2016 |
|
#
?
May 15, 2016 20:50
|
|