Android source isn’t available ?????????

[Ze]

I don't understand how Android is an open source project as its source
hasn't been released?

Ze

[Carlo Brualdi]

First, cross-posting is a bad practice.
Second, Android declares to be open, but not open source; you can read
it as open minded, for example. However probably, we hope, it will
become fully open source when it will be more mature. Remember it's
only an early look at SDK.

[test...@gmail.com]

I am not satisfied with your justification; even if it isn't mature
its source must be released. So that the open source community can
enhance it more.

Ze

> > Ze- Hide quoted text -
>
> - Show quoted text -

[Carlo Brualdi]

That wasn't a justification, I don't work for Google :)
That I said is only the reality. As Google say. I agree with you, but
the facts are these. And maybe there's a reason, or there's not. I
don't know!

[Stone Mirror]

On Fri, Mar 28, 2008 at 8:36 AM, Carlo Brualdi <carlo....@gmail.com> wrote

That wasn't a justification, I don't work for Google :)
That I said is only the reality. As Google say. I agree with you, but
the facts are these. And maybe there's a reason, or there's not. I
don't know!

On Mar 28, 4:13 pm, test1....@gmail.com wrote:
> I am not satisfied with your justification; even if it isn't mature
> its source must be released. So that the open source community can
> enhance it more.

You're correct that Google is approaching this in a completely inverted fashion relative to any real open source project.

Android isn't open source; it's "going-to-be-open-someday" source. Google has only published the portions whose licensing requirements demanded that they do, and there's no community around the Android platform itself, other than within the Googleplex.

This posting at Livejournal, which also gets into some interesting aspects of the terms and conditions (which are between you and Google, and not with the "Open Handset Alliance") points out that Google will release some unspecified "most of" the Android source under the Apache license, but not until phones ship, "the second half of 2008" according to Google. Samsung, a pretty aggressive company, doesn't expect that their Android phone will be out before 2009, however.

It's unclear what this "most of" amounts to. So, no one knows whether it'll, for instance, include Dalvik or not, or Surface Manager or not. All we know is that, so far, Google's only released what they had to, and hasn't actually engaged with the open source community on this "open source" project in any discernible way. Maybe Dan Morill, or someone like him, would liketo try to clarify this.

--
鏡石

[test...@gmail.com]

Is there any one from Google who can answer why they aren't releasing
the code?

Ze

On Mar 28, 5:55 pm, "Stone Mirror" <stonemir...@gmail.com> wrote:
> On Fri, Mar 28, 2008 at 8:36 AM, Carlo Brualdi <carlo.brua...@gmail.com>

> wrote
>
>
>
> > That wasn't a justification, I don't work for Google :)
> > That I said is only the reality. As Google say. I agree with you, but
> > the facts are these. And maybe there's a reason, or there's not. I
> > don't know!
>
> > On Mar 28, 4:13 pm, test1....@gmail.com wrote:
> > > I am not satisfied with your justification; even if it isn't mature
> > > its source must be released. So that the open source community can
> > > enhance it more.
>
> You're correct that Google is approaching this in a completely inverted
> fashion relative to any real open source project.
>
> Android isn't open source; it's "going-to-be-open-someday" source. Google
> has only published the portions whose licensing requirements demanded that
> they do, and there's no community around the Android platform itself, other
> than within the Googleplex.
>

> This posting at Livejournal <http://robilad.livejournal.com/22312.html>,

> which also gets into some interesting aspects of the terms and conditions
> (which are between you and Google, and not with the "Open Handset Alliance")
> points out that Google will release some unspecified "most of" the Android
> source under the Apache license, but not until phones ship, "the second half
> of 2008" according to Google. Samsung, a pretty aggressive company, doesn't

> expect that *their *Android phone will be out before 2009, however.

[Dan Morrill]

2008/3/28 Stone Mirror <stone...@gmail.com>:

there's no community around the Android platform itself

I betcha the other 8,463 current members of this forum would disagree with you.  But then, every forum needs a troll, I guess.

 

It's unclear what this "most of" amounts to. So, no one knows whether it'll, for instance, include Dalvik or not, or Surface Manager or not. All we know is that, so far, Google's only released what they had to, and hasn't actually engaged with the open source community on this "open source" project in any discernible way. Maybe Dan Morill, or someone like him, would liketo try to clarify this.

Certainly.  I actually talk about this publicly all the time, so quite a few people know.  Ironically, I may not have said it on this forum yet, so now's as good a time as any.

