Some folks have a problem with the terms of service for Google Drive. Solution: Don't use Google Drive. To inhibit your search results by switching to an inferior search engine because you don't like the terms of service for Google Drive is silly.
I personally believe the purpose of those "derivative works" terms are to enable services like Translate and ad targeting. But since those terms do grant Google rights to use my IP, I will choose not to use Google Drive. Google, of course, will not change their direction based on my decision, nor do I view my decision as a protest. Anyway, DropBox works better!
The key is "When I give information to Google..." Describing a service as "external storage" should not mean "giving it away". Perhaps a better analogy: a bank pays interest on your account (because they use the money while you're not using it) and charges you for a safe deposit box (because it's secured to you under their protection). They're describing this service as a safe deposit, but treating it as an account.
I think the T&Cs come out the way they are because of the vast array of services that Google has. Suppose you put some stuff on GDrive and give a few people access to it. Suppose some of them don't speak English. These T&Cs will allow Google to automatically offer translation for those users with no risk to Google. Of course such a translation creates a "derivative work", no? The T&Cs are needed because Google doesn't want claims that people's data was exposed to parts of Google's infrastructure that they didn't want. I see it as driven by Google's desire to make data useful for the user and protecting Google from lawsuits that might otherwise arise. Of course you can choose to see it differently, but in the CYA-land of lawyers, the words are simply going to be over-broad, especially if it is kept short enough for people to actually read. I don't see anything necessarily sinister here, but I can see where some would feel differently.
I do like the fact that Google seems to have attempted to put its terms and conditions into actual human readable language. But what they claim rights to is rather onerous. I can certainly imagine that their intentions are not to do anything that a user would be uncomfortable with. The problem comes in with the definition of "what a user would be comfortable with."
It can be pretty easy for a company to self-justify (either intentionally or unintentionally) a gradual slide from fair and ethical to exploitative use of personal data.
When I post something on EEtimes or in fact any other publication site, I do it knowing that it will be shared with other people. That is the point! Of course I will give them the right to reproduce, reuse or make derivatives from it. So long as they continue to credit me, then it is to my benefit. When I give information to Google, it is personal, private information that I have not chosen to share with anyone. They should have no rights to use it.
Mr Bailey is just too funny. He doesn't have a clue. I suggest he read the TOS from Amazon.com:
and finally the TOS from EE Times:
hint fo Brian: search for "derivative"
Is it a rule of life? That most of people and therefore, institutions deviate from the original target or goal... is "don't do evil" lost?
It is perhaps the need to earn the force behind the deviation.
After all Google, as cool as it is/was, is still a company which has to profit. Of course, doesn't mean anyway they can is alright.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.