Android's "Non-Fragmentation Agreement"

superglaze writes "The biggest doubt cast over Android (whose SDK was released yesterday) has been the fact that much of it is licensed under Apache. There have been worries that manufacturers might fork the code road in a non-interoperable kind of way. I.e., they would have no obligation to feed back code to the wider Open Handset Alliance, or even tell the other members what alterations have been made. However, it turns out that Google made all the members sign a 'non-fragmentation agreement' to make sure everything works with everything. In theory at least. 'All of the partners have signed a non-fragmentation agreement saying they won't modify [the code] in non-compatible ways ... That is not to say that a company that is not part of the OHA could not do so.' Google's spokesperson highlighted the historical dangers of working with Java, the programming language that lies at the heart of Android. 'One of the current problems with mobile Java development is that Java has fragmented ... Java virtual machines have fragmented, but all the members of the OHA have agreed to use one virtual machine that can run script in Java'"

Que?

[$1uck (710826)]

How is this google vs apache? I don't understand (its early and I'm feeling fuzzy headed so forgive me). Google is using an apache license to release this... other than that I don't see asf involvement in the project. Maybe I'm missing something here? This article talks about all the involved parties signing an additional agreement separate from the license agreeing not do what MS did to Java before being sued.

So... how is this google vs apache?

GPL solves these problems

[dmoen (88623)]

I agree that the use of the Apache licence is the biggest problem with Android.

If Android had just used the GPL (which prohibits forking), then this problem would have avoided. There are lots of examples to back this up. For example, if Emacs had used the GPL, instead of the Apache licence, the XEmacs fork would never have occurred. And if Gnome and KDE would both switch to using the GPL licence, then the projects would just magically merge into one, and we wouldn't have the duplication of effort and lack of standards that you currently see on the Linux desktop.

Oh, wait... (consults Google). Never mind.

Re:Java? Fragmented?

[jdeisenberg (37914)]

I'm going to lose all my karma points, but here goes...

From this (and other comments in the previous postings about Android), one might get the impression that the people at Google are a bunch of idiots who just didn't do any basic research. Why, if only they had read Slashdot occasionally, they'd know that Java is slow, has 10^6 different versions, is very slow, is inferior to C++, is extremely slow, takes up too much memory, is abominably slow, is a programming language that no real programmer uses any more, and in general is teh sux0rz. <grin/>

Re:Java? Fragmented?

[omeomi (675045)]

behaving rather bizarrely by on the one hand warning about the problems of forking and then on the other releasing their own JVM Dalvik instead of using JavaME.

You've never written a JavaME (J2ME) app, have you? Getting a J2ME application to work properly on all phones is a huge nightmare. Just when you have it working on your phone, and all of your coworkers phones, you try it on your wife's phone, and find that it completely doesn't work. There's plenty of fragmentation just within J2ME, and it's made worse by the fact that it's almost impossible to test an application on every different phone that's out there. If Google can come up with an SDK that makes "write once run anywhere" a reality in the mobile world, I'm all for it.

Re:Java? Fragmented?

[crush (19364)]

That's fine, but you're avoiding the central point: Google are causing further fragmentation and forking within Java at a time when there are significant efforts being made to re-unify and stabilize the platform. Also they've chosen a license which has the potential to allow leachers to benefit from any work anyone does on the distributed code. A pity that they didn't put their efforts into improving J2ME instead.

Re:

[rubycodez (864176)]

or we could say you're missing the point, java is so very fragmented already one more little fragment in the broken heap of glass won't make any difference at all. java: write once, run well only in the IDE of the developer.

Re:Java? Fragmented?

[dintech (998802)]

'Write once, run anywhere'. Hmm, I'm a java programmer and have been for 10 years. I know, as every java developer knows and realises, it actually means 'write once, run on the important places'. Meaning something that works on your desktop PC will also work on the Solaris server you intend to deploy it to.

Mostly people who use 'but I thought you said run ANYWHERE' argument should actually try to think about what that would mean in real terms. For example, should you expect a huge Swing application or something like Weblogic 9 to run on your 8 year old J2ME phone? Be sensible please...

Re:

[EmperorKagato (689705)]

