A Google employee's critique of the Ars Technica Android unforkable article(arstechnica.com)
arstechnica.com
A Google employee's critique of the Ars Technica Android unforkable article
http://arstechnica.com/information-technology/2014/02/neither-microsoft-nokia-nor-anyone-else-should-fork-android-its-unforkable/?comments=1&post=26199423
12 comments
I'd love to think they would be better off, but I assume their analytics are telling them right now that cheap trolling increases ad impressions more than journalistic hard work.
I would hope that Ars' editorial staff realizes that short term gains at the cost of long term losses is not worth it.
Then again, this is hardly the first P.B. story that's caused controversy and caused Ars readership/legitimacy, so I am probably wrong.
Then again, this is hardly the first P.B. story that's caused controversy and caused Ars readership/legitimacy, so I am probably wrong.
Sometimes I feel like the whole internet will eventually turn into Gawker clones.
While differing in nitty-gritty details, the googler basically confirms what I interpreted to be the main thrust of the Ars article.
AOSP is the carrot, the compliance necessary for google's value add software is the stick.
The last paragraph concludes saying that Android with google apps is the least bad offering out there. That's why I both use it personally, and why I'm not super pumped about the future of any mobile platform these days.
AOSP is the carrot, the compliance necessary for google's value add software is the stick.
The last paragraph concludes saying that Android with google apps is the least bad offering out there. That's why I both use it personally, and why I'm not super pumped about the future of any mobile platform these days.
> AOSP is the carrot, the compliance necessary for google's value add software is the stick.
"Because cloud!" seems to be the answer to most of the points raised in the original article, which kinda sounds ok on the face of it; but why can't those backend services be abstracted out as well? Why shouldn't I be able to choose some other provider for all these services, like location?
It reminds me of a commonly suggested solution to the browser wars in the 90s, when the reasoning for Microsoft's integration of IE directly into the OS was all the new possibilities from such deep integration: why not just allow different browsers/engines (e.g. mozilla) to be swapped in? Well, because then you wouldn't be using MS products anymore!
And I think a lot of that is repeating itself here.
"Because cloud!" seems to be the answer to most of the points raised in the original article, which kinda sounds ok on the face of it; but why can't those backend services be abstracted out as well? Why shouldn't I be able to choose some other provider for all these services, like location?
It reminds me of a commonly suggested solution to the browser wars in the 90s, when the reasoning for Microsoft's integration of IE directly into the OS was all the new possibilities from such deep integration: why not just allow different browsers/engines (e.g. mozilla) to be swapped in? Well, because then you wouldn't be using MS products anymore!
And I think a lot of that is repeating itself here.
The location example is bothersome, but the point about 4.4 adding the storage API to enable Dropbox (a competitor) access to apps and the systems in precisely the same way as Google Drive does demonstrate they aren't nearly as closed as many like to portray them as being. Android has the most pervasive mechanisms of this kind of any widespread system, and the best approach for adding them with applications. This is, by far, the single most underappreciated part of the platform, including by many Googlers outside the Android team.
That said, it pisses me off violently that to get weather from a non-Google source my device still insists that Google get my location data. The location system very much should be pluggable, and it doesn't present the kind of technical hurdles stuff like a generic purchasing API (discussed elsewhere) would.
That said, it pisses me off violently that to get weather from a non-Google source my device still insists that Google get my location data. The location system very much should be pluggable, and it doesn't present the kind of technical hurdles stuff like a generic purchasing API (discussed elsewhere) would.
If you make your own location provider, Google will call you non-compatible and not let you have the Google Play store. They consider users using someone else's location services to be terrible for their company, as per internal emails:
http://www.engadget.com/2011/05/10/internal-emails-reveal-go...
> Why shouldn't I be able to choose some other provider for all these services, like location?
You can, just provide an implementation of LocationProvider: http://developer.android.com/reference/android/location/pack...
You can, just provide an implementation of LocationProvider: http://developer.android.com/reference/android/location/pack...
The problem is Google wrapping those in such a way that sends them the data of the underlying sensors before reporting up the stack to the requesting app. They (rightly) point out this enables different sorts of location stuff, like the network parts, but it doesn't allow you to say to the Google Services I only want you using GPS, and no you can't report back without that whole layer becoming completely unusable, unless the app developer wrote it for the lower level stuff before and manually bypasses it in the case they detect Google's service is disabled.
Why do you want to skip the sensor fusion step? The entire point is it gives you more accurate data.
Because I don't trust Google with this data, and will sacrifice battery life and accuracy to prevent them having it. Frankly the weather is the same for a few hundred metres around me in each direction!
They proved with the WiFi slurping on Street View cars they can't be trusted with this stuff at all.
They proved with the WiFi slurping on Street View cars they can't be trusted with this stuff at all.
Settings > Location > Mode > Select "Device Only"
and
Settings > WiFi > Advanced > Uncheck "Scanning always available" (which asked for permission on first boot)
These are user settings, not app settings.
and
Settings > WiFi > Advanced > Uncheck "Scanning always available" (which asked for permission on first boot)
These are user settings, not app settings.
On my devices doing the first causes apps using the Google Play Services to report that you've disabled the location service completely, while the direct GPS based apps continue just fine.
The broader point here is wanting to be able to remove Google's service software from the equation, and run only code you can actually inspect the contents of for this kind of data. To be honest those apps having direct GPS access isn't ideal either and this should all be proxied through a standardised open source app on the device.
The broader point here is wanting to be able to remove Google's service software from the equation, and run only code you can actually inspect the contents of for this kind of data. To be honest those apps having direct GPS access isn't ideal either and this should all be proxied through a standardised open source app on the device.
On a Nexus 5 doing the first doesn't change anything for me; it's just less accurate (I did so, then opened up Google Maps to double check).
But you're going to have to define what you mean by "Google code", because ostensibly all of Android is "Google code". Doing what I outlined above will stop it from going through any form of sensor fusion. If you want to remove Google's service software then just create a build without Play Services on it, it's that simple. AOSP boots, on the Nexus devices at least, without it, so it's easy to do and gets you exactly what you want.
So really I guess I'm saying: What else do you want? Remove Play Services, the Google Apps, etc, using an AOSP based build and you get a Google free phone.
But you're going to have to define what you mean by "Google code", because ostensibly all of Android is "Google code". Doing what I outlined above will stop it from going through any form of sensor fusion. If you want to remove Google's service software then just create a build without Play Services on it, it's that simple. AOSP boots, on the Nexus devices at least, without it, so it's easy to do and gets you exactly what you want.
So really I guess I'm saying: What else do you want? Remove Play Services, the Google Apps, etc, using an AOSP based build and you get a Google free phone.
Also the argument: the cloud is proprietary so the app is as well.
If the cloud part is the hard part to implement why not make the app open source ?
If the cloud part is the hard part to implement why not make the app open source ?
This. There will continue to be improvements to AOSP, but only as that makes driving Google's proprietary apps easier and faster.
Its exactly like Chromium in other words and we see that with Blink.
Its exactly like Chromium in other words and we see that with Blink.
> This. There will continue to be improvements to AOSP, but only as that makes driving Google's proprietary apps easier and faster.
This isn't remotely true, work continues on the platform in a number of areas beyond just feature requests from other teams. Having application teams able to explain the pain points they feel in the platform and then having the platform team come up with solutions that work for the general use case is a good thing though, it improves everybody's experience. It isn't like there are hidden "makeGmailFaster" APIs that other people can't use.
This isn't remotely true, work continues on the platform in a number of areas beyond just feature requests from other teams. Having application teams able to explain the pain points they feel in the platform and then having the platform team come up with solutions that work for the general use case is a good thing though, it improves everybody's experience. It isn't like there are hidden "makeGmailFaster" APIs that other people can't use.
Yeah, it reads more like an explanation than a rebuttal.
No it doesn't, I have no idea how such utter rot makes it onto HN.
Peter is a tabloid journalist, he stopped writing interesting balanced articles a long time ago and now just posts linkbait.
His points are thoroughly refuted, but I guess you didn't bother to read them.
Peter is a tabloid journalist, he stopped writing interesting balanced articles a long time ago and now just posts linkbait.
His points are thoroughly refuted, but I guess you didn't bother to read them.
I've said it before, but it really strikes me that Ars simply don't understand the universe outside of Wintel at all, and this deconstruction is merely one of many you can do whenever they start commenting about stuff outside of that sphere. You could get away with being a tech commentator like that for a long time, but not anymore.
> but it really strikes me that Ars simply don't understand the universe outside of Wintel at all
Doesn't Ars publish the most detailed review of every new Mac OS? I also notice quite a lot of the technical articles I submit to HN from Ars are quite detailed and truthful.
Doesn't Ars publish the most detailed review of every new Mac OS? I also notice quite a lot of the technical articles I submit to HN from Ars are quite detailed and truthful.
I don't understand how this is even a discussion.
Not only is AOSP completely open and forkable, THERE IS A COMMERCIALLY SUCCESSFUL ANDROID FORK OUT THERE - and it's called Kindle Fire OS.
The existence of this conversation, this "controversy," is confusing to me.
Not only is AOSP completely open and forkable, THERE IS A COMMERCIALLY SUCCESSFUL ANDROID FORK OUT THERE - and it's called Kindle Fire OS.
The existence of this conversation, this "controversy," is confusing to me.
Peter Bright gives a very good comeback to the statements that the google employee made.
With Android 4.4 I felt disappointed that it was just an excuse to integrate more the platform to google services, so, google become the real an unquestionable controller of Android.
The "Android is an open platform" is just a fallacy.
With Android 4.4 I felt disappointed that it was just an excuse to integrate more the platform to google services, so, google become the real an unquestionable controller of Android.
The "Android is an open platform" is just a fallacy.
> The "Android is an open platform" is just a fallacy.
No it isn't, you're just lying. The response lays out in detail how Android (ie AOSP) is more open than any alternative.
Stop talking crap.
No it isn't, you're just lying. The response lays out in detail how Android (ie AOSP) is more open than any alternative.
Stop talking crap.
Being "more open" than the alternatives doesn't make it "open".
You're right. Being Apache licensed makes it open. Therefore it's open.
There are Apache- and other permissive licensed parts in iOS - so iOS is "open platform"?
No, because iOS is not Apache licensed. You're obviously a troll account though so you know, try harder.
But Android is not Apache licensed, only some parts, like in iOS. You know it and you still lying.
It's not like iOS, and I expect you'll end up banned soon enough for trolling, so just give up.
Android is AOSP. AOSP is Apache. https://source.android.com/
QED.
Android is AOSP. AOSP is Apache. https://source.android.com/
QED.
> Android is AOSP
No, Android is AOSP + GMS, googleliar.
No, Android is AOSP + GMS, googleliar.
'googleboy' and 'googleliar' aren't really good insults, I'm not a Google employee.
You might buy an Android with GMS, but you might buy one with Amazon's framework, or none whatsoever. It's down to the manufacturer and distributor of the device you purchase.
You might buy an Android with GMS, but you might buy one with Amazon's framework, or none whatsoever. It's down to the manufacturer and distributor of the device you purchase.
dammit, when did trolls like this make their way to HN?
> AOSP ... is more open
AOSP is not an Android, stop lying, googleboy.
AOSP is not an Android, stop lying, googleboy.
Yes it is. I'm not a Google employee, although I would be if I could because at least they're doing interesting stuff.
> With Android 4.4 I felt disappointed that it was just an excuse to integrate more the platform to google services, so, google become the real an unquestionable controller of Android.
What parts of the platform became more proprietary in 4.4? The only thing I can think of is Hangouts for SMS, but even then the SMS app still works and is updated to use the new messaging APIs introduced in KK, it just isn't the default on Nexus devices any more.
What parts of the platform became more proprietary in 4.4? The only thing I can think of is Hangouts for SMS, but even then the SMS app still works and is updated to use the new messaging APIs introduced in KK, it just isn't the default on Nexus devices any more.
Google music, the camera, etc.., you need really need to inform your self.
> Google music, the camera, etc.., you need really need to inform your self.
Music and Camera are still in the AOSP tree, just not Google Music and not all of the fancy camera features. Besides, neither of these changes happened in 4.4. The proprietary music app has been around for a couple years now, and Photosphere has never been in the AOSP version of the camera, which has been out for a couple years as well.
Music and Camera are still in the AOSP tree, just not Google Music and not all of the fancy camera features. Besides, neither of these changes happened in 4.4. The proprietary music app has been around for a couple years now, and Photosphere has never been in the AOSP version of the camera, which has been out for a couple years as well.
Are there, but now Google has departed from them, it will be considered like second class citizens, you really need to read Peter's Bright response.
I've read it, but my point is none of this got more proprietary in 4.4, which is the line I quoted and refuted. Cloud services have always been proprietary because it costs money to run them.
If you want to complain that not everything in Android is completely open source, including the cloud services part, that's a different issue. But many of Peter Bright's complaints are just plain wrong:
> The non-Gmail e-mail client has a poor reputation in this regard.
Both it and GMail are based on the same code base, UnifiedEmail, which is maintained: https://android.googlesource.com/platform/packages/apps/Unif...
> Right; you can use forks of some of the apps because Google hasn't done a very good job of maintaining the AOSP ones. Which is... what I said.
Yeah, and people are forking Linux because it isn't well maintained. Oh, no wait, people are forking Linux because that's one of the main ideas behind open source software: you can fork it and make it do what you want.
> Sure, except neither of those fulfils the contract of the API. They might be good enough, but if an app has a button that says "share this on G+" and it ends up sharing on Facebook instead, that'd be a little weird, don't you think?
This isn't how the sharing API works at all, and he's clearly never used it. All you do is add a ShareActionProvider to your ActionBar and it works with anything that supports the sharing intent. You don't say "I can share with G+, or Facebook, or..." like he seems to think. (http://developer.android.com/training/sharing/shareaction.ht...)
> What on earth are you talking about? You're railing against strawmen.
No, this isn't a strawman, she's refuting exactly what he said. The Android platform has standards and you have to stick to them, just like any other platform you want to base yourself on if you want to be compatible. The APIs happen to be the standard for Android. Without them there would be no compatibility between various Android distributions. You can, of course, always add additional APIs on top, which is exactly what Samsung, Motorola, etc. do with their SDK add-ons. Really though, you can't complain that "[a]ny platform using Android in this way would have only a limited ability to take the platform in a different direction from the one Google chose" because "[v]arious aspects of how Android is used are determined by the underlying APIs", and then complain they don't provide an API for other, more proprietary things like an IAP system ("Why not ship an IAP system that has code that defaults to using Google's services on the back-end, but could be swapped out without breaking apps"). This point is total insanity by Peter.
> Read Ben Evans' piece on how Microsoft should relegate Android to being nothing more than a stack of debugged device drivers. Sure, you might take bits of Google's userland too.
This is exactly what FirefoxOS and Ubuntu Touch did to bootstrap. They both took the Android kernel, the input system, etc. So clearly it works, and I think is a much more interesting use of the platform than just taking the whole thing and slapping some new paint on it; why would I use that over stock Android?
If you want to complain that not everything in Android is completely open source, including the cloud services part, that's a different issue. But many of Peter Bright's complaints are just plain wrong:
> The non-Gmail e-mail client has a poor reputation in this regard.
Both it and GMail are based on the same code base, UnifiedEmail, which is maintained: https://android.googlesource.com/platform/packages/apps/Unif...
> Right; you can use forks of some of the apps because Google hasn't done a very good job of maintaining the AOSP ones. Which is... what I said.
Yeah, and people are forking Linux because it isn't well maintained. Oh, no wait, people are forking Linux because that's one of the main ideas behind open source software: you can fork it and make it do what you want.
> Sure, except neither of those fulfils the contract of the API. They might be good enough, but if an app has a button that says "share this on G+" and it ends up sharing on Facebook instead, that'd be a little weird, don't you think?
This isn't how the sharing API works at all, and he's clearly never used it. All you do is add a ShareActionProvider to your ActionBar and it works with anything that supports the sharing intent. You don't say "I can share with G+, or Facebook, or..." like he seems to think. (http://developer.android.com/training/sharing/shareaction.ht...)
> What on earth are you talking about? You're railing against strawmen.
No, this isn't a strawman, she's refuting exactly what he said. The Android platform has standards and you have to stick to them, just like any other platform you want to base yourself on if you want to be compatible. The APIs happen to be the standard for Android. Without them there would be no compatibility between various Android distributions. You can, of course, always add additional APIs on top, which is exactly what Samsung, Motorola, etc. do with their SDK add-ons. Really though, you can't complain that "[a]ny platform using Android in this way would have only a limited ability to take the platform in a different direction from the one Google chose" because "[v]arious aspects of how Android is used are determined by the underlying APIs", and then complain they don't provide an API for other, more proprietary things like an IAP system ("Why not ship an IAP system that has code that defaults to using Google's services on the back-end, but could be swapped out without breaking apps"). This point is total insanity by Peter.
> Read Ben Evans' piece on how Microsoft should relegate Android to being nothing more than a stack of debugged device drivers. Sure, you might take bits of Google's userland too.
This is exactly what FirefoxOS and Ubuntu Touch did to bootstrap. They both took the Android kernel, the input system, etc. So clearly it works, and I think is a much more interesting use of the platform than just taking the whole thing and slapping some new paint on it; why would I use that over stock Android?
Camera, music et al still are on the AOSP tree. Perhaps the one that needs to inform himself is not him, but you.
Read Peter's Bright response, the answer is there,
Really, Peters response is wrong, fracking apps are there for anyone to take.
But as you take him as if has written the Bible and take all of his words as The Truth it is just a waste of time trying to argue.
If at least he knew just a little of Android perhaps he would write something that it is not utterly wrong
But as you take him as if has written the Bible and take all of his words as The Truth it is just a waste of time trying to argue.
If at least he knew just a little of Android perhaps he would write something that it is not utterly wrong
I don't think he is utterly wrong, he gave pretty good arguments, and many concur with him.
The real issue is that the open source world doesn't have an answer to the rise of the cloud. As the integration of the phone and the cloud becomes more central, it becomes impossible for open source to provide a matching experience. The open source movement was born when the pendulum was swinging from the centralized mainframe to the PC revolution. But now as the pendulum is swinging back to centralized computing there will be fewer chances for small individualistic rebels to make an impact.
> The real issue is that the open source world doesn't have an answer to the rise of the cloud.
Nonsense. you're speaking as though open-source and cloud storage are somehow related or in competition. But they're orthogonal -- one can obviously make open-source applications available from the cloud, and you can construct the cloud's infrastructure out of open-source elements.
> The open source movement was born when the pendulum was swinging from the centralized mainframe to the PC revolution.
That's true, but the two were coincidental and unrelated. Correlation doesn't prove causation.
> But now as the pendulum is swinging back to centralized computing there will be fewer chances for small individualistic rebels to make an impact.
Wait, what? How does open-source relate to centralized computing? For that matter, how does cloud storage relate to centralized computing? It's not as though cloud storage requires a central repository, any more than the Internet must be a central repository in order to function.
Just one example: Linux (a) dominates the Internet's servers and (b) is open-source.
Nonsense. you're speaking as though open-source and cloud storage are somehow related or in competition. But they're orthogonal -- one can obviously make open-source applications available from the cloud, and you can construct the cloud's infrastructure out of open-source elements.
> The open source movement was born when the pendulum was swinging from the centralized mainframe to the PC revolution.
That's true, but the two were coincidental and unrelated. Correlation doesn't prove causation.
> But now as the pendulum is swinging back to centralized computing there will be fewer chances for small individualistic rebels to make an impact.
Wait, what? How does open-source relate to centralized computing? For that matter, how does cloud storage relate to centralized computing? It's not as though cloud storage requires a central repository, any more than the Internet must be a central repository in order to function.
Just one example: Linux (a) dominates the Internet's servers and (b) is open-source.
"Just one example: Linux (a) dominates the Internet's servers and (b) is open-source."
...and untold millions of lines of changes to the Linux kernel are kept secret and are not at all available to other Linux users or even to Linux contributors. That is exactly the sort of the thing the GPL was meant to prevent.
Furthermore, while it is true that quite a bit of web services and "cloud computing" was built with free software, the effect is very different than distributing free software on desktops. If you do not like some new feature of the Linux kernel, you can just not use it -- nobody forces you to upgrade, and in extreme cases it is possible to fork the project. On the other hand, if you do not like a new feature in Facebook...tough luck, you have no authority. Similarly, if you want a new feature in the Linux kernel, you can add it -- maybe Linus won't merge it with the official source, but you can still have the feature and distribute it to others. Your next great idea for a GMail feature is irrelevant, because you cannot add features to GMail.
...and untold millions of lines of changes to the Linux kernel are kept secret and are not at all available to other Linux users or even to Linux contributors. That is exactly the sort of the thing the GPL was meant to prevent.
Furthermore, while it is true that quite a bit of web services and "cloud computing" was built with free software, the effect is very different than distributing free software on desktops. If you do not like some new feature of the Linux kernel, you can just not use it -- nobody forces you to upgrade, and in extreme cases it is possible to fork the project. On the other hand, if you do not like a new feature in Facebook...tough luck, you have no authority. Similarly, if you want a new feature in the Linux kernel, you can add it -- maybe Linus won't merge it with the official source, but you can still have the feature and distribute it to others. Your next great idea for a GMail feature is irrelevant, because you cannot add features to GMail.
> ...and untold millions of lines of changes to the Linux kernel are kept secret ...
Are you serious? The entire Linux kernel is open-source and public (and it is available here: https://www.kernel.org/). Most programs delivered along with the kernel are also open-source. Many Linux distributors of large assemblages of code refuse to include anything that isn't open-source.
Are you serious? The entire Linux kernel is open-source and public (and it is available here: https://www.kernel.org/). Most programs delivered along with the kernel are also open-source. Many Linux distributors of large assemblages of code refuse to include anything that isn't open-source.
You are ignoring the long list of companies that modify the Linux kernel for their own purposes, never releasing their changes, and sometimes using their modified kernel on a web server that runs web apps for their users. As long as they are not distributing their modified kernel to anyone they can keep their changes secret.
If the GPL was, as you claim, meant to keep that from happening, why is it totally permissible by the GPL?
For the same reason the GPLv2 has nothing to say about patents, even though patents are used to do the kinds of things the GPL was meant to prevent.
The thing to keep in mind is that the changes that web companies make to free software are not usually for internal consumption. The changes are user-facing -- but the software is delivered via the web, rather than distributed to the users, and so the web company never triggers any requirement to make their changes available. The GPL does allow this, but it is not in the spirit of the GPL, and the Affero GPL was created to deal with this problem.
The thing to keep in mind is that the changes that web companies make to free software are not usually for internal consumption. The changes are user-facing -- but the software is delivered via the web, rather than distributed to the users, and so the web company never triggers any requirement to make their changes available. The GPL does allow this, but it is not in the spirit of the GPL, and the Affero GPL was created to deal with this problem.
I'm not sure that's true (I'm not the most knowledgeable person when it comes to the exact specifics of the GPL). Without institutions protecting IP (like patents, trademarks, copyright) the GPL couldn't exist, it's just a hack on top of IP.
I agree that it's not in the spirit of the GPL, but they did explicitly not add in sections about that in the GPLv3. The v2 FAQ mentioned that they were considering adding in web-based applications, but the v3 FAQ says it's still okay, but if you're writing software and want to make it not okay, use the AGPL.
I agree that it's not in the spirit of the GPL, but they did explicitly not add in sections about that in the GPLv3. The v2 FAQ mentioned that they were considering adding in web-based applications, but the v3 FAQ says it's still okay, but if you're writing software and want to make it not okay, use the AGPL.
> You are ignoring the long list of companies that modify the Linux kernel for their own purposes ...
No, I'm addressing your prior claim that the Linux kernel is not open-source. The claim is false.
Also, companies that change the kernel, and then release their changed kernels, cannot do so without also releasing their source.
The claim is false, in whatever form it takes.
No, I'm addressing your prior claim that the Linux kernel is not open-source. The claim is false.
Also, companies that change the kernel, and then release their changed kernels, cannot do so without also releasing their source.
The claim is false, in whatever form it takes.
I never claimed that, read my post again.
> I never claimed that, read my post again.
I did. Here is what you said:
> ...and untold millions of lines of changes to the Linux kernel are kept secret and are not at all available to other Linux users or even to Linux contributors. That is exactly the sort of the thing the GPL was meant to prevent.
It's false. Code that is modified and then never released is not what the GPL was meant to prevent.
I did. Here is what you said:
> ...and untold millions of lines of changes to the Linux kernel are kept secret and are not at all available to other Linux users or even to Linux contributors. That is exactly the sort of the thing the GPL was meant to prevent.
It's false. Code that is modified and then never released is not what the GPL was meant to prevent.
It is not false in the context of the web being built on free software. The GPL is meant to prevent a situation where free software is used to create proprietary software that denies its users their freedom. In the case of web companies modifying free software and presenting their modified software to users as a web app, that is exactly what happens, and it is only because of a loophole that it does happen. The Affero GPL was created to address this particular loophole.
Along with the point you've just made, I thought about this after my last post, related to the difference between a tablet and the cloud. If a company changes the Linux kernel or an open-source application and includes it in their mobile device, they have to release the source on demand. As intended. (And there have been a number of high-profile cases in which companies tried to avoid releasing source.)
But if they change the Linux kernel or an open-source server utility and put it on their cloud server, they don't. An unintended outcome, and one that makes the cloud different than what came before it.
So I concede that the cloud is different, and it does affect the idea of open-source.
The line is drawn if and when a client machine downloads an open-source app from the cloud. If that never happens, then there's no requirement to release source.
But if they change the Linux kernel or an open-source server utility and put it on their cloud server, they don't. An unintended outcome, and one that makes the cloud different than what came before it.
So I concede that the cloud is different, and it does affect the idea of open-source.
The line is drawn if and when a client machine downloads an open-source app from the cloud. If that never happens, then there's no requirement to release source.
> ...and untold millions of lines of changes to the Linux kernel are kept secret and are not at all available to other Linux users or even to Linux contributors
Kept secret by whom?
Kept secret by whom?
By the people who made the changes but never had to release them, by NDAs that people sign before they work for web companies, etc. There is nothing in the GPLv2 that says, "All your changes must be released." What it says is that if you give a modified version to another person, your changes must be GPL'd also. Since web companies do not give modified versions of the kernel to others, they are not in any way obligated to make their changes available to others, and more often than not they do not make those changes available.
> By the people who made the changes but never had to release them, by NDAs that people sign before they work for web companies, etc.
This is complete nonsense. There is no proprietary, closed-source code in the Linux kernel.
This is complete nonsense. There is no proprietary, closed-source code in the Linux kernel.
Remember, recipients of GPL code (companies in this case) are not affected by the terms of the GPL until they redistribute the code themselves, until then they can add proprietary code all they want, run it on servers and never release a thing. They are completely free to USE the code however they wish.
So in this example, no cloud company has to release changes to their running linux kernel because it was never distributed to end users, or at all.
Same for all other GPL code running on servers, users of the service, loading web pages and using APIs, are not recipients of the code under the GPL, so they have no rights under the license.
If some company decides their changes to the kernel, or nginx, or apache, or php can be released because it won't destroy their business, they frequently do so. Otherwise you'll never hear about it and changes silently remain secret.
So in this example, no cloud company has to release changes to their running linux kernel because it was never distributed to end users, or at all.
Same for all other GPL code running on servers, users of the service, loading web pages and using APIs, are not recipients of the code under the GPL, so they have no rights under the license.
If some company decides their changes to the kernel, or nginx, or apache, or php can be released because it won't destroy their business, they frequently do so. Otherwise you'll never hear about it and changes silently remain secret.
No, there is no proprietary code in the official kernel as distributed on kernel.org. There is a very long list of companies that have their own version of the kernel, which they keep to themselves, which contains their own proprietary changes, and which they never distribute to anyone else. There is no requirement whatsoever that you give your changes to Linux to anyone, there is only a requirement that your changes be GPL'd if you do choose to distribute them.
Feel free to change the subject, but don't pretend you're addressing the original topic, which is whether the Linux kernel is or is not open-source.
There are two free software answers to "the cloud:"
1. Open APIs that allow useful, meaningful, and complete interoperability between different services and local software. This is a compromise that allows cloud services to continue to be proprietary while not locking users in to any one particular service or platform.
2. The Affero GPL, which requires service providers to make their source available to their users.
Personally I think that (1) is not only a more realistic option, but in the long run a more beneficial option for users.
1. Open APIs that allow useful, meaningful, and complete interoperability between different services and local software. This is a compromise that allows cloud services to continue to be proprietary while not locking users in to any one particular service or platform.
2. The Affero GPL, which requires service providers to make their source available to their users.
Personally I think that (1) is not only a more realistic option, but in the long run a more beneficial option for users.
1. Open APIs that allow useful, meaningful, and complete interoperability between different services
Also: competition. A lot of people only put up with things Facebook, Google, and Apple get up to because they feel there's no viable alternative that meets their needs. A climate that fosters competition better will encourage upstarts.
Also: competition. A lot of people only put up with things Facebook, Google, and Apple get up to because they feel there's no viable alternative that meets their needs. A climate that fosters competition better will encourage upstarts.
"how would you propose that in-app purchasing not go through GMS? Some general platform API to allow the app to do an in-app purchase with whoever wants to be a “purchase provider?”"
Actually, yes. That is how I would propose that an in-app purchasing system not go through GMS.
Actually, yes. That is how I would propose that an in-app purchasing system not go through GMS.
That was my first thought too, but there's big problems with that if you think about it for a while.
Say they did something like that. Now, I am going to build my own "purchase provider" that just says I paid without ever charging anything. How are you going to stop me from doing that? Somebody would have to authenticate "purchase providers" as actually charging money and paying it to the developer. Either you'd have to manually embed keys for authorized providers in your app, or trust some third-party to authenticate providers. Either way puts you pretty much where you are now.
Then there's the matter of developer authentication. Now I build a "purchase provider", but I'm an honest one who wants to actually bill the customer and pay the developer. How do I know who to pay? No developer has signed up in my system yet, so I have to use some kind of universal token to identify the developer of an app that somebody is making purchases from and tell them they have money to claim from me. It would have to be email, since what else would work? And we all have seen how secure email is lately. Anybody who managed to put a different address into the app or somehow intercept email to your address could claim the money.
Then we have payment splits. The Google app store has a published payment split between themselves and the developer that you implicitly agree to by publishing there. If you had universal "purchase providers" that anybody could implement, who decides what their payment split is? If I wanted my payment provider to split 90% to me and 10% to you, how do you stop that? If we have a third-party doing provider authentication, what are their standards for what payment splits are acceptable?
There's probably even more issues that I haven't thought of yet. If you want to do purchasing like this, you pretty much have to make your own app store and define a proprietary API for it that app developers must explicitly implement.
Say they did something like that. Now, I am going to build my own "purchase provider" that just says I paid without ever charging anything. How are you going to stop me from doing that? Somebody would have to authenticate "purchase providers" as actually charging money and paying it to the developer. Either you'd have to manually embed keys for authorized providers in your app, or trust some third-party to authenticate providers. Either way puts you pretty much where you are now.
Then there's the matter of developer authentication. Now I build a "purchase provider", but I'm an honest one who wants to actually bill the customer and pay the developer. How do I know who to pay? No developer has signed up in my system yet, so I have to use some kind of universal token to identify the developer of an app that somebody is making purchases from and tell them they have money to claim from me. It would have to be email, since what else would work? And we all have seen how secure email is lately. Anybody who managed to put a different address into the app or somehow intercept email to your address could claim the money.
Then we have payment splits. The Google app store has a published payment split between themselves and the developer that you implicitly agree to by publishing there. If you had universal "purchase providers" that anybody could implement, who decides what their payment split is? If I wanted my payment provider to split 90% to me and 10% to you, how do you stop that? If we have a third-party doing provider authentication, what are their standards for what payment splits are acceptable?
There's probably even more issues that I haven't thought of yet. If you want to do purchasing like this, you pretty much have to make your own app store and define a proprietary API for it that app developers must explicitly implement.
The problem is one of authenticating the store to prevent someone from writing an app that simply said you've bought stuff when you haven't.
As it stands if you've written an Android store you can (and at least Amazon and Verizon have) write your own in app purchase mechanism as well.
As it stands if you've written an Android store you can (and at least Amazon and Verizon have) write your own in app purchase mechanism as well.
Although I generally think most of the arguments in this article are bad, I do believe that having all purchases go through google can add value because even though I don't trust them with my data, I still trust them with my purchases.
Is it really the least bad offering?
Tizen has potential and is more open: https://www.tizen.org/
The problem is no one uses it on a large scale yet...
Tizen has potential and is more open: https://www.tizen.org/
The problem is no one uses it on a large scale yet...
Tizen has it's own large set of problems according to rasterman (EFL guy who works for Samsung).
https://www.tizen.org/irclogs/%23tizen.2013-01-20.log.html
In addition to those issues, the SDK is not open-source and is instead a proprietary Samsung license that severely restricts and takes control of a programmers applications (despite the software being supported by the linux foundation).
Overall, open webOS or sailfish/mer are much better projects.
https://www.tizen.org/irclogs/%23tizen.2013-01-20.log.html
In addition to those issues, the SDK is not open-source and is instead a proprietary Samsung license that severely restricts and takes control of a programmers applications (despite the software being supported by the linux foundation).
Overall, open webOS or sailfish/mer are much better projects.
Tizen is in a very precarious position at Samsung. If Samsung saw the slightest advantage (or, conversely, threat) to the billions of dollars they make with Android, Tizen would be gone. There is no handset business at Samsung without Android. Samsung lacks an ecosystem like Amazon has so forking is not practical.
Intel, you say? Tell me how many handsets has Intel.
Jolla and Firefox OS are better bets.
Intel, you say? Tell me how many handsets has Intel.
Jolla and Firefox OS are better bets.
"Critique."
ART is in AOSP. Had Google intended to create a two-speed Android, that would have been the place to turn AOSP into a second class citizen.
Kindle Fire will run on ART. Heck of a technology to give to an ecosystem competitor.
Kindle Fire will run on ART. Heck of a technology to give to an ecosystem competitor.
He's not wrong though - competing with Google on Android is definitely possible. I think the best step would be to create an OSS (GNU?) distribution of Android in the same way we have Linux. While Linux doesn't have all the same proprietary apps and services that Windows does, OSS devs have stepped up and provided some really great alternatives. We need to do the same for Android.
The only thing we are really missing is a large OSS project to serve as a base.
The only thing we are really missing is a large OSS project to serve as a base.
[deleted]
Cyanogen?
What I was gong to suggest, with F-Droid as the repository/app store.
"The only thing we are really missing is a large OSS project to serve as a base."
What about Firefox OS?
What about Firefox OS?
Which uses an Android kernel, and Gonk is mostly based off of Android userspace code (input, rild, most if not all of the HALs, etc.)
[deleted]
This isn't the first time that Ars Technica, an otherwise reasonable source of information, has published an utter crap article written by Peter Bright.
If Ars wants to maintain any shred of credibility (and a technically intelligent readership) in the future, they need to can this author, or label all of his articles as "op-ed", because that's the best that can be said of them. These articles contain no facts, no intelligent reasoning; just a spewing of one man's ill-formed opinions. Ars has already lost my paid subscription (and my ad revenue) due to other crap articles by this author, and I can't imagine them not losing more as a result of this article.
Get rid of him, Ars. You'll be better off for it.