4 ms·

I think angusr may be mistaken in his analysis. The underlying kernel for Android is licensed under GPL, but the rest of Android is licensed with the more more

by credo 16y ago

I think angusr may be mistaken in his analysis. The underlying kernel for Android is licensed under GPL, but the rest of Android is licensed with the more more permissive Apache license. My understanding is that Google explicitly chose the Apache license because it is considered as more friendly to commercial development and proprietary redistribution. I'm assuming that the manufacturers will state that they have just extended Android non-kernel components or (if kernel changes were required,) perhaps that they've just implemented a new I/O abstraction layer that is independent of the GPLd code Followup to response: If my comments reflect a misconception, can you please provide an alternate hypothesis for why Google chose the Apache license for Android

angusgr 16y ago
This is a common misconception about GPL, but it is false. To oversimplify Section 3 of the GPLv2: if you release a GPL licensed program then you have to comply by making source code available or showing where source is available, regardless of whether or not you have modified it. I can assure you that Linux BSPs for most of the underlying systems included in the list are not currently available anywhere (that's what the "source available" column in the table is intending to show.) Although this is actually unrelated to the issue of whether or not the company themselves are violating GPL. You're correct that (as the article says) quite a lot of functionality is spun off into standalone kernel modules (not necessarily GPL) and the Android layer, but this doesn't excuse the overall GPL violation.
- angusgr 16y ago
  "Followup to response: If my comments reflect a misconception, can you please provide an alternate hypothesis for why Google chose the Apache license for Android" Of course - you're entirely right that's why Google chose the Apache license for Android. In fact, people from Google have said that and my article says that as well. That still only applies above kernel level. The GPL violations I am talking about, as described in the article, are failure to comply with GPL for the Linux kernel and for other GPL licensed components that vendors have chosen to include (I identified busybox in at least two of the listed firmwares.) You are probably right that many modifications are not covered by GPL. However, the vendor still has to comply for the portions that _are_ covered by GPL (even if they made no changes.) In the case of many of these systems, that happens to include the BSP (Board Support Package) that allows Linux to boot on those systems at all. Although that last part isn't the point, at the moment it's a fundamental practical problem.
- loewenskind 16y ago
  >if you release a GPL licensed program then you have to comply by making source code available or showing where source is available, regardless of whether or not you have modified it. This seems pretty arbitrary. If I haven't modified it can't I just point you to the repository and revision I'm using?
  - angusgr 16y ago
    Pretty much. GPL 3(c) - I think - says that provided you got a binary version with an attached notice telling you where to go to get the source code, you can redistribute the same binary unmodified with the same notice.
deleted 16y ago
[deleted]

by credo 16y ago

angusgr 16y ago

This is a common misconception about GPL, but it is false. To oversimplify Section 3 of the GPLv2: if you release a GPL licensed program then you have to comply by making source code available or showing where source is available, regardless of whether or not you have modified it. I can assure you that Linux BSPs for most of the underlying systems included in the list are not currently available anywhere (that's what the "source available" column in the table is intending to show.) Although this is actually unrelated to the issue of whether or not the company themselves are violating GPL. You're correct that (as the article says) quite a lot of functionality is spun off into standalone kernel modules (not necessarily GPL) and the Android layer, but this doesn't excuse the overall GPL violation.

angusgr 16y ago
"Followup to response: If my comments reflect a misconception, can you please provide an alternate hypothesis for why Google chose the Apache license for Android" Of course - you're entirely right that's why Google chose the Apache license for Android. In fact, people from Google have said that and my article says that as well. That still only applies above kernel level. The GPL violations I am talking about, as described in the article, are failure to comply with GPL for the Linux kernel and for other GPL licensed components that vendors have chosen to include (I identified busybox in at least two of the listed firmwares.) You are probably right that many modifications are not covered by GPL. However, the vendor still has to comply for the portions that _are_ covered by GPL (even if they made no changes.) In the case of many of these systems, that happens to include the BSP (Board Support Package) that allows Linux to boot on those systems at all. Although that last part isn't the point, at the moment it's a fundamental practical problem.
loewenskind 16y ago
>if you release a GPL licensed program then you have to comply by making source code available or showing where source is available, regardless of whether or not you have modified it. This seems pretty arbitrary. If I haven't modified it can't I just point you to the repository and revision I'm using?
- angusgr 16y ago
  Pretty much. GPL 3(c) - I think - says that provided you got a binary version with an attached notice telling you where to go to get the source code, you can redistribute the same binary unmodified with the same notice.

deleted 16y ago

[deleted]