The short version is that anything we can get the rights to open-source, we will -- and one of the key reasons for the Open Handset Alliance is to make sure we have the rights to open-source everything we need to.  If we needed a particular feature to be open sourced, we either built our own or found someone to join the Alliance and contribute their implementation.

The entire system will be open-sourced, excluding certain pieces. Things that will be opened include Dalvik, SGL, the libc implementation, the Surface Manager stuff, the Binder, the various frameworks and APIs, the core applications (like the dialer, SMS client, Home screen, etc. but possibly excluding any Google-branded apps like Gmail), the media codecs (including ones for H.264, etc.) and so on.

Anything original to us (such as Dalvik) will be Apache 2.0.  Anything that has to be another license like GPL/LGPL (such as the kernel, WebKit, and Qemu) is already released.  Last I heard, a few things that were derived from other projects, notably the libc implementation, will probably be released under the original BSD license.

The "certain pieces" that will remain closed are some corner cases at the device driver level.  The engineers on that tell me that in general this will be a similar compromise to situations you frequently see in the 802.11 world, where you have binary-only firmware with an open-source driver.  I'm sure someone will now make the inevitable "but device drivers are the most important part!" criticism, but as I said we are aiming to open-source as much as we physically can.  The IP for ICs can get pretty convoluted, unfortunately.  I can't be more specific than this, because I don't know that much about this level of the system.

The reason we haven't released the source yet is primarily logistical.  One of the team once said "Android will be the largest open source project in the world". That may or may not be technically true, but I think it eloquently captures the scope of what we're doing.  When your project is this large, the simplest questions like governance become a big deal.  Dalvik by itself is huge, and so are Binder, SGL, etc.  Should we have a single gigantic source tree or split up into multiple smaller projects?  Anyone who's ever worked in open source knows that it can take a long time to come to consensus on decisions like that.  Once we do, we have to then physically tidy up the source, make sure it builds outside our internal infrastructure, set up a public source repository that can handle the load, and so on.

Those are distractions that we can't afford right now since we are working closely with our partners to get the first devices launched.  Our plan is that once we reach version 1.0, we will turn our attention to the squishier issues of releasing source.

- Dan

[Dan Morrill]

On Fri, Mar 28, 2008 at 11:00 PM, Dan Morrill <morr...@google.com> wrote:

I betcha the other 8,463 current members of this forum would disagree with you.  But then, every forum needs a troll, I guess.

Whoops, I just noticed this went to the Internals list;  the 8465 count is for the Developers list.  Sorry about that -- you can pick whether you want to add them up or just take the larger number.  ;)
 

- Dan

[Muthu Ramadoss]

Thanks for the explanation Dan.

Dan Morrill wrote:
>
> 2008/3/28 Stone Mirror <stone...@gmail.com
> <mailto:stone...@gmail.com>>:

--
Thanks.

Muthu Ramadoss
http://mobeegal.in
http://twitter.com/intellibitz http://linkedin.com/in/tellibitz
http://slideshare.net/intellibitz
http://groups.google.com/group/android-chennai
+91 44 22476750

We develop innovative search solutions using LBS for Android.

[Stone Mirror]

On Fri, Mar 28, 2008 at 11:00 PM, Dan Morrill <morr...@google.com> wrote:

2008/3/28 Stone Mirror <stone...@gmail.com>:

there's no community around the Android platform itself

I betcha the other 8,463 current members of this forum would disagree with you.  But then, every forum needs a troll, I guess.

No Dan: the platform, the Android system itself. The part that you haven't released, Surface Manager, Dalvik, the Android libraries themselves (and thanks for being a little clearer around that, I'm pretty sure I've never seen a statement to that effect anywhere previously). I clearly mentioned the two first ones as examples in my email, in fact in the very next paragraph you quote, but I guess it's easier to ignore that and call people names instead.

There's a community around the Linux operating system; actually several communities, including the kernel community, the GTK+ community, the BlueZ community. There are no equivalent communities (or community) for the Android platform. Maybe there will be someday, or maybe there won't.

The open source community at large, historically speaking, hates "code dumps" (aka "toss-it-over-the-wall-ware") especially extremely huge ones. And I'm not sure it's realistic to expect that the folks currently working on GTK, Gstreamer, PulseAudio, BlueZ, and the like--the real open source software community--are going to drop what they're doing to take on Android instead.

