So is the major advantage of Eddystone that Google will implement it and won't sue you for using it in ways they don't like?
Eddystone isn't alone; there's AltBeacon, which is also an 'open' alternative: http://altbeacon.org/ Though it looks like they might be 'merging' with Eddystone.
AltBeacon was born out of Apple giving Radius Networks a cease & desist about a year ago for reverse-engineering the iBeacon protocol and distributing an open-source Android toolkit (with paid enhancements) for iBeacons: http://beekn.net/2014/07/ibeacon-for-android/
The Android iBeacon code used to be on Github but is no longer there. IMO the core "infringement" (if there really is any) is about 10-20 lines of Java that unpacks an iBeacon (major, minor, uuid) from a byte buffer and another bit of Java that aims to map RSSI to Apple's simple model for estimating iBeacon distances. The library did wrap the functionality in a nice background-threaded interface, and their API is distinct from Apple's. On the iPhone, there's a BLE daemon that powers iBeacon and is rather crashy (at least as of iOS8). The Radius Networks solution was clearly distinct. The story would be a textbook example of Apple's legal department hurting open innovation except for the detail that Radius Networks was offering a paid developer product atop the open source offering. (But I doubt they were making much money from it).
There are a lot of problems with iBeacon technology:
* A lot of people have bluetooth off. The surveys out there have a lot of variance, and you typically have a 50/50 chance that a user with a very modern smartphone will have BLE enabled.
* Droid battery usage isn't too bad, but Apple's solution has a distinct advantage because the BLE daemon powering the feature can interop more closely with iOS and eat less CPU. It's really hard to get a consistent experience on both platforms.
* To do anything productive with the iBeacon (major, minor, UUID), you probably want to ping a webservice, which will be hard unless you have free wifi or you've made fancy deals with carriers (or Apple). And if there's wifi, you might as well just try to use that as a beacon (ala PayPal's product).
* You probably /dont/ want to have iBeacons trigger any sort of immediate advert or notification unless the user has previously opted in to the service. A lot of users are starting to not grant notification and other privs by default. Most users also do NOT like background location stuff. There are definitely user segments that differ, but you'll likely need to do a great deal of customer research to validate using iBeacon. If your app is payments, there's already NFC. If your app is marketing, you might get higher engagement with Augmented Reality or something tied to some other location service (ala Amex & 4sq).