There are Java profiles that work across most cellphones. Most of the new phones implement the profiles with ease.

Re:Java? Fragmented?

[forgotten_my_nick (802929)]

No idea why you got modded off topic. You are correct. Normal J2ME commands will work across all phones. It is when you get into graphics or messing with screen resolution that you have to be aware of different devices. That is why you can get emulators for different screen/phones and test.

Re:Java? Fragmented?

[crush (19364)]

Whoever modded him offtopic was either being childish or desperate to hide the information. Probably just a fanboy.

Reading further on this, the interesting thing about Dalvik is that it's a non-Sun-controlled JVM. The thing about JavaME (aka PhoneME) is that although it (like JavaSE and JavaEE (Glassfish)) is released under GPLv2 [linuxdevices.com], there is no exception clause [java.net] (there is for JavaSE). This means that you can only run GPLv2 code on PhoneME. Obviously Google and it's partners didn't like this, so they wrote their own JVM. In order to avoid infringing on Sun's IP they've made the bytecode unique to Dalvik. So Java goes in ---> Dalvik bytecode comes out, runs on Dalvik. Very clever.

Re:

[gEvil (beta) (945888)]

Isn't the scenario above EXACTLY what this non-fragmentation agreement should help to avoid? Seems like a reasonable way to ensure device compatibility to me. If a non-OHA entity fragments the code, that's fine, because their code/app/SDK/whatever isn't guaranteed to run on all of the devices anyway. If some hobbyists want to create their own derivative platform for device X, they're perfectly free to do so. Seems like all of the benefits of the open source model to me.

With Andriod, you are free...

[WindBourne (631190)]

to develop in non-java. Of course, it may not work on ALL handsets (in fact, all but certain that it will not). But if you do the work in Java, AND use their API, it is being guaranteed to work across all of the handsets. So, what is your gripe?

Re:Google versus Apache

[kevin_conaway (585204)]

In a strange kind of way, this is Google versus Apache. Or, commercial versus non-commercial. I know that this is a ridiculous simplification but it kind of smells that way to me.

How exactly? I don't see it that way

Google releases all their open source under the Apache license. I'm sure they have various reasons for choosing the Apache license, but I'd wager a major one is that it is very business friendly. They most likely understand what a pain it can be to include OSS products that are licensed under a different licensing scheme in a commercial product.

Re:Google versus Apache

[Kadin2048 (468275)]

In a strange kind of way, this is Google versus Apache.

I really don't think it is. This is Google taking the Apache license and then fixing a major perceived weakness in it, at least within the context of their application (creating a single, uniform, mobile platform). And even then, they're not really restricting the software; they're just getting the people who are part of their trade group to agree not to stab each other in the back.

It's not Google "versus" anything or anyone, except perhaps maybe the closed-source phone manufacturers. Certainly not Apache.

Re:

[Kadin2048 (468275)]

Well, if the licensing of the SDK is anything to go by [livejournal.com] it seems more like it's a case of Google vs. Free Software.

Well, we always knew that there were going to be parts of the software stack that aren't going to be Free software. The FCC won't allow the parts that control the radio, for example, to be user-modifiable. So there have to be some big locked-down chunks, just because it's a cellphone.

If Google actually said that the "full stack" would be OSS, then shame on them. But it seems like they're going to be way more open than anyone else, and possibly as open as they can be while still getting FCC approval for the

Re:

[Danny Rathjens (8471)]

But it seems like they're going to be way more open than anyone else, and possibly as open as they can be while still getting FCC approval for the device.

How can you possibly say that when http://openmoko.org/ [openmoko.org] exists?
And I don't think openmoko had any problems with FCC approval and are truly open. "free software" is not all that relevant the type of "locked-down chunks" you are talking about - like 911 location service - since they are "locked down" in the hardware chips (by simply not having certain things controllable via serial interface) and not by any software.

Re:Oh, FORK!!!

[ajs (35943)]

Sounds to me like they don't want anyone forking it.

Read it again. The members can't fork the development. Non-members can. They're just trying to prevent the situation where, 5 years down the line, NTT says "thanks for all the hard work Google, but now that we've achieved brand loyalty, we're going to stop working on our competitor's OS." The idea is to make the cell phone OS a commodity and let cell phone makers focus on higher level features that will work on any phone.