The reason we haven't released the source yet is primarily logistical.  One of the team once said "Android will be the largest open source project in the world". That may or may not be technically true, but I think it eloquently captures the scope of what we're doing.  When your project is this large, the simplest questions like governance become a big deal.  Dalvik by itself is huge, and so are Binder, SGL, etc.  Should we have a single gigantic source tree or split up into multiple smaller projects?  Anyone who's ever worked in open source knows that it can take a long time to come to consensus on decisions like that.  Once we do, we have to then physically tidy up the source, make sure it builds outside our internal infrastructure, set up a public source repository that can handle the load, and so on.

As I say, I wonder who you expect is going to be rushing in to take it on for you. Evidently the existing work in the open source community wasn't good enough for Google. It seems to be good enough for Moblin, for Ubuntu Mobile, for the LiMo Foundation and numerous others. LiMo had eighteen phones to show at Mobile World Congress.

 

Those are distractions that we can't afford right now since we are working closely with our partners to get the first devices launched.  Our plan is that once we reach version 1.0, we will turn our attention to the squishier issues of releasing source.

Heaven knows, we'd hate to distract you. We'll just keep plugging along on the stuff that actually available now, I guess...

--
鏡石

[Stone Mirror]

Oh, it doesn't make any difference to me, Dan, take your pick. Certainly there's plenty of overlap between the lists, and it seems sure that not everyone on the lists is a developer, much less a professional one. I see an awful lot of "Can I put Android on my iPhone/Treo/Nokia N95...?"

Of course, there's a variety of perspectives. Chris Glover, who is a long-time professional Java developer, has an interesting one on his blog.

--
鏡石

[Dan Morrill]

2008/3/29 Stone Mirror <stone...@gmail.com>:

The open source community at large, historically speaking, hates "code dumps" (aka "toss-it-over-the-wall-ware") especially extremely huge ones.

Yeah, that's definitely on our minds.  We feel pretty bad that we've got such a huge pile of changes that we haven't been able to send upstream.  We understand how open source projects operate, and we'll work with the specific upstream teams to send them our code in whatever way works best for them.

Implicit in your observation is that large dumps are a lot of work.  It would be pointless and rude to dump a huge pile of changes on a project all at once.  Waiting until we can do a good job of releasing the source also means waiting until we can dedicate the attention to the upstream projects that they deserve.

Evidently the existing work in the open source community wasn't good enough for Google. It seems to be good enough for Moblin, for Ubuntu Mobile, for the LiMo Foundation and numerous others.

You seem to be saying that open-source is a zero sum game, and that effort we spend on Android somehow detracts from those other projects.  By your argument, Linus Torvalds was wrong in creating Linux;  he should have bit the bullet and contributed to Minix, instead.

We believe that the more open source code is out there, the better.

We'll just keep plugging along on the stuff that actually available now, I guess...

Please do!  The last thing we want is to force developers to pick a single platform.

- Dan

[Stone Mirror]

On Sat, Mar 29, 2008 at 3:04 AM, Dan Morrill <morr...@google.com> wrote:

2008/3/29 Stone Mirror <stone...@gmail.com>:

The open source community at large, historically speaking, hates "code dumps" (aka "toss-it-over-the-wall-ware") especially extremely huge ones.

Yeah, that's definitely on our minds.  We feel pretty bad that we've got such a huge pile of changes that we haven't been able to send upstream.  We understand how open source projects operate, and we'll work with the specific upstream teams to send them our code in whatever way works best for them.

Well, good luck with that. Which "upstream teams" do you think will be taking on Surface Manager, Binder, Dalvik and the remainder of the never-before-seen portions of the platform (i.e. almost all of it), I wonder...

Implicit in your observation is that large dumps are a lot of work.  It would be pointless and rude to dump a huge pile of changes on a project all at once.  Waiting until we can do a good job of releasing the source also means waiting until we can dedicate the attention to the upstream projects that they deserve.

Sounds like these "upstream projects", whoever you imagine them to be, may be waiting a while. I'm not sure how something like Surface Manager or Dalvik can be released, other than to effectively "dump a huge pile of changes" into some entirely new project... They certainly seem to have no relation to any existing "upstream project".

 

Evidently the existing work in the open source community wasn't good enough for Google. It seems to be good enough for Moblin, for Ubuntu Mobile, for the LiMo Foundation and numerous others.

