11 ms·

To explain if you are just joining in: This pretty much means Oracle v Google, a case with major ramifications for the industry has been settled out of court. I

To explain if you are just joining in: This pretty much means Oracle v Google, a case with major ramifications for the industry has been settled out of court. I don't see how this can be interpreted any other way.

0x0 11y ago
Also, why are the two timestamps so far off? Authored in February 2015 (almost a year ago!), but committed only in Nov 2015.
- temac 11y ago
  Maybe because this has been ready for a long time just in case and they just decided to actually switch to that strategy right now?
- deathanatos 11y ago
  This is a git repo, so "authored" tries to map to the person who wrote the content, and the "idea" of the commit, if there is such a thing. It's set when the commit is initially created, and for the most part not changed unless explicitly requested. The commit date is the actual time the commit object was made; this can differ if the commit is amended, rebased, cherry-picked, the result of a squash/fixup, etc. If a commit sits on a branch for months, then gets rebased against master, code-reviewed, and merged, those two dates will be significantly different. This usually works as you might expect. If your coworker Joe authors a commit on a branch, and you cherry-pick it onto another branch, that cherry-picked commit is authored by Joe (and the time reflects when Joe authored it) and commited by you (at the time you performed the cherry-pick).
  - saurik 11y ago
    First, read my response to the other person who provided a technical answer to this question. https://news.ycombinator.com/item?id=10806642 https://news.ycombinator.com/item?id=10806642 You have gone a little further and provided some general reasons as to "why this might happen", but you still seem to have missed the essence of the question, which was almost certainly more "can someone come up with some guess why, in this particular circumstance, given the theories about this commit being influenced by a settlement of the Oracle lawsuit, this commit was authored in February but only landed in November?".
    - deleted 11y ago
      [deleted]
- kazinator 11y ago
  This means that a person named Piotr Jastrzebski created a commit in February. This is a different commit based on that one (not in the sense of revision ancestry, but in the sense of rewrite history): this commit is the N-th rewrite of Piotr's Jasterbski's commit, for some N > 0, and the rewriter ("committer") is Narayan Kamath. The rewrite can have different content: for instance, it can be altered to merge against a different parent. An example of a rewrite is a simple cherry-pick (e.g. from one branch to another). All these things are commits. The initial authoring is a commit, and this latest rewrite by a different person is a commit.
  - saurik 11y ago
    You have answered how it is possible, not why it happened: that is like someone pointing out that this "mysterious" commit is actually quite easy to explain, as a commit is an object in a git database, and we have all the metadata to see who made this one: I am extremely well aware of how it works (I give lectures at UCSB about git where I start by explaining the internal file formats and work my way up to the various command line tools), but I still found the question here of "why was this authored in February but only landed in November" fascinating, given the speculation about Oracle.
grizzles 11y ago
If this inference is right, I hope this means that Google will enable the web community to use the JVM with or as an alternative to WebAssembly. Hotspot is absolutely incredible technology, and it's competitors are still many years away from coming close to matching it's capabilities.
- 0x0 11y ago
  Embedding the JVM to run code within webpages you say? Hasn't that been tried before? :-S
- devsquid 11y ago
  I'm all for the JVM but it's too powerful to run arbitrary code man. No JVM in my browser please.
  - geofft 11y ago
    The Java plugin's mistake was to embed a rich sandboxing mechanism right in the middle of the language layer. The Java runtime, in the middle of parsing bytecode and registering class hierarchies, is supposed to enforce who can access what things, not simply as an advisory mechanism or safety check (as public/private is just about everywhere else), but as a security mechanism under active assault, with only this single line of defense between untrusted code and full local privileges just like native code. And, like anything with a complicated security policy and a wide attack surface, it had no chance. Stick a regular, unprivileged JVM, with no secure classloader magic, inside a straightforward non-Java low-level sandbox like NaCl or even just PPAPI + Chrome's renderer sandboxing (like Pepper Flash or PDFium) and it'll probably hold up just fine. And honestly that's what Android does. Java isn't a security boundary on Android, and the NDK makes this explicit. Each app runs as its own UID, and the kernel is taught to isolate users a bit more than usual for UNIX, and that holds up pretty well -- not perfect, but far better than the Java plugin does. (To be clear, I'm not advocating the JVM as a platform for web content. Just that, if somehow it turns out that the JVM is in fact the right platform, the sandboxing problem not a blocker.)
    - 11y ago