Re:Oh, FORK!!!

[tomhudson (43916)]

Riiight - but who are these potential non-members? Its not like you can have half you development team be members, and the other half non-members.

And its not like there's a huge field when it comes to cell phone manufacturers. There's not thousands of different manufacturers, so google starts out with a de facto quasi-monopoly.

So even if a fork came along that was better, the companies can't use it.

No wonder Microsoft is afraid google will be the next Microsoft - they're using Microsofts' playbook.

Re:

[FinestLittleSpace (719663)]

You have a valid point, however Google /have/ been running Android on mobile handsets. You can see videos of them in action on the main site.

Perhaps they want to avoid symbians mistake?

[SmallFurryCreature (593017)]

Symbian was developed on hardware, on the lowest hardware then available so that it would be sure to run on everything. This made the design obsolete at launch and now it is so archaic(?) that people really resent that original decesion.

Perhaps Google wants to avoid this. Wants apps that push the hardware requirements so that the Android phones will HAVE to be powerhouses, and it doesn't get trapped in the symbian or even MS trap of having to work on the cheapest shit some company can throw together.

Apparently (I only have this from hearsay) symbian phones often miss basic hardware capabilties that drive a pc programmer up the wall because he suddenly has to code for features that have been present in PC's from the dawn of computing.

All google now has to do, is convince mobile phone makers that it is in their best interest to make their phones capable of actually running the software currently being developed.

Don't forget mobile tech moves fast but is expensive. If the companies could get away with yesterdays tech they would. That ain't good for us consumers, we want them to be pushed so we finally get some fully capable smart phones and not the same crippled yunk they have pushing on us.

Re:

[Sancho (17056)]

Perhaps Google wants to avoid this. Wants apps that push the hardware requirements so that the Android phones will HAVE to be powerhouses,

Gosh, I really hope not. Battery technology just isn't there for powerhouse phones :\

Re:

[babbling (952366)]

There is no "speed that real hardware runs at," since each phone running Android software will be different, just like every PC is different. Think of Android as a PC in your pocket that has mobile phone capabilities.

I haven't looked at the SDK, but from what I have heard you can configure the emulator a bit to reflect the capabilities of different types of phones.

Re:

[AKAImBatman (238306)]

it would be incredibly easy to decompile the bytecode back to Java source.

#1 Who cares? Only young'uns with little experience with how the industry works actually care about someone "stealing" their (incredibly boilerplate, easy to duplicate, hard to integrate into my own project) source code. Did you know that it's easy to "decompile" your HTML, Javascript, Actionscript, PERL, Python, Ruby, Shell scripts, and even Assembler too?

Oh noes! Do not want!

#2 The "Java" that runs on the phone isn't Java at all. Ja

Re:

[m2943 (1140797)]

How serious Motorola is about Android when they have just made an serious investment into an Symbian company?

Motorola is already shipping lots of Linux phones (far more than Symbian), but they have almost no developer community. Android might be the answer to their problems.

Motorola just bought half of UIQ from Sony-Ericsson

I think UIQ is a short-term fix for them. I also don't think UIQ is going to make it in the long term. For Symbian, Series 60 is going to be the de facto standard.

Re:Revisionism?

[by Anonymous Coward]

but J2ME phones all run the same code and the same APIs. Issues between phones almost always come down to working around JVM implementation bugs

This is just plain wrong. Once you start looking at graphics, audio, keyboard input, bluetooth, gps, network, photo or video capture or anything beyond very basic apps, you reach the murky world of JSRs, which are bits of java that may or may not be included in a particular j2me installation. If they are included, many of them have lots left up to the implementation to decide, for example MMAPI leaves it up to the implementation whether to support MIDI sound, whether to support playing audio directly from code rather than from a file, whether to support recording, what file formats to support etc. You can't even reliably play audio files across platforms, let alone do interesting things like get at the camera, get video frames etc.

Nokia phones for example, most will let you grab a single frame from the camera, some won't, but you can't grab multiple video frames without a 1/4 second delay per frame, whereas motorola phones, many will not let you at the camera at all, but those that will, will let you record multiple frames properly, except for a few which will only let you take single frames.