You seem to be saying that open-source is a zero sum game, and that effort we spend on Android somehow detracts from those other projects.  By your argument, Linus Torvalds was wrong in creating Linux;  he should have bit the bullet and contributed to Minix, instead.

No, that's not what I'm saying. Remember, Linus started Linux for his own edification and amusement, "just for fun", as he put it. There was not nearly the mature open source community in 1992 that there is today. If there were, and if Minix had a significant community around it, then yes, I'd think it might well make more sense for Linus to have worked with that community rather than start a whole new effort from scratch. You're comparing apples and oranges here.

What I'm saying it that--to take Surface Manager as an example--the folks most qualified (outside of Google) to do continuing work on such a project are already working on GTK+ or Qt or compiz or something similar. I don't see that they're going to be interested in dropping those efforts to help Android's Surface Manager out. They may be interested in taking pieces of it to improve specific aspects of GTK or Qt, and thanks to the "developer friendly" Apache license, you won't really be able to keep them from doing so. None of that's likely to help Surface Manager for Android.

There's a finite number of folks working on open source platform development today, that's a simple fact. In order to get those developers to work on Surface Manager, they'd presumably have to free up some time from their current efforts. I'm saying that I believe they're unlikely to do so. So, in a sense, it is a "zero-sum game", but not in the way that you're suggesting.

We believe that the more open source code is out there, the better.

Well, I don't think it's a simple numbers game. I'd suggest that quality, and consonance with existing efforts is at least as important as the sheer number of lines of code out there. There's no shortage of moribund projects. Functionally, Android is in large part duplicative of existing efforts.

Of course, until it's released, the quality of Android's underlying code is unknown and unknowable. As far as consonance with existing projects, there isn't any, and deliberately so--as I said, that was a completely conscious decision that Google made. This is what I mean about Google's unwillingness to work with the existing development communities preferring instead to go the "massive code dump" route.
 

We'll just keep plugging along on the stuff that actually available now, I guess...

Please do!  The last thing we want is to force developers to pick a single platform.

Well, not that you could, even if you wanted to. But if you don't want to "force developers to pick a single platform", why have you created a platform to (or from) which it's effectively impossible to port existing code, and on which one can't use existing languages, frameworks and APIs...?

Let's be very clear here. Rich Miner said:

When we looked at the other [mobile] Linux activities out there, oftentimes they're initiatives that are based on Linux but their resulting platforms aren't completely open. Or they're completely open and they're Linux, but they're missing most of the things that [Android has]. They probably don't have video codecs, Midi sequencer, speech recognition. So they're not a complete phone stack. The goal with Android was to build into it everything you needed to release a phone: an entire stack to build a competitive smartphone or high-end feature phone.

So, why couldn't Google provide just the missing, un-free pieces, for the benefit of existing projects, and work with the community to make improvements where Google felt they were needed, with the community. Why the necessity to come out with a whole new platform to go along with them?

Also, does this suggest that, for instance, Nuance (for instance) is going to be somehow giving away their speech recognition software for free to the world at large, turning what's now proprietary into an open source project? Does it mean that Google is going to somehow pay the patent and licensing fees on behalf of the rest of the world to be able to provide "free" video codecs...? (If the latter is true, I'm sure the Open Media Now! Foundation, for starts, would be happy to hear about it...)

I'm a little skeptical of either of those things happening, actually. Please correct me if I'm mistaken here.

--
鏡石

[Muthuselvam Ramadoss]

Interesting discussion or dare I say different perspectives ;)

--
鏡石
http://groups.google.com/group/EtoE

[Stone Mirror]

2008/3/29 Muthuselvam Ramadoss <muthu.r...@gmail.com>:

Interesting discussion or dare I say different perspectives ;)

I think it's interesting, and we definitely have different perspectives. Dan, apparently, thinks I'm "a troll" for disagreeing with his perspective.

='(

--
鏡石

[Dan Morrill]

2008/3/29 Stone Mirror <stone...@gmail.com>:

Well, good luck with that. Which "upstream teams" do you think will be taking on Surface Manager, Binder, Dalvik and the remainder of the never-before-seen portions of the platform (i.e. almost all of it), I wonder...

Er... we don't expect anyone to; we will maintain them ourselves.

Android consists of several totally new components such as those you listed, and some patches for existing upstream projects (such as Apache Harmony.)  Our engineering teams will maintain our original components going forward;  we don't expect any third parties to assume ownership of these.  When I said that we're sad about having to sit on a large backlog of upstream patches, I was referring to those projects whose software we've used in Android.