rewqfdsa 11y ago
Thanks for ruining my holiday season. What's the precedent situation if they do settle it? Is Oracle's latest victory binding even if the final resolution of the case isn't decided by the court?
- curt15 11y ago
  The federal circuit's opinion concerning the copyrightability of APIs is only binding precedent on the federal circuit itself and only when interpreting 9th circuit law. The FC's usual jurisdiction is over patents, not copyrights, and they only got involved in this case because Oracle originally asserted some patents that failed to find traction. In particular, the real 9th circuit would be free to draw their own conclusions should they hear a future case concerning the copyrightability of interfaces.
pron 11y ago
Or that Google has simply decided to use OpenJDK and abide by its license, an option that has always been open to them (yet they have so far rejected).
- grizzles 11y ago
  This is an interesting comment. GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. But the NOTICE file doesn't say anything about Oracle at all! Nor did they carry over the openjdk LICENSE file, which adds to the mysteriousness. I only did a cursory examination of the commit. Someone please post if I'm wrong about this.
  - pron 11y ago
    > GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. That doesn't work. GPL is divisible (in fact, you can do whatever you want with the code), but the license must be applied to the entire deliverable, up to (excluding) classpath-linking which is explicitly exempted by the OpenJDK license -- so in this case, the whole runtime minus Google-only packages if they're classpath-linked only. My thought was that Google may simply choose to make Android GPL + classpath exception. The reason for not doing so when Android was young (I can only assume) was the fear that phone vendors would balk at a runtime that doesn't let them make proprietary changes (of course, Linux doesn't either, but I guess the thought was that the phone manufacturers are likely to make changes that are closer to the application). But now, given Android's popularity, phone vendors would swallow whatever license Google imposes on them (and would still be free to make proprietary changes to classpath-linked portions of the runtime). This is a win for everyone: Google gets to expend less effort maintaining the runtime, plus they get Oracle off their back (at least for future Android versions); Oracle gets to have Java (or something close enough to it) on lots of smartphones, and the developer community gets to have true Java interop (with all new Java features), and probably a higher-quality runtime. Later, Google would be free (but not compelled, although that depends on a future settlement) to make Android fully Java compliant with one of the Java standards, but that is an orthogonal issue.

0x0 11y ago

Also, why are the two timestamps so far off? Authored in February 2015 (almost a year ago!), but committed only in Nov 2015.

temac 11y ago
Maybe because this has been ready for a long time just in case and they just decided to actually switch to that strategy right now?
deathanatos 11y ago
This is a git repo, so "authored" tries to map to the person who wrote the content, and the "idea" of the commit, if there is such a thing. It's set when the commit is initially created, and for the most part not changed unless explicitly requested. The commit date is the actual time the commit object was made; this can differ if the commit is amended, rebased, cherry-picked, the result of a squash/fixup, etc. If a commit sits on a branch for months, then gets rebased against master, code-reviewed, and merged, those two dates will be significantly different. This usually works as you might expect. If your coworker Joe authors a commit on a branch, and you cherry-pick it onto another branch, that cherry-picked commit is authored by Joe (and the time reflects when Joe authored it) and commited by you (at the time you performed the cherry-pick).
- saurik 11y ago
  First, read my response to the other person who provided a technical answer to this question. https://news.ycombinator.com/item?id=10806642 https://news.ycombinator.com/item?id=10806642 You have gone a little further and provided some general reasons as to "why this might happen", but you still seem to have missed the essence of the question, which was almost certainly more "can someone come up with some guess why, in this particular circumstance, given the theories about this commit being influenced by a settlement of the Oracle lawsuit, this commit was authored in February but only landed in November?".
  - deleted 11y ago
    [deleted]
kazinator 11y ago
This means that a person named Piotr Jastrzebski created a commit in February. This is a different commit based on that one (not in the sense of revision ancestry, but in the sense of rewrite history): this commit is the N-th rewrite of Piotr's Jasterbski's commit, for some N > 0, and the rewriter ("committer") is Narayan Kamath. The rewrite can have different content: for instance, it can be altered to merge against a different parent. An example of a rewrite is a simple cherry-pick (e.g. from one branch to another). All these things are commits. The initial authoring is a commit, and this latest rewrite by a different person is a commit.
- saurik 11y ago
  You have answered how it is possible, not why it happened: that is like someone pointing out that this "mysterious" commit is actually quite easy to explain, as a commit is an object in a git database, and we have all the metadata to see who made this one: I am extremely well aware of how it works (I give lectures at UCSB about git where I start by explaining the internal file formats and work my way up to the various command line tools), but I still found the question here of "why was this authored in February but only landed in November" fascinating, given the speculation about Oracle.

