Hacker News Reader

Comment by stusmall | Hacker News Reader

The "android isn't very open source" sentiment really bothers me and I see it a lot here. It is a complete and fully functional mobile OS under extremely permissive licensing. Pull it! Change it! Build it! Fork it! Whatever! AOSP is open source.

Look at the closed source services google adds. As far as I know they are all related to google services(Someone please correct me if I'm wrong). Their store, their maps, their email, their location services. This isn't needed in the open source distro and it works great without them. Also there are a lot of restriction on the brand and how you use it when release an Android product. That isn't unique to Android. See firefox vs iceweasel.

Sure sometimes it gets annoying that a lot of Android design decisions are made behind closed doors and in working in the framework sometimes I have to play the game of "Guess what the Google engineer was thinking" because documentation can be scarce. Also from what I've heard sending changing upstream isn't an easy process. These things are nice and make it an easy product to work with... but aren't required for it to be truly open source. The code is there in a series of open git repos and under Apache license. That is open source in my book.

View on HN

Google's AOSP is FOSS, Android you get on a typical phone isn't. You got bunch of proprietary binaries, kernel source code (usually, even without a toolchain to build it), and, well, that's about it.

Fuck open source, I don't give shit about Samsung/Sony/Motorola developers and how they are happy with Apache license they took AOSP under. I - the user - want free software on my phone and I mean the software that respects my freedoms. In this regard, average Android phone isn't free by any standards.

But, yeah, right, AOSP is open. Like this fact is of any use to an average tech-savvy consumer who's not skilled at reverse engineering.

It's not open source because the average consumer wouldn't know what to do with the source code? what the hell kind of argument is that? Open source isn't about end-users, it's about developer freedom. And developers are free to use android to build things. that's what open source is.

Just because you've chosen to create your own ill-informed definition of what open means, doesn't make android any less open.

It all boils down to what you call "Android."

AOSP is open source, I've already said that. It doesn't care about my freedoms (so I don't care about its openness), but it's "open" as in OSI definition. That's true and I've never argued about that.

However, typical Android you get on smartphone (that's called "Android", too) is neither open nor free - it's usually completely proprietary bootloader, firmware and userspace, you won't have any source code for anything except for GPLed parts (i.e. Linux kernel). It just happens that those proprietary binaries were mostly built from unmodified AOSP code (but you can't really tell if code's modified or not), but this doesn't make them open.

I'm surprised no-one's mentioned Replicant, which "aims to replace all proprietary Android components with their free software counterparts"

http://en.wikipedia.org/wiki/Replicant_(operating_system)

That's mostly about binary drivers for hardware though, which remains a struggle for desktop Linux too.

So you're upset that they call it "Android" ?

You know you can change what's installed on your handset? Cyanogenmod supports a ton of phones... maybe next time you buy a handset, check they support it.

> You know you can change what's installed on your handset?

Ah, thanks for suggestions. Actually, I've had to buy a smartphone recently, and tried exactly what you suggested. Unfortunately it seems that Cyanogenmod has almost non-existent support for dual-SIM phones (at least nothing for what was available, and I was in a bit of hurry), and due to personal circumstances I needed this kind of hardware.

Then maybe it's better to discuss whether Android, as ultimately delivered to end-users, is free software.

http://www.gnu.org/philosophy/free-sw.html

http://www.gnu.org/philosophy/free-software-even-more-import...

Regardless of whether most users know what to do with the source code, are they free to ask or hire a developer of their choice to study and modify it on their behalf? drdaeman's point, which seems inarguable to me, is that with most Android devices, the answer is no, because Sony/Samsung/Motorola are free to use AOSP code under the Apache license, but they don't pass that freedom on to the user.

I believe that's called "moving the goalposts". Android is free. that's what the original discussion was. No, most of the time products based on android as delivered to customers are not free software. But that doesn't mean android isn't free.

As usual, RMS had this sussed out years before everyone else realised what was going on http://www.theguardian.com/technology/2011/sep/19/android-fr...

Well it also implies that Android isn't popular with consumers so isn't much worth talking about, as consumers.

Relevant to this discussion is that Google's nefarious plans (more people using the internet) would have been met even with a fully free software stack. They had to expend more effort building an Apache codebase to appease their partners, who wanted to have their own (minor) proprietary forks.

This actually makes Android more attractive to Microsoft and generally increases the chance of a divergent, proprietary fork, which I believe Kindle already is.

Free software assumes that all end users might want to modify it, regardless of those users' current skill set. I may not be capable of modifying kernel source code today, but who knows what the future might bring.

Even if end users can't modify it themselves, they can hire developers to do it. This effectively creates a market for software customization/personalization, whereas closed-source software is more akin to a monopoly (whoever holds the source code, holds the monopoly to fixing bugs/adding features).

Not just that really, I think his point is more so that AOSP will not build and run for 99% of phones out there (i.e. non-Nexus phones). There's a lot of reverse engineering that goes on from people like CyanogenMod to make it work on other devices. Manufacturers release kernel source, as they must, but they rarely release other modifications they make for their own devices to even boot. There's a lot of stupidity in the Android "hacker" community (i.e. XDA) where people go around saying "X manufacturer doesn't release their sources, I'm boycotting X" when in reality, except for the Chinese OEMs they do release the source that they're required to release, it's just that 90% of the time that source is nowhere near enough to produce a build that you can run on your phone.

Open source is not for end users you are right. Fre software is, its where I as user would expect to have root by default on my own phone. Its a huge difference.

> Open source isn't about end-users, it's about developer freedom.

That is why FSF keeps criticizing "Open Source". This nonsense is awful. Software freedom is extremely important to end-users. They might like to do something as simple as protect their privacy and turn off surveillance or uninstall bloatware! If Open Source isn't about those things at all (even though they do NOT require programming skills!), then we really need to keep focusing on software freedom for real and not your insulting interpretation of "Open Source"

It's really weird that people talk about phones like general purpose computers that they should be in control of...I'm just pointing out that it has NEVER been the case. I'm not even sure what it would take to get to where it could be.

With PC's there was some FCC oversight, being a device without a transmitter meant that there wasn't a whole lot though. With cell phones they are so heavily regulated...and the carrier is such an integral part of the equation. It seems like you might get more of what you want with a wifi handset or device. The carriers have no vested interest in making a handset like you describe and their monopoly status makes market pressures almost non-existent forces for change.

Just rambling...

> That is open source in my book.

Have you actually built and installed AOSP on a device? If you have you might not completely agree with that statement above because without proprietary firmware and closed sourced device drivers those devices often become unusable.

That is completely ignored by your post. Is it on purpose?

JBQ (their AOSP "liason" to the community even quit over that issue) -- people complaining that open isn't really that open.

https://plus.google.com/+JeanBaptisteQueru/posts/9HHRURorE7g

So it is not just me raving about.

I understand Google though. They don't design all those sensors and drivers and all the hardware but have other manufacturers make the devices who buy components from others and so on. So they don't have a choice. But regardless of blame assignment here, I can't honestly say the system is completely open.

Now if you are Amazon or Microsoft, ok, you can find a hardware builder with its own custom drivers just for your device, then forking could work out. But for enthusiasts and experimenting you need to download the proprietary drivers to get a usable device, simple as that.

So write your own open source reverse engineered drivers or find a manufacturer that gives you docs for their sensors. It's what the Linux crowd has done for a decade now. That's what hacking and tinkering are all about. They are doing free and open Adreno drivers for example. Also Tegra. Saying Android is not open source because it doesn't come with open drivers for all current and future hardware is just plain impractical. It just means you want everything in your plate. It doesn't mean Android isn't open.

Edit: Noticed people might be taking offense to my strong wording.

Quite, but by the time you finish that the next generation is out and everybody has moved on.

The same thing happened with the HTC devices and Linux ports, it took years to get a port working and by the time it did everybody had a newer Android device (or whatever). A few people still use the HD2 and I still see questions on our (HTCLinux) Facebook page from people, but, for the most part, even XDA has moved on.

The 'current and future hardware' part is what Linux is really about, it's an abstraction layer over the specific hardware so that the user experience can be implemented once and used on many devices. Unfortunately, the lack of support for current 3D hardware means that the abstraction is incomplete. The development processes of the OEMs also break this abstraction, with everything build around one version of the kernel, one version of the phone HAL, one version of the camera driver and module, and the rest. Android, as delivered by OEMs, is not designed to adapt to other hardware. It's open in the sense that the core code is available, but not in the sense that the higher layer can be used as is on a new device.

Support for future hardware is not neccesary, but a profile that allows that hardware to be used once drivers are provided is desirable. This requires a strong abstraction between the Android userland and Linux kernel, GLES with standard DRI/DRM interfaces, UVC for the camera module (or an SoC-specific open specification much like ASoC is for audio), standard IOCTLs and sockets for network devices (wifi could use net80211 for instance), upstream Bluetooth stack including WiPHY, HE, and LE support, with working A2DP audio routing, input devices with valid metadata in the driver so they can be probed, supported flash filesystem, and probably some others.

Then Google takes this and builds a set of tests that verify that these requirements have been met, and states that the next 3 versions of Android will use this base.

They also provide an ABI guideline (so version) for the phone interface, the audio playback, sensors, and other aspects provided by libhardware. They make the same commitment: the next 3 versions will require this so version of libhardware.

The OEMs get this set of guidelines and build a device to meet them, passing the tests provided by Google.

Then Google releases an OTA version of Android that works on top of this base. Then they release another, and another.

As features require it, they amend the guidelines, adding NFC for instance. Not all devices support NFC and on those that don't, the functionality is not exposed by Android.

>Android, as delivered by OEMs, is not designed to adapt to other hardware. It's open in the sense that the core code is available, but not in the sense that the higher layer can be used as is on a new device.

Don't you think that's more due to the way ARM / mobile hardware scene is than due to Android? There isn't something like a BIOS or ACPI type of standardization to make that kind of thing happen. Also the pace of obsoletion is way faster in the mobile space than it ever was in the PC space.

Initially it was, but Android/Google have become the establishment. And ARM-based devices are becoming our general-purpose computing devices. Having an option for running the software we choose is the question of whether we have open computing device in the future.

There actually is a solution at the hardware/firmware/driver level now, the ARM Linux community has adopted DeviceTree, actually a varient called FDT, and drivers have migrated from the one-off platform buses to FDT. Even vendors like Qualcomm are embracing it and the time to upstream is falling.

As far as bootloaders, there are a number of open options. also don't personally see anything wrong with EFI on ARM, as long as there is a way for the end user to choose what signatures are accepted when booting software. A standard for describing memory layouts independent of hardware is important, as that allows for the newer multi-SoC ARM Linux kernels along with DT for defining the hardware and what driver should bind to what hardware device.

There are standards that exist at this layer, as long as the OEMs and SoC makers adopt them.

The basic concepts of SoCs are not being obsoleted, and the basic set of devices that need to be present to boot a system are not really changing that much, specific buses are changing, better DMA mapping is supported on newer hardware, including IOMMUs, but the basic concepts are still pretty much the same.

My proposal takes place at a different layer though, and is more focused on the fragmentation problem of Android.

Essentially you have an ARM ABI standard which defines what registers a call into the Linux kernel uses, this used to be more complicated with multiple ARM ABIs. Now it's pretty simple and ARM binaries on Linux work across devices, across SoCs, across Android OEM vendors. This is not much better or worse than the same compatibility on x86/x64.

The issue lies in the "expanded ABI," the suite of drivers, libraries, daemons, configuration, RPC procedures, hardware specific IOCTLs, and other particulars of each OEM's hardware. A Samsung camera APK isn't going to work on a device with a different sensor, even though they are both coded to Android's camera APIs. They might handle zoom differently, or lighting. They might handle sending the uncompressed stream to the DSP differently, or drawing into the LCDC different for real-time previews. They might handle flash timing differently. But what would happen if this was a plugin for the standard Google or even AOSP camera instead? What if this was a defined API/ABI that CyanogenMod could use on that hardware, or Firefox Apps with embedded WebAPI camera media source and canvas? What about capturing from the command line with something like uvctool?

Numbers like 4.4 at 2% (from another story today) should scare Google. It should scare them when apps built for Chrome Mobile don't work on all Android devices. It should scare them when the improvements made to Google Now won't be usable by an overwhelming proportion of their users. It should scare them when others like Yahoo and Mozilla can come in and poach Android users stuck on an outdated version of Android and build alternatives economies on their own (Google's) partner's flagship devices. And they should respond by competing.

>Have you actually built and installed AOSP on a device?

Yes. I work with embedded Android at the driver and framework integration level. This is my every day.

I'm not really concerned that someone can't load AOSP on some cheap AT&T subsidised phone. Does that make the framework less free? No, that means they have non-free hardware.

Have you been able to get GLES 2.0 working on an AOSP device with manufacturer provided drivers? Do the modern rendering features like renderscript work? What about audio and video codecs (like h.264, etc. not the PCM codecs)? Do common downloadable games that depend on 3D features work? Are they playable?

AOSP is great to bring up on a framebuffer-based device, but that gets you as far as an Android 2.0 launcher.

Any idea if Chromium can be build for AOSP with similar features as Chrome on Android?

>Have you been able to get GLES 2.0 working on an AOSP device with manufacturer provided drivers?

No. This is a problem that extends far beyond Android and existed before it showed its face on the scene. Non-free graphics drivers are common on desktop Linux too.

I've reread my comment and am trying to see where I was critical of Android.

AOSP is open source, and it has parity with commercial distributions of Android in a number of areas.

I have been working with Android and Linux on Qualcomm MSM-based devices for a few years, navigating their portal at codeaurora.org, tearing into Android kernel commits and following the upstreaming process. The changes that Android makes to Linux are minor, and most of the them have been merged into the upstream kernel in some form.

The Linux framebuffer started out as a device wrapping the memory-mapped display memory of the Amiga and similar RISC devices, then it was ported to the Netwinder, which was an early embedded ARM computer in a screen. It has a minimal set of operations for accelerated graphics, it can do fast fills or clear the screen for instance. It does not support 3D graphics, it does not support most of the 2D primitives that X and the Android rendering libraries (such as surfaceflinger) require. Android had an extended protocol for using some of the features to enhance fast blits of of data from an offscreen buffer to the main display buffer. This was implemented using IOCTLs on top of the framebuffer, and by reusing some of the features in a different way.

This is sufficient to get you a basic Android launch screen, you won't get the 3D launcher screen, you won't get the enhanced gallery plugin, you won't get fast Google Maps/Earth rendering, and you won't be able to play 3D games. For that you need a 3D graphics driver. Most of these drivers are tightly controlled by the company that makes the chip, are closed source, and are not readily reverse engineered. Some projects have made progress, but it's been a slow process. LIMA is an implementation of the ARM Mali driver for instance. Recently, Nvidia submitted a patch to Nouveau for their Tegra device. This breaks with years of not cooporating with development of 3D drivers for their devices on Linux, and has the potential for a bright future of AOSP 3D graphics support on Tegra devices.

Oh sorry, I read it as a jab against Android for its reliance on non-free drivers and firmware. Sorry for assuming!

Ha, no problem. I was actually asking your experience with those things.

I am a little critical of people declaring Android great because it's open, while ignoring the limitations of AOSP. Unfortunately, this is a trend for or against many popular platforms where emotional responses replace reasoned consideration of the pros and cons of the products.

I've seen this a lot in discussions around Android, iOS, and Windows Phone. I prefer to inform and learn more about the platforms and use that discussion to shape my internal image of the state of the mobile industry. I care about the good features of Windows Phone. I care about the negatives of closed source drivers on Android, even as I'm aware of the limitations that Google's Android business had at the time that these decisions were made. I consider the iPhone, when it was released, to be very positive step forward and superior to pretty much every device a normal consumer would consider at the time. The willingness to seize control from the carriers, support apps from developers that couldn't afford the licensing fees and restrictions for BREW, and the limited number of phones that it supported, and revolutionize mobile OSs toward a modern graphics rendering, interaction, etc. was a huge boon to the industry. But I'm also willing to criticize the control Apple has over the choice of applications they distribute for competitive reasons. I want the ability to install any app I wish on my device. I want the ability to build applications for my device without joining a paid program, or being limited in who I can share my developed app with. I want to be able to choose the license my code is released under while still being able to distribute it in the most used venue.

I want a device with integrated services, but I want to choose which services I use.

I want full 3D support in open source so that anyone can go out there and build a new experience for their device from the ground up, and not be limited to the one that Android provides. FirefoxOS on every device, Ubuntu Mobile, Open WebOS, and plain old X.

I don't see the point of criticizing Android itself for lacking open 3D drivers, I use a Samsung Galaxy S4, Google services, Google Play, and the Chrome browser. (As well as Firefox for Disqus sites, for some reason.) But I don't see myself using AOSP as delivered.

> I am a little critical of people declaring Android great because it's open

I am in the same boat (I made the original comment referring to the drivers). Now it is partly through my own ignorance. I assumed if I just followed the steps to built and install AOSP (plus some patches I was trying out), I would have gotten a functional Nexus 7, minus all the google apps of course. Well rotation sensor, and other wasn't working, GPU was slow, other stuff was crippled. The device was basically not usable very much.

Now yes, Android on a scale is a lot more open than say Apple products for kudos for them. But at the same time the fine print associated with AOSP is a little too much for the project to be proclaimed completely "open".

I couldn't even load it on Nexus device without proprietary drivers. Some of which were not released for quite a bit. Those are not just Chinese knock-off those are Nexus devices.

> No, that means they have non-free hardware.

My Lenovo laptop is also non-free hardware, it works very well without closed source drivers.

Because people made it work. People can do that for AOSP, but they haven't yet. Go do it!

> Because people made it work.

Right, and they haven't made all these other Android devices work. So, "Android is open source" statement is only true with some major fine print attached to the bottom. That was my point and I was trying to clarify the misconception.

People can also reverse engineer Windows and "make it work". That doesn't mean it's open.

Would that be the same Lenovo range that gets regularly recommended for use with Linux because, unlike many others, it works well with Linux? If so that rather undermines its relevance here.

>The "android isn't very open source" sentiment really bothers me and I see it a lot here. It is a complete and fully functional mobile OS under extremely permissive licensing. Pull it! Change it! Build it! Fork it! Whatever!

The fact that you could theoritically "fork it and change it" doesn't change the fact that Android, the thing that is actually shipped, is not open itself, in the sense that it's not a community project, where everybody's opinion has equal weight based on their work, community standing, etc.

Without an actual community behind it, like Gnome or KDE, or FreeBSD have, one cannot influence it much, one's vote doesn't count, and "fork it and change it" is not really feasible -- who'll be paying for that?

>The code is there in a series of open git repos and under Apache license. That is open source in my book.

Well, that's the least interesting part of being open source. The actual important attribute of being open source is being a community project (cathedral vs bazaar etc).

I think the issue is that all of those Google services are really what makes Android Android. An Android phone lacking integration with Gmail, Google Calendar, etc, without something else to make it compelling (like the Kindle Fire), would be a pretty tough sell I think.

That's true, but if say, Microsoft, wanted to, they could clearly create replacements for those services. Now, it's arguable whether an Android phone with Hotmail + Bing Maps integration is even an improvement, but at least it's possible.

In China, most Android phones are already sold without Google services: http://www.radiofreemobile.com/android-in-china-no-google-he...

You could say the same for GNU. What is Linux without a DE? And a fancy DE like GNOME Shell pulls in a lot of dependencies, the latest furore in that area is GNOME&systemd.

Difference between systemd and GMS is, developers aren't making money off of systemd being in their control, Google relies almost wholly on it for Android profits.

Android is a fully functional Linux based operating system. To expect GMS to just be handed out like it was a keg party flier without considering the actual economic reality of running Google is ridiculous.

OEMs like Samsung weren't fooled back in ~2004 to think they'd get an amazing OS for their phones for free, and the deal Google is offering is beyond amazing compared to how other (tech) firms do business. imo.

Wait, isn't GNOME a part GNU Project?

And Microsoft wouldn't be able to add similar integration?

What it comes down to is really "what do Android buyers expect from an Android device?"

If the consumers expect that they will get email, cloud storage, calendars, and maps then it would likely be fine for Microsoft to create similar integrations. If consumers expect that they will get Gmail, Google Drive, Google Calendars, and Google Maps, then they will likely be disappointed.

Remember there are billions of people who haven't already been locked into Google services. They don't think "I need access to my years and gigabytes worth of Gmail." They think "I want email. This 'outlook.com' thing that came with my [hypothetical MS Android] phone will work fine"

Exactly - and isn't the Kindle Fire OS a successful Android fork?

Different case; different business model. Kindle Fire is a tablet platform for delivering Amazon content and services.

This is exactly the same case.

How about, say, the location services apis, aren't they kind of needed for most apps?

You are thinking of Android as just an OS for consumer mobile phones. You don't always need Facebook to run on it for it to be useful. It is a great polished Linux distro that can find a lot of uses. Think of it as a specialized Linux without the GNU user space. It has a full rich and powerful API without relying on google.

Also device integrators are free to fork away from the base APIs to add their own functionality in the same way google has. If an app wants to be portable, they shouldn't build against these proprietary APIs. This isn't a unique problem to android and doesn't make the source any less open.

What I love so much about open source is that once a project is out there it can take on a life of its own. People can/have/will start cramming Android in places Google would have never expected. It makes a great base for POS systems, high end touch screen vending machines, in flight entertainment consoles, and any number of other things I can't think of but I'm sure the community will.

Yes but the APIS themselves are open. It is possible to yank out the Google implementation of the location services and instead use a 3rd party implementation. The OS was designed to make something like this possible. Nokia could plug in their location services trivially for example if MSFT goes Android. (Not that I think it's a good idea but it's doable.)

There are other ways too - Sky hook for example seems to offer location services SDK http://www.skyhookwireless.com/location-technology/sdk.php for the Kindle Fire which doesn't ship with GApps.

Good point, but does this actually solve the "shortage of apps" problem if you don't have access to GMS and Google Play?

All this came up because of a couple of articles that said Microsoft should dump Windows Phone and do Android phones instead. So, would Microsoft have more problems getting developers to write for Windows Phone (and Windows 8 Metro) or for a forked version of Android?

Also, technically, you don't need an Android phone or tablet (or Linux) to run Andoid apps, since Bluestacks does this... though you might run into the same problem with GMS.

Amazon solved the lack of Google Play problem but their circumstances were very different.. Microsoft could technically do the same and they might have better app situation. Developer's problem with WP is that it is yet another platform to port their app to without any guarantee of returns given the platform's numbers. If MSFT went with their own Android store developers would just need minor changes to their Play Store version to gain yet another entry point. If it doesn't work out no big deal.

Problem is just going Android without great differentiation is almost a guaranteed failure for Microsoft. And at this stage in the game coming up with great differentiation is going to be very hard. But if they do something like put out great Nokia handset with great camera, guaranteed OS updates, a tiles based launcher an thriving alternate app store, more focus on privacy of the user and great Microsoft services and apps - that could work well. I am not sure about the practicaility of all that and if it will mean significantly more revenue for Microsoft. Besides, by all accounts Microsoft is still badly bullyish on the Windows everywhere strategy so to change course with Ballmer being the biggest share holder and Gates doing product advisor role it's just not easy. On top of that the market is just too irrational and hyper competitive for them to feel confident about doing something this drastic.

I used to work in Nokia's developer relations group. For a lot of developers, the following requirements are all hurdles that make WP more trouble than its worth:

- Learn a new language (C# is awesome but odds are the dev you are talking to already knows Java or ObjC. Telling an Android dev to learn C# is more work than telling him/her to tweak his/her Android app)

- Get Windows (a huge number of mobile devs are on MacBooks. Getting Windows costs some combination of time, money, and precious SSD space)

- Get Windows 8 (a lot people who are on Windows are on Windows 7 and have no desire to go to Windows 8)

bottom line: telling devs to tweak their Android apps for some kind of "MSMS" over GMS would represent a whole lot of lower barriers to entry.

Possibly, but just saying learn C# so you can program for Windows Phone is the wrong selling point. It should be learn C# so you can develop native-quality apps for all mobile platforms. Microsoft should completely embrace Xamarin. That would solve the OSX problem as well, as developers could use whatever OS and IDE they prefer.

Removing these barriers doesn't actually require forking Android, though. For example they could create a Java language projection for WinRT alongside the C++, .net and JavaScript ones. Actually just making the existing JavaScript stuff from Windows 8 available on WP might help a lot.

Windows is on more than 90% of PCs (including a lot of Macs), Visual Studio is one of the most popular development environments, and C# is one of the most sought-after skills in the job market. And as others have noted, Xamarin for Visual Studio lets you develop for iOS and Android as well. https://xamarin.com/visual-studio

Also, C# isn't compulsory because you can develop in HTML5 instead.

So, it might be impossible to get people who specialize in iOS apps to develop for WP8, but it should be possible to grow a comparable ecosystem. And making apps run on both W8 and WP8 would be a good move in that direction.

The short term view may be bleak but the future is uncertain, and the long term _could_ look different.

I'm running cyanogenmod without google and many of the apps out there rely on google apis without telling you that they do so (a significant chunk of the apps available on aptoide). Also with some phones that I've had it's been basically impossible to get a gps fix without enabling the 'allow google to track me' option, not that that is particularly relevant, but it is pretty annoying...

its not what makes an android phone and android phone. so.. the argument is valid, android as a whole, coming from google, isn't open source. only AOSP is. And heck, even the AOSP maintainer resigned some time ago because AOSP didn't include open source drivers and what not.

It's somewhat analog to OSX. The kernel and low-level services are open-source and made publicly available on http://opensource.apple.com/. From that point and up, OSX is proprietary. Android would be somewhat analog to Darwin + Finder being open and iTunes, iPhoto, Mail and others being proprietary.

yeah, somewhat. that being said, AOSP does provide a little more than Darwin does, mainly, there is some UI provided. Otherwise, .. yeah. It's also getting closer and closer to that model.

It provides a lot more, otherwise Cyanogenmod wouldn't be possible. I have a cheap Huawei phone and replaced the annoying stock firmware with KitKat per Cyanogenmod and it's virtually impossible to see the differences compared to my Nexus 4 besides logo's and the extra features that Cyanogenmod has (I installed the Google Apps bundle).

At this point in time, it would be nearly impossible to make an open source, fully compatible, version of OS X. Replicating the APIs and user interface would probably cost hundreds of millions and a few patent lawsuits.

as you said, you installed the google apps. well, google apps are 100 megs. guess why. Its not just gmail and what not. It includes all the proprietary APIs, everything.

You don't get any of that in AOSP. Reinstall CM but do not installed gapps, and you'll have something close to AOSP (well, better than AOSP still)

I bet you don't last a day before you'll install gapps again (and thus all the google proprietary libs, etc.)

>The "android isn't very open source" sentiment really bothers me and I see it a lot here.

>AOSP is open source.

Clever switch there from Android to AOSP, no wonder its the top comment. The difference between them is what the author is talking about. You just prove his point.

It "bothers" you? How can it "bother" you? You arent an AOSP developer.

The license is not what the author is referring to, he's referring to the fact that YOU, or I or ANYONE cannot sign up to develop AOSP and contribute to the project because its just a code dump from google with a license.

Thats NOT open source and if you think the license makes it so then you need to go up and try to make a commit no matter how trivial to AOSP. Dont be a fool...fool.

Not even Richard Stallman defines open source (or rather free software) like you do. [1] AOSP meets all of the criteria, and it's a code dump with a permissive license that you are free to fork and redistribute as you wish.

There's no rule that free software requires accepting pull requests from the entire world.

[1] https://www.gnu.org/philosophy/free-sw.html

The beauty of open source is that Stallman doesnt really matter. There is no community developing around Android except for the google play store because to do so would be futile. (Yes I actually READ the article).

If a text blob of nonsense at the top of a source file makes you open source then WOW. How about Doge-Source? Such open, very free.

https://en.wikipedia.org/wiki/Doge_Source

Reply on news.ycombinator.com