Android 1.0 is the beginning, not the end, for our engineers.

 

There's a finite number of folks working on open source platform development today, that's a simple fact.

Finite, but constantly changing.  Once we've cleaned up the source and "push the button" to release it, that number will jump upward by the size of our engineering teams.  We aren't expecting to poach developers from other projects.  We intend to grow the open-source community in every sense.
 

So, why couldn't Google provide just the missing, un-free pieces, for the benefit of existing projects, and work with the community to make improvements where Google felt they were needed, with the community. Why the necessity to come out with a whole new platform to go along with them?

An excellent question!  This is a technical question, though, not an open-source one.  The short version is that we think desktop-based environments like GTK/GNOME and Qt/KDE inherently reflect a desktop way of building applications, and Android's framework is designed explicitly for mobile applications.

In other words, Android has two goals:  First, to be an excellent mobile platform on its merits, and second, to be open and open-source.  We decided the existing efforts didn't meet our needs, so we designed one that does.
 

Also, does this suggest that, for instance, Nuance (for instance) is going to be somehow giving away their speech recognition software for free to the world at large, turning what's now proprietary into an open source project?

That is correct:  Nuance's speech-recognition engine will be open-sourced.  I believe that's one of the things that will be Apache 2.0 licensed.

 

Does it mean that Google is going to somehow pay the patent and licensing fees on behalf of the rest of the world to be able to provide "free" video codecs...? (If the latter is true, I'm sure the Open Media Now! Foundation, for starts, would be happy to hear about it...)

Also correct: the source will be released for the media framework, and the codecs.  As you say, in some cases there are patent licenses that need to be acquired.  I am not involved in the business side of the project, so I don't know what the situation there is, but the traditional industry model in these cases is that the manufacturer, carrier, or retailer pays the license on a per-unit basis.

- Dan

[Dan Morrill]

2008/3/29 Stone Mirror <stone...@gmail.com>:

I think it's interesting, and we definitely have different perspectives. Dan, apparently, thinks I'm "a troll" for disagreeing with his perspective.
='(

Actually, I thought you were a troll because you frequently seem to have an agenda and say the same things over and over.  I now see that you just had a lot of questions and feedback, and had not found a thread to discuss them.  You've made some great points, so it looks like I was wrong -- I'm sorry about that.

Thanks for participating.

- Dan

[Stone Mirror]

Mm. Thanks for apologizing.

--
鏡石

[Stone Mirror]

On Sat, Mar 29, 2008 at 12:46 PM, Dan Morrill <morr...@google.com> wrote:

2008/3/29 Stone Mirror <stone...@gmail.com>:

Well, good luck with that. Which "upstream teams" do you think will be taking on Surface Manager, Binder, Dalvik and the remainder of the never-before-seen portions of the platform (i.e. almost all of it), I wonder...

Er... we don't expect anyone to; we will maintain them ourselves.

Well, that's realistic, anyway.
 

Android consists of several totally new components such as those you listed, and some patches for existing upstream projects (such as Apache Harmony.)  Our engineering teams will maintain our original components going forward;  we don't expect any third parties to assume ownership of these.  When I said that we're sad about having to sit on a large backlog of upstream patches, I was referring to those projects whose software we've used in Android.

Aha. Well, as I said, best of luck with getting those accepted, hope the effort doesn't make you any sadder. It did Nokia, and all they had were 50,000 lines of actual improvements to GTK... Like I said, projects hate code dumps, even worthwhile ones.
 

Android 1.0 is the beginning, not the end, for our engineers.

From the sound of things, and how!
 

 

There's a finite number of folks working on open source platform development today, that's a simple fact.

Finite, but constantly changing.  Once we've cleaned up the source and "push the button" to release it, that number will jump upward by the size of our engineering teams.  We aren't expecting to poach developers from other projects.  We intend to grow the open-source community in every sense.

That's good to hear, too, even if it does guarantee a fairly inward-looking, insular, community, at least for a while.
 

So, why couldn't Google provide just the missing, un-free pieces, for the benefit of existing projects, and work with the community to make improvements where Google felt they were needed, with the community. Why the necessity to come out with a whole new platform to go along with them?

An excellent question!  This is a technical question, though, not an open-source one.  The short version is that we think desktop-based environments like GTK/GNOME and Qt/KDE inherently reflect a desktop way of building applications, and Android's framework is designed explicitly for mobile applications.

Hm. I guess efforts like GNOME Mobile, Ubuntu Mobile, Moblin, GPE Phone Edition, the LiMo Foundation platform, Maemo, OpenMoko and a variety of others are just kidding themselves. They're all using GTK+, and I'd thought they were managing pretty well with it.

Perhaps you're confusing GTK+, an interaction stack, with GNOME, a desktop program, or with the various window managers it can utilize. There's nothing specifically "desktop-based" about GTK that I'm aware of (although the widget libraries need work for smaller screens, something that's again, already being addressed in the open source community). It works quite well for mobile devices with a window manager (also open source) like matchbox.

