Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Google Businesses The Internet Cellphones Communications Programming IT Technology

Android's "Non-Fragmentation Agreement" 142

Posted by Zonk from the i-hate-it-when-my-agreements-fragment dept.
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'"
This discussion has been archived. No new comments can be posted.

Android's "Non-Fragmentation Agreement" More

Android's "Non-Fragmentation Agreement"

Comments Filter:

  • Que? (Score:2)

    by $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?

    • Re: (Score:1)

      by $1uck ( 710826 )
      blah... this was supposed to be in response to someone else and not the main article... I am out of it this morning sorry.

    • Re: (Score:2)

      by rumith ( 983060 )
      I'm not sure how exactly it is Google vs Apache, too, but the Apache License is not the only way ASF is involved in this story: Google's custom Java VM, named Dalvik, is heavily based upon Apache Harmony.
  • I took a look at the SDK yesterday and some of the videos - having done windows mobile development it looks like it will be almost as easy and have a number of similar features.

    My concern with all of this though - is that there is no hardware available.

    One of the things about emulators is that they run really fast, much faster than the actual hardware runs - so it's hard to tell how responsive an application will be. So given that google has been plowing ahead on development but not been testing on real har

    • Re: (Score:3, Informative)

      by 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? (Score:4, Interesting)

      by SmallFurryCreature ( 593017 ) on Tuesday November 13, 2007 @10:54AM (#21336673) Journal

      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: (Score:3, Insightful)

        by 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: (Score:2)

      by $1uck ( 710826 )
      "almost as easy" Are you saying that J2me is easier than this? or... are you comparing to a different embedded sdk?
    • Run your emulator in another emulator, maybe two or three levels deep. Emulators, not virtualizers. That should make it run slowly enough for you.

      (I'm sure there's a way to simply slow down the one emulator, but I just had to post the Rube Goldberg solution...)

    • Re: (Score:2)

      by enjo13 ( 444114 )
      I seriously doubt that they haven't put this on hardware yet. The entire system is a fairly standard set of components...you could flash it onto a number of different reference boards. I would be shocked if they didn't do just that.

    • Re: (Score:3, Interesting)

      by 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.

  • Revisionism? (Score:2, Interesting)

    by AKAImBatman ( 238306 )

    One of the current problems with mobile Java development is that Java has fragmented ... Java virtual machines have fragmented

    Whoa, he-llo? That's a rather interesting (and bold!) statement to be making there. I don't know if Google has noticed, 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. Which isn't that huge of a deal when you consider that "porting" then becomes a straightforward matter of applying a min

    • Re:Revisionism? (Score:4, Informative)

      by Anonymous Coward on Tuesday November 13, 2007 @12:06PM (#21337869)

      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.

      • 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.

        No it is not wrong. Not all phones has camera snapshotting or audio recording capability which is why you need API:s that leaves it up to the manufacturer what to support. The only other alternative is that each manufacturer writes their own API for whatever features their phones support. All manufacturers had such API:s but are now trying to phase them out because it is easier to stick to standards than to invent your own. Which is exactly what Google is doing, which is exactly why they will fail to att

      • FWIW, Android also leaves it up to the handset manufacturers to decide whether or not a particular piece of functionality is available. However, it provides a simple and standardized mechanism to determine whether or not it is, and use it if it is there.

        And besides this, even just having a single VM with a single set of bugs will seriously simplify things - right now entire companies exist for the purpose of making J2ME code run on enough phones to take the thing to market (I know - my brother works at on

        • Re: (Score:2)

          by jrumney ( 197329 )

          However, it provides a simple and standardized mechanism to determine whether or not it is, and use it if it is there.

          try {
          ...
          }
          catch (NoClassDefFoundError e) {
          ...
          }

          Works on any Java VM.

          • Right, but there are problems with try/catch for fragmented services.

            Suppose four different phones implement the same functionality in different ways. Now you've got to have four different try/catch segments, and best case scenario, you're going to trip three of those every time you call the thing. Not only is this slow as all hell (catching an exception is one of the slowest ops in Java), it is an abuse of the exception mechanism. Exceptions are supposed to be used for exceptional situations, not for n

      • Re: (Score:2)

        by jrumney ( 197329 )

        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 c

    • Whoa, he-llo? [Claiming that jvms have fragmented is] a rather interesting (and bold!) statement to be making there. I don't know if Google has noticed, but J2ME phones all run the same code and the same APIs.

      Each time I've developed for a particular phone, I've had to visit the website of the manufacturer and download one or more jars that specify what subset of j2me is supported on the phone. Does this not qualify as having different APIs for different phones?

      Issues between phones almost always come

      • Re: (Score:2)

        by jrumney ( 197329 )
        There are about 4 J2ME vendors that cover 90% of the phone market. The main problem comes from developers who assume that every phone has the snazzy new API they want to use, then find that people with older phones want to use their app too.

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

    This is not as bad as Tivo ... or is it?

    Non-fragmentation my you-know-what.

    • Re:Oh, FORK!!! (Score:5, Informative)

      by ajs ( 35943 ) <{moc.sja} {ta} {sja}> on Tuesday November 13, 2007 @10:31AM (#21336391) Homepage Journal

      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!!! (Score:4, Interesting)

        by tomhudson ( 43916 ) <barbara.hudson@b ... m ['on.' in gap]> on Tuesday November 13, 2007 @10:41AM (#21336497) Journal

        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: (Score:2)

          by jrumney ( 197329 )
          Nokia would be the main non-member Google has to worry about. They are already using Linux on their Internet tablet devices, and are already porting WebKit to GTK so they can use it in place of Opera (which they currently use on those devices), so forking their own version of this platform might be quite attractive to them. Any smaller companies probably have more to gain by using the platform as-is, so they benefit from the upgrades and applications developed by/for their bigger competitors.

        • Re: (Score:2)

          by ajs ( 35943 )

          Riiight - but who are these potential non-members?
          You? Me? The folks at OpenMoko? Just ideas....

    • Forking - and even just the threat of forking - can be powerful forces for coordination. Reducing the freedom to fork tends to centralize control and reduce the size of the community for a project, while also restricting potential innovation. From Stephen Weber's The Success of Open Source (pp. 169-170):

      Forking, like speciation, is an essential source of variation and ultimately of radical innovation. Too much forking would undermine the open source process in the obvious ways that people worry about a

  • GPL solves these problems (Score:4, Funny)

    by dmoen ( 88623 ) on Tuesday November 13, 2007 @10:34AM (#21336415) Homepage
    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: (Score:2, Informative)

      by domatic ( 1128127 )
      What? The GPL does NOT prohibit forking. There are dynamics associated with it that tend to discourage forking but it certainly is not prohibited.

    • If Android had just used the GPL (which prohibits forking), then this problem would have avoided.

      The GPL solves the problem by giving you freedom not by taking it away. Forking is not a problem when code is free as you can tell by looking at the hundreds of "forks" in the Debian repository, or if you look at the thousands of distributions that all get along famously. Java has problems because it was not free and two or three companies were able to control it's destiny. Real community developed and own

      • where you can't be sure the clipboard is going to work across applications
        Just want to add my non-AC voice to this - why don't you cite your examples of where the clipboard doesn't work between applications and we'll see if we can verify them.

      • Re: (Score:2)

        by dedazo ( 737510 )

        The "Linux Desktop" is far more unified than non free equivalents from M$ and others

        No, twitter. I think you don't really understand what "unified" means. It doesn't mean being able to copy and paste text across applications, Microsoft figured that out 15 years ago. It means KParts working with GNOME applications. It means KIOslaves working with GNOME applications. It means KDE apps being bonobo-aware. It means that hilarious "embedding" technology OpenOffice uses is used by other desktop applications as

  • Lets just get it over with - all "GOOG is the AntiChrist" posts please file under this one, so as to have a neat and orderly flamefest.

    Brought to you by the Lawful Neutral alignment since 1984 - "I don't care what you do, just as long as it's in a neat and orderly fashion"
  • Say it isn't so! It's all these guys [wikipedia.org] can do!
  • ...it is largely because cellphone mfgs are so tightly wedded to telecoms that they have little interest in offering a platform that attracts 3rd party development.

    Open up the network, as Google is proposing, and mfgs have to compete more in terms of coherent feature sets and what 3rd party apps they can attract.
  • Can a kind Slashdotter educate an ignorant soul about the gist of the Apache license? I sincerely would like to know.

  • I don't know about you others, but I seriously think that Android is over hyped. Yes, it's Linux based platform for mobile devices, but so what? There's already Maemo, but you don't see it hyped to death. Yes, the Android can also run Java ME applications, so what? All mobile phones can run Java ME applications...

    And one last thing... there are no devices yet! No nothing! And you know what, there probably won't be even many of them. If you look at the alliance that Google has put together, the only serious

    • Re: (Score:1)

      by ElBeano ( 570883 )
      I'm guessing you are posting from another country. Japan, perhaps? The point isn't the hardware. The point isn't even the software. The point is creating a different paradigm for phones and service in a country with an oligarchic mess, one that is open and free of extraordinarily ridiculous limitations. In this environment, it really only takes one hardware manufacturer with enough courage to step out of line to shake things up.
      • Right (ATTN MODDERS see parent)

        Apple got Time's invention of the year nod-- not for the device but for the breaking of an anti-consumer technopoly.

        This isn't about Google /choosing/ linux, its about the calvery finally showing up to address the crippling backwardness of a corrupted FCC/MEN/Telecom bloc. The Linux, apache, GPL, fork driven is hopelessly beside the point. This is a political seachange,far more than a technical one.

        AIK

    • Re: (Score:3, Insightful)

      by 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.
    • The difference between Android and other, similar projects is that Android has huge backing from Google and 33 other companies. That means that it is guaranteed to be the most widespread operating system for mobile phones.

      That Google has released the SDK early and is running a "competition" for applications that ends before the first phone will even be released guarantees that there will be cool and interesting software available for these devices as soon as they are released.

      One open platform on almost eve
  • So long as the person fragmenting the platfrom hasn't used a Java obfuscator then it would be incredibly easy to decompile the bytecode back to Java source.

    • Re: (Score:3, Informative)

      by 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

  • 'All of the partners have signed a non-fragmentation agreement saying they won't modify [the code] in non-compatible ways

    To me that reads as they could close off the code and fork it into a proprietary monster as long as everything is still 100% compatible with the Google framework (user apps run correctly, etc).

    So you still can't modify the source code on your phone and run the changes. I bet they are still going to lock down the phone software with DRM (Example.. Motorola A1200)

  • "We've built some interesting applications for Android, but the best applications are not here yet, and that's because they're going to be written by developers,"
    It seems that most of Skyne^WGoogle's code has been written by robots so far. WATCH OUT!
  • One Java to rule them all?

Slashdot Top Deals

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Close