You are clearly Disconnect-ed from reality, you work for apple or something? I'm not going to bother wasting any more time on you.
On Aug 11, 1:35 pm, Disconnect <[email protected]> wrote: > On Tue, Aug 11, 2009 at 1:22 PM, lbcoder <[email protected]> wrote: > > > Second, last I checked, it is most DEFINITELY open source. The Apache- > > licensed components can be USED IN closed source projects, but *as a > > matter of choice* -- they can choose to release their modified sources > > if they want. Android itself IS OPEN SOURCE, i.e., you can download > > the source tree, compile it, and run it on your device without needing > > any closed source components. Donut won't run? Its INCOMPLETE, as in > > STILL BEING WRITTEN! Sometimes things break when under development. > > It isn't "broken/work in progress". It is "broken/parts missing". Even > @google admits that:> JBQ, cursing in the general direction of unreleased > proprietary files > > when they're necessary to properly use an open-source project. > > (http://groups.google.com/group/android-platform/msg/7e9d83aa0b08cd39?... > is linked earlier as well) > > Third... where in the license (Apache license) does it say that > > > copying the binaries is a violation? > > Are you claiming that the various libraries captured by the extract-bins > script are under the apache license? (Hint: they aren't. Thats why everyone > calls them 'proprietary'.) > > > As for the illusion of openness... it is NO ILLUSION. As I have stated > > before, you can download the sources, compile them for your platform, > > and they will run as a fully functional OS without any closed-source > > binary components. And don't you dare to suggest that because the > > Dream/Magic/Whatever platform has some closed source drivers that this > > is somehow incorrect, because Android is NOT limited to those > > platforms, for instance, it will run FULLY OPEN SOURCE (including all > > drivers) on an openmoko handset or on just about any x86-based desktop/ > > laptop/etc. > > (Unrelated, but do you have to type LikE a FOOOR4teen year 0lD? It detracts > from your points.) > > You and I have a different view of "fully functional." Donut is frequently > broken (see above) due to proprietary dependencies, and cupcake has various > fun things required-but-missing like provisioning (so no making/breaking > calls) and broken calendar (oops, no sync framework so it doesn't even work > as a stand-alone app.) And that doesn't even include a case where "your > platform" is the Dream (ADP1), which google sold to do exactly this sort of > thing with, in so many words. > > > On Aug 11, 12:38 pm, Disconnect <[email protected]> wrote: > > > On Tue, Aug 11, 2009 at 12:26 AM, David Turner <[email protected]> > > wrote: > > > > > Not really, otherwise there wouldn't be any reason to even try the > > > > open-source thing. > > > > > The reason why everything is not entirely developed in the open source > > tree > > > > are multiple, but basically boil down to the fact that product > > development > > > > has a much higher priority at the moment than building a strong and > > pure > > > > open-source community for the platform. > > > > > However, the latter is still a goal that we strive to achieve, and be > > sure > > > > we will get there at some point. For example, the open-source donut > > branch > > > > really reflect the state of our current sources, with a slight delay > > > > compared to the internal tree. > > > > > Also; I know a couple of manufacturers that are using the open-source > > > > Cupcake > > > > sources to build real products; so I disagree with Disconnect's > > assumption > > > > that the open-source tree is "totally useless" :-). > > > > Leaving aside the procedural/technical problems (inability to reasonably > > > accept patches to anything except master, etc) its still not a project > > you > > > can contribute to. If cupcake is the version external devs should be > > working > > > with, are you accepting patches to it? ..no? Only for donut. > > > > That makes sense, except the donut tree is almost always broken for > > anything > > > other than the emulator. (Most recently it was because of proprietary > > > HEADERS. Yes, as in "header files describing an interface but containing > > no > > > code". Not proprietary libraries, which is bad enough, but headers.) > > > > Outside platform devs - who own the device sold specifically for platform > > > dev - are once again in the state where the recommended action is "wait > > for > > > donut to ship on hardware, then illegally copy the bins off and use > > those." > > > (It's against the license, no matter how many times google says to do > > it.) > > > > That is hardly an open source community project. Its great that its close > > to > > > the internal tree, but that is a misleading statement when the internal > > tree > > > includes a ton of core proprietary bins and libs. (Even the > > > "non-google-experience" version, which could theoretically be public.) > > > > lbcoder's big long rosy "how an open source community project can work" > > > message was great, but it has very little bearing on reality in Android. > > A > > > couple points though: > > > - they avoided gpl like the plague. Just the kernel and bluez, iirc - > > there > > > is no license requirement to release anything else. (Most similar > > > environments would have used busybox and one of the small libc's as well, > > > but they didn't -- specifically to reduce the amount of source that had > > to > > > be released.) > > > - the illusion of openness is exactly that - an illusion to make > > consumers > > > feel fuzzy about it. (and lbcoder, evidently) it's great that the > > > unsupported unmaintained version is mostly open. > > > - hw manufs -always- modify the source to get their specific goals met. > > look > > > at the different symbian interfaces for example. that's not special to > > > android. > > > - outside collaboration is near zero still, partially due to > > > backlog/workload/procedures (being worked on, mostly by poor jbq) but > > > largely due to the inherently proprietary nature of the trees. > > > > If google was committed to the big rosy picture painted in the rest of > > his > > > message, they could knock out some low-hanging fruit: a gmail client > > (even > > > just an android-skinned version of the j2me one - no push, no contact > > sync, > > > etc) and a market client (no-protected-apps). And I'm talking bins, not > > > source so don't get all freaky at me. > > > > Those things are entirely under their control and don't interfere with > > the > > > 'google experience' phones, but they'd bring AOSP vaguely close to every > > > other mobile platform out there.. (m.google.com is a really depressing > > site > > > if you are an AOSP user. Native apps for everything from maps to contact > > > sync to youtube, for everyone but you.) > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