Can you be more specific about the technical issues you saw? If nothing else, they'd be excellent feedback for the GTK+ community. (I.e., I wouldn't mind hearing the "long version".)

 

In other words, Android has two goals:  First, to be an excellent mobile platform on its merits, and second, to be open and open-source.  We decided the existing efforts didn't meet our needs, so we designed one that does.

Again, no one seems to be clear on just why "existing efforts didn't meet [your] need". "Fighting fragmentation" by introducing a whole different fragment seems a little odd.
 

Also, does this suggest that, for instance, Nuance (for instance) is going to be somehow giving away their speech recognition software for free to the world at large, turning what's now proprietary into an open source project?

That is correct:  Nuance's speech-recognition engine will be open-sourced.  I believe that's one of the things that will be Apache 2.0 licensed.

Now, that's interesting. Is Google going to acquire Nuance or something? While I'm sure companies like Samsung, who are paying license fees for the use of that software now, will be gratified to save the money, I don't see how that leaves much of a business model for Nuance. Maybe I missed something.

Is the TAT framework going to be open sourced as well? And Esmertec's Java VM? Sounds like serious money savings in store for the mobile industry at large, if so, but it'd seem to throw the futures of the companies making their livings with those technologies into some doubt...

 

Does it mean that Google is going to somehow pay the patent and licensing fees on behalf of the rest of the world to be able to provide "free" video codecs...? (If the latter is true, I'm sure the Open Media Now! Foundation, for starts, would be happy to hear about it...)

Also correct: the source will be released for the media framework, and the codecs.  As you say, in some cases there are patent licenses that need to be acquired.  I am not involved in the business side of the project, so I don't know what the situation there is, but the traditional industry model in these cases is that the manufacturer, carrier, or retailer pays the license on a per-unit basis.

Indeed. And passes that cost along to the end user in some way or other. But you seem to contradict yourself: if Google's acquiring the patents and releasing source for the codecs, why would anyone need to pay a license anymore....? Maybe I missed something in there.

Of course, one of the big questions is that, given the non-reciprocal nature of the Apache license, what's to keep anyone from incorporating any improvements they might find in Surface Manager into GTK, or re-purposing those now-free (maybe?) codecs for use with Gstreamer, or getting the now-libre Nuance voice recognition integrated into, say, the LiMo platform...? It'll be dandy for all those projects I mentioned previously, maybe not so helpful for Android: there are a lot more developers working on GNOME-related technologies than Google's likely to be donating to the community to support Android per se... Maybe Google doesn't mind if that happens...

Gonna be interesting.

--
鏡石

[Dan Morrill]

2008/3/29 Stone Mirror <stone...@gmail.com>:

That's good to hear, too, even if it does guarantee a fairly inward-looking, insular, community, at least for a while.

Yes, that's one possible outcome.  The questions you're asking are on our minds, too, but at the end of the day we're just going to have to get the code out there and then work through it.  We realize this is a process, not something that happens overnight.  We aren't going to send somebody an email and then expect to see patches committed by the next morning.
 

(I.e., I wouldn't mind hearing the "long version".)

I'd be happy to talk about it -- although I propose a new thread. :)  Care to start one?
 
 

Is Google going to acquire Nuance or something?

I'm not familiar with the specifics of the relationship with Nuance.  I do not believe that a merger or anything like that is involved, but I am not informed as to what the details are.

Instead let me describe the Alliance in general terms.  The purpose of the Alliance is that members join to contribute something that fills a specific need.  That is, it's not a consortium in the sense where joining amounts more or less to expressing your interest and support of a particular effort.  The Alliance is more like the "core team" of an open source project.  Each member contributes something specific and important to Android.  In some cases that means source code, in others it means expertise.

For instance, Nuance is contributing a voice-recognition engine to open-source, while TAT is contributing their expertise in UI design. Google is contributing Dalvik (among lots of other software) and staff to handle things like marketing and answering questions in the android-internals forum. ;)

Is the TAT framework going to be open sourced as well? And Esmertec's Java VM?

I am not familiar with TAT's products, so I don't know what you mean by "the TAT framework."  TAT is designing the UI for Android, and their designs are being implemented directly on the Android APIs.  I am aware of Esmertec's product line, but I know nothing at all about the details of their contribution to the Alliance, so I can't answer that question.

 

if Google's acquiring the patents and releasing source for the codecs, why would anyone need to pay a license anymore....? Maybe I missed something in there.

I don't think you missed anything, it's just messy. :)  We plan release the source; patent rights to actually sell a phone using them are a separate matter.  I will ask our attorney and see if I can get a more detailed answer to this.

 

