4 ms·

At first I thought this is hyperbole, but there's an anti-forking clause in the license agreement: > "3.4 You agree that you will not take any actions that may

by codeflo 14y ago

At first I thought this is hyperbole, but there's an anti-forking clause in the license agreement: > "3.4 You agree that you will not take any actions that may cause or result in the fragmentation of Android, including but not limited to distributing, participating in the creation of, or promoting in any way a software development kit derived from the SDK." IANAL, but this seems to be designed to prevent projects like the Kindle Fire from building their own ecosystem on Google's code. Good for Google I guess, but no longer in the spirit of open source.

untog 14y ago
"Google's code" is a little vague, though. You can use the code for Android (which the Fire indeed does), you just can't use Google's first-party apps.
- codeflo 14y ago
  Are you sure? This license covers the SDK, not the first-party apps. At the very least, this agreement could prevent them from adding any Kindle-specific extensions to the API. (This point is a bit moot because the Fire codebase was presumably forked from an older version of Android without this license change.)
  - fpgeek 14y ago
    This point isn't moot at all. One of the first things Amazon tells Kindle Fire developers to do when setting up their development environment is download the Android SDK: https://developer.amazon.com/sdk/fire/setup.html https://developer.amazon.com/sdk/fire/setup.html To me, the real issue I have with the SDK anti-fragmentation clause is that I have no idea what it means. Does it mean you can't develop for the Kindle Fire, Nook, Nabi et al using it? Or is it OK if your apps still work on Google devices as well? Does that mean Amazon can't use the SDK when working on the Kindle Fire OS? Or is that fine too as long as the OS passes the associated compatibility tests (and, reportedly, Amazon has been very good with compatibility to date)? And so on. And whatever the bizarre restrictions are how in the world is Google even dreaming of enforcing them? Or are they just planning to complete with Microsoft and Oracle for the "most pirated development tools ever" prize?
mvanga 14y ago
What does such a clause might mean to projects like Cyanogenmod?
vibrunazo 14y ago
We have been through this many times before here. This is meant to prevent forks that break compatibility. Like that chinese company that made their "own" phone OS. That was just a fork of Android, but not perfectly compatible with the Android SDK. It causes fragmentation in the sense that it forces developers to rewrite apps for it because there are differences in the SDK. Amazon, Cyanogen, OUYA etc are all fine.
- codeflo 14y ago
  I'm sure that's a good thing for the Android ecosystem. I'm not against that on priciple (that is to say, I'm not an open-source zealot). I'm just saying that a having single entity with the sole right to change the API is essentially the definition of a closed system.
- revscat 14y ago
  I'm sure there are justifications for this clause, but that doesn't change the fact that you can no longer fork the code, and that API changes are under the control of a single entity. This is almost the textbook definition of closed software.
  - DannyBee 14y ago
    You can fork the open source parts of the code, even the open source parts of the SDK code. The SDK code is not the same as the SDK download.
- lnanek2 14y ago
  The whole point of free software, though, is that you can fork it and customize and use it as you like. If someone wants to fork Android to run on stoves, and they have to break compatibility to do that, if it was free software it would support and allow that. Instead you aren't even allowed to use the SDK or let developers use the SDK if you do so. You can't really claim Android is open or free anymore now, just that it uses a few free pieces, which are being taken away wherever possible.
  - 14y ago

by codeflo 14y ago

untog 14y ago

"Google's code" is a little vague, though. You can use the code for Android (which the Fire indeed does), you just can't use Google's first-party apps.

codeflo 14y ago
Are you sure? This license covers the SDK, not the first-party apps. At the very least, this agreement could prevent them from adding any Kindle-specific extensions to the API. (This point is a bit moot because the Fire codebase was presumably forked from an older version of Android without this license change.)
- fpgeek 14y ago
  This point isn't moot at all. One of the first things Amazon tells Kindle Fire developers to do when setting up their development environment is download the Android SDK: https://developer.amazon.com/sdk/fire/setup.html https://developer.amazon.com/sdk/fire/setup.html To me, the real issue I have with the SDK anti-fragmentation clause is that I have no idea what it means. Does it mean you can't develop for the Kindle Fire, Nook, Nabi et al using it? Or is it OK if your apps still work on Google devices as well? Does that mean Amazon can't use the SDK when working on the Kindle Fire OS? Or is that fine too as long as the OS passes the associated compatibility tests (and, reportedly, Amazon has been very good with compatibility to date)? And so on. And whatever the bizarre restrictions are how in the world is Google even dreaming of enforcing them? Or are they just planning to complete with Microsoft and Oracle for the "most pirated development tools ever" prize?

mvanga 14y ago

What does such a clause might mean to projects like Cyanogenmod?

vibrunazo 14y ago

We have been through this many times before here. This is meant to prevent forks that break compatibility. Like that chinese company that made their "own" phone OS. That was just a fork of Android, but not perfectly compatible with the Android SDK. It causes fragmentation in the sense that it forces developers to rewrite apps for it because there are differences in the SDK. Amazon, Cyanogen, OUYA etc are all fine.

codeflo 14y ago
I'm sure that's a good thing for the Android ecosystem. I'm not against that on priciple (that is to say, I'm not an open-source zealot). I'm just saying that a having single entity with the sole right to change the API is essentially the definition of a closed system.
revscat 14y ago
I'm sure there are justifications for this clause, but that doesn't change the fact that you can no longer fork the code, and that API changes are under the control of a single entity. This is almost the textbook definition of closed software.
- DannyBee 14y ago
  You can fork the open source parts of the code, even the open source parts of the SDK code. The SDK code is not the same as the SDK download.
lnanek2 14y ago
The whole point of free software, though, is that you can fork it and customize and use it as you like. If someone wants to fork Android to run on stoves, and they have to break compatibility to do that, if it was free software it would support and allow that. Instead you aren't even allowed to use the SDK or let developers use the SDK if you do so. You can't really claim Android is open or free anymore now, just that it uses a few free pieces, which are being taken away wherever possible.
- 14y ago