4 ms·

Fuschia seems to be non-GPL. Are Google trying to remove GPL entirely from Android?

pjmlp 7y ago
Every major corporation is trying to get rid of GPL. On the embedded market Linux is competing against alternatives like mbed, RTOS, Zephyr, NuttX. In a couple of more years, we will be back to days of public domain and freeware, a subset of features free and the enticing ones all closed source. Or running in some cloud (aka mainframe), with the only open part being the browser code, or not even that depending how WebAssembly + WebGL/WebGPU happen to evolve (depending on how Google and Apple feel like driving it). Then the anti-GPL crowd might remember the days that they got GCC, GNU and the Linux kernel, or maybe not. Although for many of us that deal daily with commercial software that is kind of irrelevant anyway.
- est31 7y ago
  The biggest issue of fuchsia isn't its license, it's rather the design choice to allow proprietary driver blobs. Linux, for the exception of a few blobs here and there, rejects such an idea. In other words, the question is less about license and more about attitude / tolerance for proprietary extensions/tooling. The main power that an open source maintainer has is the design of the codebase and what to accept inside, not the power to litigate a copyleft license. The more it cooperates with proprietary software, the more likely proprietary software can establish itself and restrict user freedoms.
  - pjmlp 7y ago
    Google has already achieved that with Project Treble by the way.
    - est31 7y ago
      But they had to pay for the project. For others it might not have been economic to do it. Also, in fact there were Android-custom abstraction layers before project Treble, and the Treble abstraction layer is not around the device drivers but the entire kernel including the drivers.
soulofmischief 7y ago
They're following in Apple's stead, I guess.
ndesaulniers 7y ago
I am removing GCC/binutils from Android. I wrote: https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/master/GCC_4_9_DEPRECATION.md https://android.googlesource.com/platform/prebuilts/clang/ho... It has nothing to do with GPL. It has everything to do with Google having 50+ LLVM developers and 0 GCC/binutils developers.
- yjftsjthsd-h 7y ago
  Surely that's just a layer of indirection over whatever the real reason is? What prevents Google from having GCC/binutils developers on staff (whether by hiring or training)?
  - ndesaulniers 7y ago
    Supporting one toolchain is already a ton of work; splitting resources between two toolchains is too costly, even for Google. If you don't think so, you underestimate the cost.
- pjmlp 7y ago
  Maybe some of them could be reassigned to the NDK tooling then. I and other NDK users have several ideas of what is missing versus Java/Kotlin.
  - ndesaulniers 7y ago
    A lot of my teammates focus on LLVM for Android, including the NDK, which redistributes AOSP LLVM. > what is missing versus Java/Kotlin. I'd be happy to pass on feedback, though as worded I'm not sure if you're referring to language features or what exactly?
    - pjmlp 7y ago
      As mentioned already a couple of times with online discussions with Dan and AMA on Reddit, from me and others: An NDK version of Android JetPack/AndroidX, for starters proper C++ API, instead of forcing everyone to code 90's style, each re-creating their own C++ wrappers for the Android C++ APIs exposed as C function calls. Which by the way, given the whole security theme on Android, means more insecure code than if we had those C++ APIs to start with. Have one shot libraries like Oboe actually be part of NDK and not in another github repo with uncertain future versus the Android platform. For basic stuff like reading files (using the platform codecs e.g. BitmapFactory, now SAF as well), asking permissions, calling Java from C++, it would be nice if all NDK users wouldn't be force to keep writing those from scratch as rite of passage. Actually provide build infrastructure to create NDK libraries that can be shared across Android projects, instead of forcing us to somehow cram library and header files into AAR packages while having build scripts extract them for correct placement where cmake and ndk-build expect to find them. cdep never went anywhere, while conan and vcpkg aren't the right answer when many NDK libraries need Java code to come along due to JNI wrappers for like 90% of Android APIs. Android Studio networking debugger support, currently only supported for networking calls done in Java/Kotlin code. Easier CMake support for multiple libraries on our projects, which is found lacking versus how easy it is on ndk-build. As mentioned, these are just a couple of issues that we keep mentioning, always getting some kind of "thanks for the feedback, we will look into it". Just like the NDK status talk at Google IO 2019. From the outside it doesn't look like NDK is that staffed with engineers, more like a 20% project where a little bit is done every year, like how long it took to fix the header files, adding minimal C++ support to Android Studio, or settling into CMake as the future build system. EDIT: Almost forgot this one, fix the regressions regarding missing GCC features in clang (Android NDK tracker used to have a couple of them listed).