Of course, one of the big questions is that, given the non-reciprocal nature of the Apache license, what's to keep anyone from incorporating any improvements they might find in Surface Manager into GTK, or re-purposing those now-free (maybe?) codecs for use with Gstreamer, or getting the now-libre Nuance voice recognition integrated into, say, the LiMo platform...? It'll be dandy for all those projects I mentioned previously, maybe not so helpful for Android: there are a lot more developers working on GNOME-related technologies than Google's likely to be donating to the community to support Android per se... Maybe Google doesn't mind if that happens...

Yes, you've got it exactly -- and not only do we not mind, we'd love to see it happen.  As a general rule, Google prefers the Apache 2.0 license, because we believe it's the most progressive and flexible license available.  We want to make it easy for everyone to benefit, including LiMo and other projects.  We believe we've got a very solid product and we're going to work hard to be very competitive, but we know better than to assume that we're the only ones who can create something cool.

 

Gonna be interesting.

I'm glad you agree!

- Dan

[Jean-Baptiste Queru]

There is no doubt that the patch situation is going to be interesting.
We (Google) don't expect that any project upstream from us would
accept giant code dumps from us, just like we probably wouldn't
accept giant code dumps from someone downstream from us. The
way Android has been developed so far definitely creates some
challenges in the way we'll be able to interact with code maintainers
upstream from us, we're aware of those challenges and don't expect
them to be overcome without some significant and lengthy effort from
our side.

Just like anyone contributing to upstream open-source projects, we
totally expect that project maintainers upstream from us will want to
see cleanly separated patches that each implement a single additional
functionality, and they'll want each of those patches to come with
documentation, code reviews, additional tests, and test results that
are consistent with the standards set by those projects. And we will
expect the same from people downstream from us who want to
contribute back to us. None of that is fundamentally specific to Android
being open-source, and such process constraints can be expected in
any well-run software project, whether Google's or not, whether
open-source or not.

Going further, we don't, can't, and shouldn't believe that every single
one of the changes that we made is going to be suitable for inclusion
upstream. I fully expect some of our changes to be fundamentally
specific to Android, and fully expect that we will decide that we prefer
Android to have those changes while the code maintainers upstream
would rather not have those changes in their code. There's nothing
wrong with that, and it won't prevent us from collaborating with projects
upstream from us in order to avoid drifting and forking. The same is
true for projects downstream from us. And if drifting and forking turns
out to be the both options, we'll do it or we'll let it happen downstream
from us.

There are a few differences between Android (and in fact most cell phone
environments) and desktop environments.

As an example, tasks that involve cooperation between multiple applications
on the desktop typically involve copy-paste, drag-and-drop, or files that
have to be explicitly saved and re-opened. On a mobile phone, it's usually
considered more natural to create stacks of "screens" (the Android Activities).

