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?pli=1which 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 -~----------~----~----~----~------~----~------~--~---
