4 ms·

Rebuilding Android proprietary SDK binaries

44 points by edward 11y ago

Zigurd 11y ago
This is really unfortunate. I can understand that Google, who are probably paying some fairly serious money to Jetbrains for a vastly improved toolchain, feel that it is competely fair to lock Amazon and other (mother) forkers out of the toolchain they are paying to get. But this does give a lot of ammuniation to those who claim Android isn't really open. It had been a clear defense against anti-trust litigation: Android is open, and those who want to use Android, like Amazon, are on an even footing. That's still technically correct, but it's not true in practice. This is much worse than Google Play Services, which is only a clear boundary between open Android and Google's ecosystem.
DannyBee 11y ago
"(Incidentally, if Google wanted SDK forks to spread and increase fragmentation, introducing an obnoxious EULA is probably the first thing I'd have recommended. What was its legal team thinking?)" (I'm a bit biased here, of course, and this is my personal opinion) I would actually expect it will have the opposite effect. The fragments already existed. They existed, in part, because it was cheap and easy to freeload on Google's SDK. You could just take it and modify it in incompatible ways and it cost you basically nothing to maintain that. See, for example, the amazon fire stuff, which was already a fragment, which basically used to say "download the google sdk and do this to that". Now they can't do that. They either have to become more compatible (which they did), or spend time producing their own SDK and tools. IE it increased the cost of forking and fragmenting, not decreased it. I also don't think the last sentence represents a good understanding of how legal teams work.
- tadfisher 11y ago
  The terms don't say you can't produce software destined for a fork of Android, they say you can't fork the SDK tools themselves. Amazon was never in violation of these terms, and save for Google's proprietary SDKs (Play Services), Fire OS has always been fully API-compatible and "binary-compatible" (in the bytecode sense) with the Android platform release it is built upon. Amazon has never distributed the Android SDK tools, let alone forked them. So I guess I'm not sure what this example proves.
  - DannyBee 11y ago
    Sadly, i can't comment on pretty much any of what you've written, as you've phrased it in a way that would require discussing matters i've given legal advice about.

44 points by edward 11y ago

This is really unfortunate. I can understand that Google, who are probably paying some fairly serious money to Jetbrains for a vastly improved toolchain, feel that it is competely fair to lock Amazon and other (mother) forkers out of the toolchain they are paying to get. But this does give a lot of ammuniation to those who claim Android isn't really open. It had been a clear defense against anti-trust litigation: Android is open, and those who want to use Android, like Amazon, are on an even footing. That's still technically correct, but it's not true in practice. This is much worse than Google Play Services, which is only a clear boundary between open Android and Google's ecosystem.

DannyBee 11y ago

"(Incidentally, if Google wanted SDK forks to spread and increase fragmentation, introducing an obnoxious EULA is probably the first thing I'd have recommended. What was its legal team thinking?)" (I'm a bit biased here, of course, and this is my personal opinion) I would actually expect it will have the opposite effect. The fragments already existed. They existed, in part, because it was cheap and easy to freeload on Google's SDK. You could just take it and modify it in incompatible ways and it cost you basically nothing to maintain that. See, for example, the amazon fire stuff, which was already a fragment, which basically used to say "download the google sdk and do this to that". Now they can't do that. They either have to become more compatible (which they did), or spend time producing their own SDK and tools. IE it increased the cost of forking and fragmenting, not decreased it. I also don't think the last sentence represents a good understanding of how legal teams work.

tadfisher 11y ago
The terms don't say you can't produce software destined for a fork of Android, they say you can't fork the SDK tools themselves. Amazon was never in violation of these terms, and save for Google's proprietary SDKs (Play Services), Fire OS has always been fully API-compatible and "binary-compatible" (in the bytecode sense) with the Android platform release it is built upon. Amazon has never distributed the Android SDK tools, let alone forked them. So I guess I'm not sure what this example proves.
- DannyBee 11y ago
  Sadly, i can't comment on pretty much any of what you've written, as you've phrased it in a way that would require discussing matters i've given legal advice about.