Also, desktop frameworks aren't necessarily prepared for the notion that
there might not really be enough memory to hold multiple application
processes in RAM, or (worse) for the fact that there might not even be
enough RAM to hold all the screens of a single application at the same
time. It is definitely correct for desktop frameworks to assume that there
is enough RAM for most situations, and that the presence of a hard drive
(and therefore of a swap file) will allow performance to degrade gracefully
when memory utilization increases; in a vast majority of cases it is enough
to let the OS (and by that I mean the kernel) take care of managing the
system's RAM on its own. In a mobile environment, those assumptions
don't really hold: there's not enough RAM, you can't assume that there's
a lot of mass storage (and if there is you have to assume that it's either
slow and prone to wearing out, like flash, or so power-hungry that you
can't have it available at all times, like a hard drive); because of that,
desktop software running in mobile environment tends to me more likely
to corner itself into tight memory situations and to not degrade very
gracefully when conditions get tight.

In those two cases, I believe that we felt that it made little sense to try
to reconcile the two approaches: we believe that both are quite correct
given their constraints, but that they are too different to be both embodied
in a single unified framework.

You'll also notice some other differences between Android and typical
desktop environments, though I won't claim that they're fundamental
(but they're more consistent with the way mobile phones typically work):

-applications running within Android are quite protected from one
another, more than you typically find in desktop environments.

-Android prefers to hide the fact that there's a hierarchical filesystem
and prefers to manage lists of media files regardless of their location.

In the end, we'll all have learned something. Maybe we'll see memory
sizes on cell phones grow so dramatically that traditional approaches
to memory management become practical on a mobile device. Maybe we'll
find that preventing applications from deleting one another's settings is
in fact a good thing to have on the desktop and expand that approach out
of Android into other environments.

Like you said, it's going to be interesting. Very interesting. I'm personally
excited. Very excited.

JBQ

2008/3/29 Stone Mirror <stone...@gmail.com>:

[KunalSingh]

Hi,

I had an impression so far (from whatever publicity Google has done)
that Android is truely open source. In fact I saw statements where it
has been called "open source". But, when I started to look for the
platform code, I could not find any. Surprisingly, on the android
website there is not even a mention about it. At least they should put
their official stand somewhere on the android website. There are
various possibilities. They should clearly mention their stand on the
website.
(1) They do not intend to make it open source
(2) They intend to make it open source - by when?
(3) They are not sure what they want to do?

While trying to get information about this I searched on the web
and found this post. Here I got a clarity on the current status of
android (which I could not get on android website).

Here is my view about what Google is trying to do.

First this text from Android website
"Today, there are 1.5 billion television sets in use around the
world. 1 billion people are on the Internet. But nearly 3 billion
people have a mobile phone, making it one of the world's most
successful consumer products".

After reading the above information, it is not tough to guess what
Google's objective with Android is. Their intention is to catch this
big consumer base of 3 billion people. Google (with their
applications) is already ruling the Desktop world. Now a logical next
step for them would be to rule the embedded world. they have more
reasons to do that because consumer base is continually shifting from
Desktop to Embedded Devices. Today more people opt for Laptops (than
Desktops). Over a next few years more people will opt for embedded
gadgets (than laptops) as these gadgets will become powerful enough to
serve all their needs.
With android Google will achieve the objective of getting their
applications (either applications from Google or applications built
around Google applications) on to the embedded device (starting with
phone). They have decided to call it "open", so that they can leverage
a large work force working for free (from open source developer
community). Their intentions are justified by the fact that they have
only offered an SDK which allows developers to develop applications on
Android - and have released no information on the Android Internals
(other than an architecture diagram).
Google has been clever to announce US$10 million of price money in
various application development contests. This will not only give them
a popularity among developers, but it will also attract more
developers to do work on Android. Again all this price money goes only
to the developers developing application on Android (around Google
Apps) and not to the people who want to work on Android as such (This
again vindicates my view on Google's intentions). The amount of
software development which Google will achieve by throwing away this US
$10 million will be actually worth a few 100 million US$ :-)

Google's policy on Android is no wonder great. It is bound to help
investors who have picked up the Google stock. It is bound to help
every one at Google. It also may (or may not - in the long term) help
the application developers (who intend to work on Android). But for
the developers who are actually interested in working on development
of a mobile platform - this policy really sucks.

I hope I will have a good day :-)

Regards,
Kunal

PS: This is my personal opinion and I do not intend to offend any one
with my opinion. My opinion may or may not match with other people's
opinion (which is the case with every personal opinion). If you differ
in opinion please show the difference by posting what you feel about
it and not by attacking what I feel about it (and not by just
conflicting with what I said.

> 2008/3/29 Stone Mirror <stonemir...@gmail.com>:
>
> > On Sat, Mar 29, 2008 at 12:46 PM, Dan Morrill <morri...@google.com> wrote:
>
> > > 2008/3/29 Stone Mirror <stonemir...@gmail.com>:

> ...
>
> read more »