Every major corporation is trying to get rid of GPL. On the embedded market Linux is competing against alternatives like mbed, RTOS, Zephyr, NuttX. In a couple of more years, we will be back to days of public domain and freeware, a subset of features free and the enticing ones all closed source. Or running in some cloud (aka mainframe), with the only open part being the browser code, or not even that depending how WebAssembly + WebGL/WebGPU happen to evolve (depending on how Google and Apple feel like driving it). Then the anti-GPL crowd might remember the days that they got GCC, GNU and the Linux kernel, or maybe not. Although for many of us that deal daily with commercial software that is kind of irrelevant anyway.

est31 7y ago
The biggest issue of fuchsia isn't its license, it's rather the design choice to allow proprietary driver blobs. Linux, for the exception of a few blobs here and there, rejects such an idea. In other words, the question is less about license and more about attitude / tolerance for proprietary extensions/tooling. The main power that an open source maintainer has is the design of the codebase and what to accept inside, not the power to litigate a copyleft license. The more it cooperates with proprietary software, the more likely proprietary software can establish itself and restrict user freedoms.
- pjmlp 7y ago
  Google has already achieved that with Project Treble by the way.
  - est31 7y ago
    But they had to pay for the project. For others it might not have been economic to do it. Also, in fact there were Android-custom abstraction layers before project Treble, and the Treble abstraction layer is not around the device drivers but the entire kernel including the drivers.

soulofmischief 7y ago

They're following in Apple's stead, I guess.

ndesaulniers 7y ago

I am removing GCC/binutils from Android. I wrote: https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/master/GCC_4_9_DEPRECATION.md https://android.googlesource.com/platform/prebuilts/clang/ho... It has nothing to do with GPL. It has everything to do with Google having 50+ LLVM developers and 0 GCC/binutils developers.

yjftsjthsd-h 7y ago
Surely that's just a layer of indirection over whatever the real reason is? What prevents Google from having GCC/binutils developers on staff (whether by hiring or training)?
- ndesaulniers 7y ago
  Supporting one toolchain is already a ton of work; splitting resources between two toolchains is too costly, even for Google. If you don't think so, you underestimate the cost.
pjmlp 7y ago
Maybe some of them could be reassigned to the NDK tooling then. I and other NDK users have several ideas of what is missing versus Java/Kotlin.
- ndesaulniers 7y ago
  A lot of my teammates focus on LLVM for Android, including the NDK, which redistributes AOSP LLVM. > what is missing versus Java/Kotlin. I'd be happy to pass on feedback, though as worded I'm not sure if you're referring to language features or what exactly?
  - pjmlp 7y ago
    As mentioned already a couple of times with online discussions with Dan and AMA on Reddit, from me and others: An NDK version of Android JetPack/AndroidX, for starters proper C++ API, instead of forcing everyone to code 90's style, each re-creating their own C++ wrappers for the Android C++ APIs exposed as C function calls. Which by the way, given the whole security theme on Android, means more insecure code than if we had those C++ APIs to start with. Have one shot libraries like Oboe actually be part of NDK and not in another github repo with uncertain future versus the Android platform. For basic stuff like reading files (using the platform codecs e.g. BitmapFactory, now SAF as well), asking permissions, calling Java from C++, it would be nice if all NDK users wouldn't be force to keep writing those from scratch as rite of passage. Actually provide build infrastructure to create NDK libraries that can be shared across Android projects, instead of forcing us to somehow cram library and header files into AAR packages while having build scripts extract them for correct placement where cmake and ndk-build expect to find them. cdep never went anywhere, while conan and vcpkg aren't the right answer when many NDK libraries need Java code to come along due to JNI wrappers for like 90% of Android APIs. Android Studio networking debugger support, currently only supported for networking calls done in Java/Kotlin code. Easier CMake support for multiple libraries on our projects, which is found lacking versus how easy it is on ndk-build. As mentioned, these are just a couple of issues that we keep mentioning, always getting some kind of "thanks for the feedback, we will look into it". Just like the NDK status talk at Google IO 2019. From the outside it doesn't look like NDK is that staffed with engineers, more like a 20% project where a little bit is done every year, like how long it took to fix the header files, adding minimal C++ support to Android Studio, or settling into CMake as the future build system. EDIT: Almost forgot this one, fix the regressions regarding missing GCC features in clang (Android NDK tracker used to have a couple of them listed).