grizzles 11y ago

If this inference is right, I hope this means that Google will enable the web community to use the JVM with or as an alternative to WebAssembly. Hotspot is absolutely incredible technology, and it's competitors are still many years away from coming close to matching it's capabilities.

0x0 11y ago
Embedding the JVM to run code within webpages you say? Hasn't that been tried before? :-S
devsquid 11y ago
I'm all for the JVM but it's too powerful to run arbitrary code man. No JVM in my browser please.
- geofft 11y ago
  The Java plugin's mistake was to embed a rich sandboxing mechanism right in the middle of the language layer. The Java runtime, in the middle of parsing bytecode and registering class hierarchies, is supposed to enforce who can access what things, not simply as an advisory mechanism or safety check (as public/private is just about everywhere else), but as a security mechanism under active assault, with only this single line of defense between untrusted code and full local privileges just like native code. And, like anything with a complicated security policy and a wide attack surface, it had no chance. Stick a regular, unprivileged JVM, with no secure classloader magic, inside a straightforward non-Java low-level sandbox like NaCl or even just PPAPI + Chrome's renderer sandboxing (like Pepper Flash or PDFium) and it'll probably hold up just fine. And honestly that's what Android does. Java isn't a security boundary on Android, and the NDK makes this explicit. Each app runs as its own UID, and the kernel is taught to isolate users a bit more than usual for UNIX, and that holds up pretty well -- not perfect, but far better than the Java plugin does. (To be clear, I'm not advocating the JVM as a platform for web content. Just that, if somehow it turns out that the JVM is in fact the right platform, the sandboxing problem not a blocker.)
  - 11y ago

rewqfdsa 11y ago

Thanks for ruining my holiday season. What's the precedent situation if they do settle it? Is Oracle's latest victory binding even if the final resolution of the case isn't decided by the court?

curt15 11y ago
The federal circuit's opinion concerning the copyrightability of APIs is only binding precedent on the federal circuit itself and only when interpreting 9th circuit law. The FC's usual jurisdiction is over patents, not copyrights, and they only got involved in this case because Oracle originally asserted some patents that failed to find traction. In particular, the real 9th circuit would be free to draw their own conclusions should they hear a future case concerning the copyrightability of interfaces.

pron 11y ago

Or that Google has simply decided to use OpenJDK and abide by its license, an option that has always been open to them (yet they have so far rejected).

grizzles 11y ago
This is an interesting comment. GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. But the NOTICE file doesn't say anything about Oracle at all! Nor did they carry over the openjdk LICENSE file, which adds to the mysteriousness. I only did a cursory examination of the commit. Someone please post if I'm wrong about this.
- pron 11y ago
  > GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. That doesn't work. GPL is divisible (in fact, you can do whatever you want with the code), but the license must be applied to the entire deliverable, up to (excluding) classpath-linking which is explicitly exempted by the OpenJDK license -- so in this case, the whole runtime minus Google-only packages if they're classpath-linked only. My thought was that Google may simply choose to make Android GPL + classpath exception. The reason for not doing so when Android was young (I can only assume) was the fear that phone vendors would balk at a runtime that doesn't let them make proprietary changes (of course, Linux doesn't either, but I guess the thought was that the phone manufacturers are likely to make changes that are closer to the application). But now, given Android's popularity, phone vendors would swallow whatever license Google imposes on them (and would still be free to make proprietary changes to classpath-linked portions of the runtime). This is a win for everyone: Google gets to expend less effort maintaining the runtime, plus they get Oracle off their back (at least for future Android versions); Oracle gets to have Java (or something close enough to it) on lots of smartphones, and the developer community gets to have true Java interop (with all new Java features), and probably a higher-quality runtime. Later, Google would be free (but not compelled, although that depends on a future settlement) to make Android fully Java compliant with one of the Java standards, but that is an orthogonal issue.