Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Software GNU is Not Unix Sun Microsystems IT

Open Source And Closed Standards? 219

Posted by timothy from the you-must-be-this-tall-to-enter dept.
jaaron writes "Can open source and closed standards work together? That's the question asked by Kevin Bedell in his O'Reilly weblog article. The issue springs from questions on an OSI mailing list, hinting that Sun Microsystems is looking for an open source license that would require derivatives to maintain test suite compatibility. Under such a scheme Sun could maintain control of the Java API but allow open implementations."
This discussion has been archived. No new comments can be posted.

Open Source And Closed Standards? More

Open Source And Closed Standards?

Comments Filter:

  • Maybe a bit off topic (Score:5, Interesting)

    by jmcmunn ( 307798 ) on Sunday September 26, 2004 @09:28PM (#10359098)

    But after reading the article, the one thing that sticks out to me is "What if the test suite is flawed, or has a bunch of bugs in it?" So then the test suite that has gone out to everyone unmodified, and then it circulates a few hundred times before people find the bug...then you have tons of stuff designed to work with a flawed test suite and when the test suite is fixed, there is the potential that previously working code (tested with the suite) will be broken! Maybe I am just a pessimist....

    • Re:Maybe a bit off topic (Score:5, Interesting)

      by Tony-A ( 29931 ) on Sunday September 26, 2004 @09:40PM (#10359186)
      No, methinks you are an optimist.

      "What if the test suite is flawed, or has a bunch of bugs in it?" [Emphasis added]

      What if many test suites are flawed and have a bunch of bugs, all different?

      • Re:Maybe a bit off topic (Score:4, Insightful)

        by Minna Kirai ( 624281 ) on Sunday September 26, 2004 @10:59PM (#10359656)
        What if many test suites are flawed

        RTFS. The whole point of Sun's proposal is that there can be only one [geocities.com] test suite. They want to release Java code including a test suite, so that whoever recieves that code can't redistribute it unless that test suite works. Not some random test suite, but the specific test code included by the original author.

        • Re:Maybe a bit off topic (Score:4, Insightful)

          by Tony-A ( 29931 ) on Monday September 27, 2004 @02:46AM (#10360500)
          "New bugs for Old!"

          We can be reasonably assured that there will be bugs in that one test suite. Eventually they will become known bugs. Well technically, an obviously buggy implementation will pass the official test suite.

          A different test suite will cover those now known bugs, but introduce some unknown bugs. If you are risk-averse, then trading known bugs for unknown bugs is not a good idea. I think that some of the stuff that Sun does involves things that are very risk averse.

          Changing standards is a very awkward and time-consuming process. Look how long it has taken the USA to switch to the metric system.

      • Re:Maybe a bit off topic (Score:2, Funny)

        by Anonymous Coward
        So now you know how us web developers feel

    • Re:Maybe a bit off topic (Score:4, Interesting)

      by Anonymous Coward on Sunday September 26, 2004 @09:43PM (#10359204)

      I think that you can take it as a given that there already is a Java API test suite, it just never makes it outside of Sun. Regression testing is a basic step in serious engineering these days, hardware or software. You would have an almost impossible task to convince me that Sun doesn't have one for such an important piece of technology as Java.

      Getting a new form of licensing would just let Sun take Java in new directions.

    • When you are coding to a written API, you wouldn't be just getting your code to get the right answers out of a test suite. Your code will actually be testing the test suite's correlation to the written API.

    • Its called a trademark silly (Score:4, Interesting)

      by gr8_phk ( 621180 ) on Sunday September 26, 2004 @09:59PM (#10359295)
      Require people to pass the test suite in order to use the trademarked name. It doesn't matter. There is already an open source JAVA implementation in the works. Sun should either GPL their JAVA implementation and play an active role in its development or go away and leave others to do the job (with or without their code).

      • there is a precedent for this (Score:5, Interesting)

        by JoeBuck ( 7947 ) on Sunday September 26, 2004 @10:30PM (#10359480) Homepage

        The DoD retained the trademark for Ada, and you have to pass the test suite to call your implementation Ada. The GNU Ada Translator (GNAT) passes just fine.

        • Re:there is a precedent for this (Score:5, Informative)

          by dvdeug ( 5033 ) <dvdeug@NoSPaM.email.ro> on Sunday September 26, 2004 @11:33PM (#10359833)
          you have to pass the test suite to call your implementation Ada.

          That hasn't been true for a long time; I don't believe it was ever true for Ada95.

          The GNU Ada Translator (GNAT) passes just fine.

          That's half true. There exists a version of GNAT, several years old, that on a one (a small group?) of systems, again several years old, it has been certified to pass. There is a much larger group of systems and versions that it passes on, although it's never been checked officially. As for the versions that many distributions ship based on GCC 3.x, they generally don't pass all the tests.

          • Re:there is a precedent for this (Score:4, Insightful)

            by Tony-A ( 29931 ) on Monday September 27, 2004 @06:15AM (#10361001)
            As for the versions that many distributions ship based on GCC 3.x, they generally don't pass all the tests.

            Which could help explain why Sun is so sensitive about it.

            If you have to depend on something, you need to be able to depend on that something. A fixed test suite help assure that at least the bugs don't keep changing on you. As things get more complicated, faster, and more out of sight, everything really has to be better just to break even.

      • Re:Its called a trademark silly (Score:4, Interesting)

        by Rinikusu ( 28164 ) on Sunday September 26, 2004 @11:12PM (#10359713)
        I'm not a moron in real life, I just play one on /. Help me out here.

        Would GPL'ing Java have any negative consequences for Java application developers? I.E., if I use a GPL'd Java, would I be required to GPL my application? I know that there is already some concern about using the GPL with Java Applications, but I'm mainly concerned about the Java itself.

        I currently use Java (1.4.2 on OS X and 1.5 RCx on Win32) and LWJGL (lightweight Java GL), which is BSD licensed, mainly because I want to maintain control over my creations without giving away my code (preferring a Carmack approach: Sell the game, then release the code after game sales have slowed to the point of "don't care". No, I haven't actually released any games, Thanks for Asking.. :) ). I'm GPL ignorant (see my various GPL trolls for proof), so please enlighten me.

        • Re:Its called a trademark silly (Score:2, Informative)

          by Anonymous Coward
          uhh, think about it for a second. people don't have to "release" thier code under the GPL even though they build and link it with gcc.
        • No, you wouldn't. You aren't altering the base Java code, so you'd be fine. Just like you can run closed source like Oracle on Linux.

        • Re:Its called a trademark silly (Score:3, Informative)

          by Anonymous Coward

          Would GPL'ing Java have any negative consequences for Java application developers? I.E., if I use a GPL'd Java, would I be required to GPL my application?

          For a GPL "javac", no; e.g. gcc is GPL, but programs which are compiled with it don't have to be.

          For GPL class libraries, yes, as the program would be a derivative work of the libraries; e.g. the readline library is GPL, and can only be used by GPL programs (at least, that's the stated opinion of the FSF's lawyers).

          • The golden bridge of a good license. (Score:4, Insightful)

            by Combuchan ( 123208 ) <seanNO@SPAMemvis.net> on Monday September 27, 2004 @08:34AM (#10361658) Homepage
            To that end, we have the Lesser GPL [wikipedia.org], which would allow compiled applications themselves to be closed-source.

            It's funny you mention readline, because I seem to recall there being some disagreement about it being GPL'd as opposed to LGPL'd. In the FSF's [gnu.org] opinion on the subject [gnu.org], "releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline."

            It is paradoxical here that the FSF dims their own light on behalf of their own greater good. In the case of readline, and I'm sure a possibly GPL'd java class library, is that when the license which inhibits adoption by closed-source folks who wish to develop in their own manner, these same closed-source folks will instead opt for a more restrictive/liberal alternative (depending on your point of view) that enables them to continue to do what they've been doing all along--develop closed-source software. This slows the overall adoption rate of open-source software.

            Open-source seems to grow best when it's not forced down our throats or dangled in front of us like an unattainable carrot. The ideal solution should be to showcase the power of open-source in combination with the freedom to do what you want with it, including using it in closed-source. This greatly assists open-source's wide-scale adoption. Lao Tsu said it best: "Build your enemies a golden bridge to retreat across."

            Look at GCC and friends--closed source software built on GPL'd and LGPL'd libraries released for open-source platforms such as Linux increases that platform's market share. Regardless of how you perceive Flash and RealPlayer1, they are both closed-source applications that help Linux be a better desktop OS because you can easily view a good chunk of the WWW with it without having to learn about swfdec or mplayer/xine, respectively. And people all over can move their IIS/Oracle/ASP application letter by letter to LAMP2--all because interoperability with the closed and open is possible.

            In summary, let the open and the closed comingle, because the open will certainly prevail.

            1. It should also be noted that once in the open-source world, people will be more prone to ditch those closed-source holdovers in favor of the aforementioned open-source (and many times superior) alternatives.

            2. Substitute L for F, N, O, H, as applicable. The P can stand for whatever the hell you want--I'm not getting into that tonight. ;)

            --sean

      • Re:Its called a trademark silly (Score:5, Interesting)

        by OverflowingBitBucket ( 464177 ) on Monday September 27, 2004 @01:05AM (#10360156) Homepage Journal
        I would have to say that my first impression is that your solution sounds like a great idea.

        However...

        Remember that Sun did get stung a bit back by a little Java-like offshoot that wouldn't have passed their test suites. Remember Visual J++? Trademark protection wouldn't have helped there, J++ != Java.

        They are probably looking to avoid a repeat of the same "mistake".

      • Re:Its called a trademark silly (Score:5, Informative)

        by remi2402 ( 816874 ) on Monday September 27, 2004 @02:59AM (#10360536)
        This is exactly how OpenGL works.

        There is an open published standard that any developer can use for free or non-free software. For OpenGL implementations, they have some sort of dual-licensing. FOSS operating systems have a free (free beer) license. However closed source implementations have to pay a fee.

        No matter what kind of software is created, they *all* have to pass a compatibility test suite, created and managed by the ARB. With revison numbers, the OpenGL standard is fairly easy to follow and to extend. (1.2, 1.3, ...) All non-standard extensions just can't begin with glXYZ(). Official extensions begin with ARB_XYZ and in the next version(s), they turn into glXYZ() once they have been formaly approved.

        While OpenGL has been criticized for being slow to face competition from Direct3D, the standard is here to stay, clearly defined.

        IMHO, Sun should look into OpenGL type of managment. It looks very close to what they are trying to accomplish.
        • Actually the way Open Source has generally approach the OpenGL mark licensing and testing is not to call itself OpenGL, but to use names like Mesa.

          Ditto Linux is not Unix.

          Ditto a collection of Red Hat Enterprise Linux sources rebuilt by someone else is not RHEL but Tao/Whitebox/etc.

          This is a solved problem and the trademark like approach works. Vendors will certify to the 'real thing' unless there is some very strong variant in the market.

      • Your argument seems to hinge on the idea that all Sun owns right now about the Java platform is their own implementation and the trademark. But that's not true: Sun has much strong intellectual property rights, and they have demonstrated time and again that they are not willing to give up those rights.

        For example, you cannot write an open source implementation from Sun's specifications (see here [newsforge.com] for RMS's take on it). Furthermore, Sun has numerous patents on technologies related to Java; it looks like som
    • ...then you have tons of stuff designed to work with a flawed test suite and when the test suite is fixed, there is the potential that previously working code (tested with the suite) will be broken!

      Welcome to standards development! Since you have such a good understanding of the process, let's get you to work right away!

      (I'm serious...multi-thousand-page ISO documents are nauseating)

  • Why even bother open sourcing Java then? (Score:5, Interesting)

    by chrispyman ( 710460 ) on Sunday September 26, 2004 @09:28PM (#10359100)
    When you have a license that restrictive, though it would be benefitial in maintaining compatibility with Java VMs & apps, wouldn't this basically restrict you from doing much with Java other than perhaps speed hacks and porting to some obscure OS?

    • Re:Why even bother open sourcing Java then? (Score:4, Insightful)

      by Anonymous Coward on Sunday September 26, 2004 @09:47PM (#10359222)
      Depends. There are lots of things that you could do, depending upon the form of the license. You could reimplement the guts of java in the language of your choice, such as C#, pascal, or ada. You could add functionality to the JVM or language, if the license allowed it. You could optimize the compilers for different purposes. You could develop instrumented JVMs. Lots of things.

      And don't forget, the reason for Java is compatabilty. If you don't care about that, then it really isn't Java. Just roll your own and insert whatever you want.

    • Re:Why even bother open sourcing Java then? (Score:5, Interesting)

      by anonymous cowherd (m ( 783253 ) on Sunday September 26, 2004 @09:53PM (#10359264) Homepage
      Not quite. You could add additional features to the language that are not tested by the test suite. The fun comes when future versions of the test suite/standard break your code.

      Sun should just take a lesson from the Python Software Foundation. Although I don't like how Python's current implementation basically acts as a de facto standard (there should be a real standard rather than just a reference implentation that doesn't really reference anything), Python's implementation and "standard" are both open. Anyone can take Python and fork it in incompatible directions. Just take a look at all the posts in comp.lang.python regarding Python-derived languages.

      How has this affected Python? Not a bit. If anything, it's encouraged innovation through the Stackless and IronPython projects.

      I think what Sun is really worried about is trademark dilution. If that is the case, why not just specifiy that any derivative works must be named something other than Java? The only practical effect this would have is to make the licence GPL incompatible, since most people will rename a fork anyway. However, it does preserve Sun's trademark.

      Sun could still certify implementations as Java compatible, giving them the right to use the phrase, too. If there were a reasonable fee involved for certification, then Sun wins another revenue stream. It's a win-win.

      Why is this so difficult for Sun to see?

      • Re:Why even bother open sourcing Java then? (Score:5, Insightful)

        by Chandon Seldon ( 43083 ) on Sunday September 26, 2004 @10:49PM (#10359600) Homepage
        The "Trademark Java and don't let people call things Java that aren't Java" plan works perfectly. If it doesn't adhere to Sun's Java standard, there's no reason anyone should be calling it Java anyway.
      • Except Python isn't a business and so they don't care that they don't have control over it, on the other hand Sun is, and they want control, but don't want to alienate a whole community of talented developers who place more in the license of a product over its use as a simple tool.

        Sun doesn't have to worry now about trademark dilution, since if they say it isn't Java, and a little lawsuit would solve that. What Sun wants is to have the more zealous of the OSS developer, the more moderate already chooses Ja
      • Sun could still certify implementations as Java compatible, giving them the right to use the phrase, too. If there were a reasonable fee involved for certification, then Sun wins another revenue stream. It's a win-win.

        Why is this so difficult for Sun to see?

        Assuming infinite manpower, that might be a feasible option, but I doubt Sun has that. They may think their time and resources are better spent keeping up with MS by advancing Java in a less fractured way. Then again, IANASE.

      • Re:Why even bother open sourcing Java then? (Score:4, Funny)

        by R2.0 ( 532027 ) on Monday September 27, 2004 @01:00AM (#10360139)
        "I think what Sun is really worried about is trademark dilution."

        You mean, in excess of their own trademark dilution? They've been slapping the "Java" name on everything but the toilets at HQ.
      • But java stands out as a target from companies (most notably MSFT) that care to destroy its 'write once run anywhere' philosophy. Java has been a target, and might be again, because it is much more relevant (especially in the enterprise software world) than languages such as python, perl and ruby.

        Therefore I think sun cannot simply take those as an example.
      • Although I don't like how Python's current implementation basically acts as a de facto standard (there should be a real standard rather than just a reference implentation that doesn't really reference anything)

        Errrr, a reference implementation is something that is referenced by other things, not something that references other things.

        Actually a reference implementation is a cheap and effective way to define a standard. The standard is what the reference implementation does. What the standard should be is

    • Re:Why even bother open sourcing Java then? (Score:5, Insightful)

      by gehrehmee ( 16338 ) on Sunday September 26, 2004 @10:34PM (#10359500) Homepage
      I think you're sort of mis-reading Sun's intention on this. I don't believe they have any interest in restricting what we, the open-source community can do with it.

      What they want desperately to avoid is being screwed the same way they've been screwed so many times before: Microsoft swings in, take what Sun (or the W3C in the case of HTML&Friends) and shattering it into independant & incompatible implementations that eliminate one of the project's main goals: Interoperability.

      I believe Sun is trying very hard to let the open source community take the code and run with it as its done with so much other software, but without letting MS tie it to a You-Require-Windows-To-Work-In-The-Real-World business model.
  • that if I made a derivitave and then released something with a bug in it that breaks the test suite, it's not allowed in the license? Feh!

    Just go with the GPL so you can legally steal whatever code you need back.

  • Bah (Score:5, Insightful)

    by ThoreauHD ( 213527 ) on Sunday September 26, 2004 @09:29PM (#10359103)
    I'm gonna stay out of this one flame war. When diversity means less options, then I'm all for closed. Until then.. Darwin is in control.

    • Re:Bah (Score:5, Funny)

      by antifoidulus ( 807088 ) on Sunday September 26, 2004 @09:40PM (#10359185) Homepage Journal
      Darwin is in control.
      Great, now you have to add a Mac flamewar into an already flamewar-prone topic!
      • Great, now you have to add a Mac flamewar into an already flamewar-prone topic!

        No no no, you're getting them confused now. It's Burger King (a.k.a Hungry Jacks in some places) that has the flame-grilled burgers - Big Macs are not flame grilled! ;-)

    • Re:Bah (Score:2, Interesting)

      by builderbob_nz ( 728755 )
      Survival of the fittest may be seen as a good idea for software, but one thing I don't like about it is what happens when the fittest is flawed and the unfit aren't?

  • Open source + Closed standard = Closed (Score:4, Insightful)

    by mind21_98 ( 18647 ) on Sunday September 26, 2004 @09:29PM (#10359108) Homepage Journal
    By definition, anything created to satisfy a closed standard leaves very little room for improvement. If you have to build around a crappy API, you can't improve the API. In order to have a fully open source application, you must build around open standards as well. Otherwise you'd have some very nasty license issues.
    • What do you mean by "nasty license issues?" I don't see how coding to a given API can result in this... If the product does not meet the given guidelines, the standards body could sue for breach of contract. Sounds simple to me.
    • You're taking the wrong approach to improving the API. The standard says that API(x) has to behave some broken way. So that you don't break the existing apps you have to implement API(x) with the broken behavior.

      But nothing is stopping you from implementing API2(x) with the correct behavior. If API2(x) is a good enough solution it will probably be incorporated into the standard API the next time around. API/API2 lets both older and newer apps run without breaking each other.

    • Re:Open source + Closed standard = Closed (Score:5, Interesting)

      by iabervon ( 1971 ) on Sunday September 26, 2004 @10:06PM (#10359343) Homepage Journal
      Linux conforms pretty closely to POSIX and SUS, which are closed standards. GCC conforms to ISO C99 (at least, when you tell it to). Firefox conforms to RFC 2068 and HTML 4.01. Most OSS programs conform to some standard or other. Most projects are not able to change the standard and unwilling to break compatibility.

      The real issue is how much is left unspecified by the standard and available for innovation. Good standards will contain well-defined areas of uncertainty, where the behavior is entirely up to the implementation to specify, with good ideas coming to be required parts of later standards.

      In the case of java, any option starting with -X to either java or javac is non-standard. So you just have to make your exciting new features depend on a -X flag and you'll pass the test suite (which, by definition, won't use any non-standard options).
      • Linux conforms pretty closely to POSIX and SUS, which are closed standards.

        Compared to Java, they aren't closed at all. Despite the existence of an impotent "community process", the Java standard is 100% Sun property. Scott McNeely could totally change the meaning of "Java" every 15 minutes if he wanted to.

        Do you want him to be able to take away your work just because it's based on a "Closed Standard" Sun decided to rewrite?

        Firefox conforms to RFC 2068 and HTML 4.01.

        What do you think a "closed sta
        • Have you actually read the standard licensing information for RFCs [rfc-editor.org]? Once an RFC is published, it's pretty much set in stone. You need the permission of the author in order to reformat it, let alone make any substantial changes to it. The main difference between Java and RFCs is that people care about using the trademark "Java" for whatever they're doing, while "RFC 2068" isn't worth trademarking, let alone trying to apply to modified versions.

          Really, standards should only be replaced and never modified. No
      • Linux conforms pretty closely to POSIX and SUS, which are closed standards. GCC conforms to ISO C99 (at least, when you tell it to).

        Yes, but Linux conforms to those standards that its users want it to conform to, not to the standards that some other entity says it has to conform to.

        That makes a huge difference in practice because it allows junk that users just don't want to be removed from the system.

        Furthermore, allowing Sun to set compatibility standards and tests means that, for all practical purpose
  • "Can open source and closed standards work together?

    No they can't really, and even if it were possible why wouldn't people just use Eclipse?

    "Under such a scheme Sun could maintain control of the Java API but allow open implementations."

    Sun never learns. When they got into fight over java with Mircrosoft the result was MS making .NET. When will Sun decide to open Java up when Java becomes as much as an underdog/hasbeen as Solaris.

    No one cares anymore Sun, the community is just routing around you and s

    • Re:Sun will Wither Away (Score:2, Interesting)

      by Anonymous Coward
      Great comment. Unfortunately devoid of facts in reality. Java is somewhere between the 1st and 5th most desired language experience in IT, depending hugely on area. .NET has been out for a couple years now, but is only being adopted widely within organizations that already had adopted M$ technologies for implementation. At the end of the day, it simply means that .NET has been used as an upgrade for some inferior MS deployments .. like the fabulous ASP/VB/COM combination.

      Java solved the problems with these

    • Re:Sun will Wither Away (Score:5, Insightful)

      by thisgooroo ( 685374 ) on Sunday September 26, 2004 @10:41PM (#10359548)
      "Can open source and closed standards work together?

      No they can't really

      tell me, how open are posix, ANSI C, or the internet standards? are linux, *bsd, apache open source or not?

      "Under such a scheme Sun could maintain control of the Java API but allow open implementations."

      Sun never learns. When they got into fight over java with Mircrosoft the result was MS making .NET.

      MS put out an incompatible java in yet another attempt to control the internet. in order to prevent that, sun had to do something. so MS didn't like the outcome and decided to do its own standard. fine, but at least we can pretty much rely on the java we have installed on our systems run whatever claims to be java

      • tell me, how open are posix, ANSI C, or the internet standards?

        POSIX, ANSI C, and the Internet standards are completely open: you can implement them in whatever way you like. There are no mandatory compatibility test suites for your implementation. Only if you want to have your implementation certified do you have to pass official tests.

        fine, but at least we can pretty much rely on the java we have installed on our systems run whatever claims to be java

        Fine, but at least we can pretty much rely on t
    • "Can open source and closed standards work together?

      No they can't really, and even if it were possible why wouldn't people just use Eclipse?

      So you're telling me that the Samba project doesn't work? At least Sun gives away a test suite - with SMB you have to do a lot of network snooping to verify things are working correctly.

      When they got into fight over java with Mircrosoft the result was MS making .NET.

      Part of the $2bn settlement was due to M$ inability to make .NET without infringing on Sun's pate

    • "Can open source and closed standards work together?

      No they can't really,

      Closed standards:
      meter as a measure of distance.
      second as a measure of time.
      liter as a measure of volume.

      These are closed in that neither you nor I stand any chance of changing anybody's mind as to what they should be.

      When everybody gets to mess with the standards the standards cease to be standards.

  • Possibly (Score:5, Informative)

    by Lancaibheal ( 813222 ) on Sunday September 26, 2004 @09:33PM (#10359141)

    Possibly.

    It depends on just how "closed" the closed-source component of the partnership is. If it's something like Java, which is mostly open in its technological aspects, but legally closed, and there is an undertaking from the owner that there will be no GIF-style schenanigans, then why not?

    On the other hand, if we're talking about, say, the MS Word "standard", then I just don't think that a partnership with Open Source is possible. There's no real reason why an Open Source project would need to use such a standard anyway, so I think the answer probably has to be "probably not"

  • Open Source Works with Closed Standards:1 Caveat (Score:5, Insightful)

    by reporter ( 666905 ) on Sunday September 26, 2004 @09:34PM (#10359148) Homepage
    Open source can work with closed standards under 1 caveat: the open-source programmers may need to rename a variant on the closed standards.

    The situation is analogous to building a chip that runs an instruction set architecture (ISA) owned by a competitor. The ISA is a closed standard in the sense that the company owning the ISA has trademarked its name. For example, MIPS technology trademarked the name "MIPS". A competitor, Lexra, then implemented a subset of the MIPS ISA, omitting 2 instructions. Lexra said that its chip is MIPS ISA compatible. MIPS sued and won. If Lexra had, instead, labeled its chip "MIPS ISA flavored", not "MIPS ISA compatible", then there would be no legal problems.

    Another good analogy is Microsoft incorporating the Java runtime environment in its browser. The environment was not fully compatible with Sun's closed-standard for the Java runtime environment. Sun sued and won. If Microsoft had claimed that the browser was equipped with a "Java flavored runtime environment" or "JavaPlus[tm] runtime environment" (and trademarked "JavaPlus"), then there would be no legal problems.

    I do not see a problem here.

    Open source is now a credible movement. The open-source development lab (OSDL) and the free software foundation (FSF) have sufficient clout that if any team of talented programmers created a language called "JavaPlus", derived from and mostly (but not entirely) compatible with the closed-standard Java, there is the strong likelihood that JavaPlus would come to dominate the market for Java. Then, Sun would need to kiss OSDL's or FSF's ass. Sun would be forced to alter the Java standard to make it compatible with JavaPlus.

    Sweet. Sweet revenge.

  • This is BS (Score:3, Insightful)

    by Anonymous Coward on Sunday September 26, 2004 @09:35PM (#10359152)
    All Sun has to do is to publish a standard Solaris OS specification (similar to whats done with SPARC) and then GPL the OS.

    GPL offers protection to individual developers that they will be able to freely benefit from improvements to their contributions anyone makes without having to fork over money. The problem with BSD is that if a company uses your source in a closed product you dont get any future benefit and if you want to use their product you have to pay.

    Open source developed Solaris OS'es should have the ability to claim compliance to whatever revision of Solaris.

    Sun can charge a fee to do compatibility testing. In theory though it should be possible for third parties to also engage in the certifying compliance business .. if they do a half ass job ..they just won't be trusted.
    They will have to have their own logo though and not be allowed to use a Sun certified Solaris specification compliant logo

    • Re:This is BS (Score:2, Insightful)

      by psetzer ( 714543 )
      It would be nice if Sun decided to open their intellectual property up, but right now they are in dire straits. Asking them to throw away all of their software sales in exchange for entering a different market is asking them to really risk their livlihoods and their business on something that may not pan out. Every time the open source community tells Sun to make the leap, I wonder if they've thought about the consequences and are willing to support Sun, or if they just want to cannibalize Solaris and Jav

    • Re:This is BS (Score:5, Insightful)

      by Eivind Eklund ( 5161 ) on Monday September 27, 2004 @02:35AM (#10360464) Journal
      You are repeating a lie.

      As a developer with the FreeBSD project, I can say with certainity that there do come benefits from proprietary derivates of BSD-

      Specific examples:

      • The entire SCSI subsystem of FreeBSD (CAM) comes from a proprietary derivate
      • The entire netgraph subsystem (network transformation system) comes from a proprietary derivate
      • Many of our core developers are employed by companies making proprietary derivates
      • The mpd multilink PPP daemon came from a company that made a proprietary derivate
      We've also got a ton of other submissions, but bugfixes and feature enhancements.

      Now, we can have an economics debate about which license results in the most contributions - but claiming that "if a company uses your source in a closed product you dont get any future benefit" is plain misinformation.

      Eivind.

  • I think it's brilliant (Score:5, Insightful)

    by yaphadam097 ( 670358 ) on Sunday September 26, 2004 @09:46PM (#10359218)

    Maybe it's just because I've been doing Java development exclusively for the past three years. Or, maybe it's because I've been doing Extreme Programming exclusively for the last two and this gels extremely well with the idea of Customer Tests which are at the core of what I do. But, I think this is absoulutely brilliant.

    Essentially, "Do whatever you want, but you can't call it Java unless it passes our compatibilty suite." Thus the core vision of "write once run anywhere" is preserved but the community is given the freedom (And, yes, I do know what that word means) to enhance and bugfix. BTW, it is already pretty easy and wouldn't become any harder to expand beyond core java by adding additional libraries. The difference would be that you could distribute the whole thing under a single open source license.

    The one thing you couldn't do would be to change the language itself. But then, maybe I'm missing something, but if you don't care about compatibility why use java in the first place?!? It's not like there aren't good alternatives out there that will let you do whatever you want (Perl, Python, C++, etc.) The whole advantage of Java is that it is so prolific, and it is so because of it's rigorously maintained compatibility/portability (And strong advocacy by Big Blue among others... who like it because of it's portability across the many platforms they offer and support.)

  • Doesn't really mix (Score:5, Insightful)

    by joe_plastic ( 704135 ) * <stephen...pollei@@@gmail...com> on Sunday September 26, 2004 @09:49PM (#10359244) Homepage Journal
    If Bob Scheifler had read the Open Source definition [opensource.org] he would have noticed that maybe criteria 8 and 10 contends with what he wanted to accomplish.

    8. License Must Not Be Specific to a Product: The rights attached to the program must not depend on the program's being part of a particular software distribution.
    His test suite would be another program.

    10. License Must Be Technology-Neutral:No provision of the license may be predicated on any individual technology or style of interface.
    The environment to be tested might not support all of the I/O that his suite might need in order to pass. IE maybe it has some combination of no writable filespace, no gui, no network connection, no terminal....

    I wish the definition was more clear that the license itself shouldn't restrict the kinds of modifications that can occur. If that is impied then criteria 3 is abused as well.
    The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. You are allowed to make modification as long as the md5sum of the resultant file is cc4e48a5fe0ba15b13a98b3fd34b340e ;->
    • You are allowed to make modification as long as the md5sum of the resultant file is cc4e48a5fe0ba15b13a98b3fd34b340e ;->

      As I understood it, the big fuzz is compliance in order to use the Java trademark. APIs aren't copyrightable, AFAIK. This is the same as with e.g. Linus' trademark on Linux. In theory, if you've applied a patch, you need his permission to call it "Linux". Maybe he'd only accept calling the file with md5sum "cc4e48a5fe0ba15b13a98b3fd34b340e" linux. So what? The question is the licence

  • free work, no loss of control... (Score:4, Interesting)

    by Numen ( 244707 ) on Sunday September 26, 2004 @09:52PM (#10359261)
    Is it possible to get a bunch of people to work for you for free, while still not loosing any control in the market place?

  • Isn't That What Trademarks Are For? (Score:5, Insightful)

    by femto ( 459605 ) on Sunday September 26, 2004 @09:55PM (#10359279) Homepage
    Surely the correct solution is to license all the copyrightable stuff under the GPL then reserve access to the "Java" trademark for implementations which comply with Sun's (open) standards?

    The idea of a trademark is to make is difficult to pass of an inferior clone as the original, which seems to be precisely what Sun is trying to prevent.

  • great (Score:5, Interesting)

    by jdkane ( 588293 ) on Sunday September 26, 2004 @10:05PM (#10359332)
    Can open source and closed standards work together?

    Yes, anything can work if you make it work, and Sun is a hard-working company. The other questions is: Do we want it to work?

    Why not. Sun has to maintain some kind of reign on the technology if they are to control it properly to compete against (for example) Microsoft and .Net.

    Kudos to them ... they're trying their best to serve the best of both worlds: their own, and the Open Source community. Maybe it doesn't look like it's giving as much control to some developers as they want, but it's better than nothing. And the two sets of interests do compete ... so -- again -- kudos to Sun for even trying this. At least they're trying something new and innovative instead of saying it cannot be done.

  • They need to split up J2SE (Score:5, Interesting)

    by ShatteredDream ( 636520 ) on Sunday September 26, 2004 @10:12PM (#10359383) Homepage
    At this point it is just insane that Sun isn't leveraging its investments into Java APIs to attack Microsoft by attempting to suck .NET developers into using Java APIs like Swing for their apps. There are already compilers that will let Sun rebuild Swing for the .NET platform and at this point Sun needs to consider co-opting the .NET platform to be a major goal.

    Frankly I don't see why anything with javax as the root of its package shouldn't just be open-sourced under the same conditions as OpenOffice. Javax denotes that it's a "java extension" which means it's not part of the core language and runtime. Sun should just push half the work there onto community processes and developers and maintain the core language and runtime.

    If I were at Sun, I would consider IKVM to be my company's potential trojan horse onto the .NET platform, not my enemy. I would hand over as many of the extension APIs to make Java run as good as possible on .NET. Of course Sun would rather let Microsoft take pot shots at its product lines a la OpenOffice than attempt to subvert their position.

  • Why Open Sourcing Java worries me. (Score:5, Insightful)

    by Yaztromo ( 655250 ) on Sunday September 26, 2004 @10:14PM (#10359401) Homepage Journal

    I like Java. I maintain an Open Source project [jsyncmanager.org] coded in Java. I particularily apperciate the fact that Java applications can be easily made completely portable across platforms.

    Here's what concerns me. Open Source has never really shown that it's terribly interested in ensuring API and binary compatibility across releases. Native binaries tend to be somewhat tightly compiled for their specific distro. To get around this, many packages are distributed as source so you can compile them specifically against your platform of choice.

    All well and good, but take a look at how the sources accomplish this: via pre-compiler directives to ensure things compile correctly on different platforms, or via complex makefiles to build specific sources on specific platforms.

    Currently, I don't typically have to worry about such things with Java. There are no pre-compiler directives, and there is no need to use them: one codebase compiles on every platform.

    Here's where my concern comes in. As soon as you Open Source Java, someone is going to want to put in pre-compiler directives because they're used to them from the C/C++ world. Around the same time, someone is going to create a Java fork which isn't 100% compitable in some area.

    Java developers, wanting to target as many platforms as possible, are going to start using the pre-compiler directives in order to work around implementation-specific bugs. Maintainers are going to start worrying less-and-less about API compatibility issues because developers are going to have pre-compiler directives to work around them (as we've already seen many times over the years in the C/C++ world). All of which is going to help reduce Java's platform neutrality, and make my job as a Java developer more complex than it is currently, reducing incentive to use it in the first place.

    My biggest interest as a Java developer would be to ensure that all Java runtimes conform to a single, standardized testsuite as Sun seems to want. And I don't care that the testsuite could be buggy -- so long as any API bugs that do exist are consistant across platforms. At the same time, there are some amazing things the Open Source world could do with all the other parts of the Java Runtime Environment -- for example, making the HotSpot Compiler Open Source could allow for some pretty massive JIT research to be consolidated in one place for the benefit of everyone.

    Much of this could be solved if Sun put the Java API and other technologies through an official standardization process, and then made their implementation Open Source. The former has worked well for other languages (Ada comes to mind), where a tight standardization process long helped to ensure source compatibility between platforms. The latter works extremely well for enhancing the adoption and development of a given technology. But to make it work, you couldn't just go with some form of defacto standard that most Open Source projects use/create/adopt. Unfortunately, I'm not quite sure what benefit Sun would see from doing something like this (not that I personally care anything about wether or not Sun were to get anything out of doing this -- I just realize they're going to need to see some sort of benefit before they ever decide to do such a thing).

    Yaz.

  • Article text (in case of slashdotting) (Score:2, Informative)

    by Anonymous Coward

    The Case for Open Source/Closed Standards

    Kevin Bedell

    There's been some debate recently on the license-discuss list hosted by the OSI on how to release code as open source while still requiring that it be compatible with a test suite that must be distributed as part of the code.

    The initial discussion was kicked off by Bob Scheifler of Sun Microsystems. Bob's original post was:

    For my personal edification, and hoping this is an acceptable inquiry, I'd like to understand if and specifically how the f

  • Dear Sun, ...! (Score:3, Interesting)

    by j.leidner ( 642936 ) <leidner@[ ].org ['acm' in gap]> on Sunday September 26, 2004 @10:25PM (#10359448) Homepage Journal
    The open source community (and other companies) could freely publish implementations of the code that passed the test suite, but Sun (or at least the JCP) would remain in control of Java as a standard.

    That's all fine for Sun to remain in control of Java. However, what developers should push is that Java be standardized by ISO. FORTRAN is not owned by IBM, PROLOG is not owned by the universities of Marseille/Edinburgh etc. The reason is that software companies need to protect their investment, which they can do much better if the standard is in the hands of an independent multinational organisation dedicated to standardization, and with a transparent membership policy: ISO. Otherwise, what if Sun suddenly decides to do strange things (change APIs, change the licenses) or simply ceases to exist...?

    Dear Sun: Please free Java!

    --
    Try Nuggets [mynuggets.net], the mobile search engine. We answer your questions via SMS, across the UK.

  • Release the code under GPL but if you want to use the JAVA trademarks (i.e. if you want to call your program "JAVA") you have to pass the testsuite.

    The same testsuite would also be usable by people writing other "JAVA" implementations (such as the GNU GCJ compiler and libraries).
    In fact, GCJ could just grab whatever code is usefull from the SUN VM directly and use it :)

  • Currently use Trademarks and GPL... (Score:5, Interesting)

    by eamacnaghten ( 695001 ) on Sunday September 26, 2004 @10:28PM (#10359469) Homepage Journal
    I believe you can achieve this in the current framework.

    Java is trademarked. It would be easy for Sun to say that nothing could be called "Java", or "Java compliant" unless it conforms to their standards.

    Also - Sun can release the code under dual license. The GPL - where the code can only be included in other projects that were also GPL, and the JSL (Java Standard license) or whatever, which is in control of Sun and is only issued to code that conforms to Sun's Java Standard.

    Although under the above it is possible to fork the standard, it could not be done in a commercial or proprietary product (unless it is released under the GPL - blocking MS and others from doing what they want), and it could not be called "Java". Therefore, the above I think would satisfy all requirements.

    • Close. Dual licencing is a twisty maze of tainted code, all alike.

      Why not a simple GPL licence, with the requirement that anything commited to the core project is licenced back to Sun. Sun has complete control over the core implementation, Sun has complete control over the Java trademark, the Java Community Process controls the standard. Who looses?

  • Closed standard? (Score:5, Interesting)

    by michael_cain ( 66650 ) on Sunday September 26, 2004 @10:42PM (#10359554) Journal
    I guess I take at least a bit of a contrary view on whether the standard is closed or not. Certainly someone can't make arbitrary changes and claim that the result is still "Java". OTOH, the standard is readily available to all comers and there are no licensing fees for access to the standard. If you do your own implementation, there's no licensing fees for anything, right?

    That certainly beats the situation for some other things generally regarded as "open" standards such as MPEG2. There you can't add arbitrary extensions and claim that it's still MPEG2. Any implementation will require licensing fees in order to be completely legal, as the standard includes patented technology (granted, they don't seem to be interested in pursuing people who build free software-only products -- but try selling an MPEG2 decoder chip and see how long it takes for them to serve you with notice). The Sun standard seems at least that open.

  • Remember Microsoft J++... (Score:3, Interesting)

    by Fantasio ( 800086 ) on Sunday September 26, 2004 @11:06PM (#10359691)
    ...the "embrace, extend and break" attack on Java. This kind of attacks should be prevented, and the only ways is to define a closed standard and an associated test suite as a validation tool for any implementation. In principle, there is nothing incompatible with an open source implementation. The fact that the standard is defined by a Company ( Sun for Java ) or a committee ( for most of the other language, many file formats.. ) is irrelevant.
  • Keither's license-discuss posting. [crynwr.com]

    Yep, Karma whoring all the way except that I was just reading his posting this afternoon.
    -russ

  • This is news? (Score:5, Interesting)

    by aristotle-dude ( 626586 ) on Sunday September 26, 2004 @11:09PM (#10359701)
    First of all. What exactly is a closed standard? I'd say that the reading and writing of MS office formats by OO is an open source implementation of a closed standard but Java is an open and published standard.

    Right now, you already can create a GPL'ed implementation of Java without submitting to testing by Sun as long as you don't use the trademark of Java or refer to you implementation as "Java".

    I find this lack of understanding of the English language disturbing. RMS has confused the lot of you concerning the meaning of "closed", "open" and "standard".

    Java is already an open, transparent and published specification. What Sun wishes to maintain is control over "their" trademark.

  • Open Standards are Huge (Score:3, Insightful)

    by alanbs ( 784491 ) on Sunday September 26, 2004 @11:14PM (#10359728)
    One of the main criticisms of GNU/Linux for example is that there are not consistant standards. I know that this has recently been fixed to a large degree with the specification created a few weeks ago by all the big distros and important people, but this is a great example of the more general situation. Linux people out of all people are for open implimentations, but there was still a need for large collaberation in interface. As a result, some freedom was taken away, but I think most would agree that this is a good thing. Sometimes what you need is a good benevolent dictator. Is Sun benevolent? I don't know. That has been a point of recent contraversy.

  • before flamming sun remember... (Score:4, Insightful)

    by the-build-chicken ( 644253 ) on Sunday September 26, 2004 @11:18PM (#10359756)
    ...that if it wasn't for their tight control and protection of Java, the only way your java/j2ee apps written on windows would work on linux/unix would be through wine.

    And vice versa through cygwin.

  • A License proposal (Score:4, Interesting)

    by miyako ( 632510 ) <miyako AT gmail DOT com> on Sunday September 26, 2004 @11:52PM (#10359922) Homepage Journal
    Here is an idea for a license sun could use.... (please forgive the lack of requisite legalese, I'm sure sun's lawyers could obfuscate it quite well)
    Java is owned by sun, and sun is going to allow you to have access to the Java standard, so you can make your own implementation. If you do make your own implementation though, then you have to make sure that it's compatible with our version of Java, that is to say, you can add features, but you have to make sure that any program written to run with our version of Java also runs on your version. For a price, you can pay us to ensure compatibility, and only after this can you use the term Java in your application, or claim "Java Compatible". Oh, and none of this applies to Microsoft, screw you guys.

  • that doesn't make sense (Score:4, Insightful)

    by jeif1k ( 809151 ) on Monday September 27, 2004 @12:52AM (#10360113)
    The primary purpose of open source licenses is to give users control over the software platform that they use--to allow them to adapt it to their own needs, instead of the business needs of some mega-software-corporation. This includes removing or replacing poorly conceived portions of a platform and adding incompatible extensions. An "open source" implementation for a closed standard under the control of Sun doesn't allow this, hence it doesn't achieve the goals of open source.

    Furthermore, requiring formal test suite compatibility means that such a project simply cannot meet the definitions of an open source project.

  • I don't get it. (Score:3, Insightful)

    by mcrbids ( 148650 ) on Monday September 27, 2004 @01:12AM (#10360171) Journal
    What is the big deal?

    How many implementations are there of Java? Perl? PHP? Python? Ruby?

    Yep. Just one, each. That hasn't stopped each from growing to enterprise-grade capacity. (Yahoo has bet the farm on PHP, etc)

    If Sun Opens up Java, but requires that forks retain a baseline compatability, what is wrong with that?

    There are numerous implementation of Structured Query Language (SQL) and the fact that they are all "mostly" compatable is a developer's nightmare. You either don't bother with all the fancy foreign keys/rules/triggers stuff, or you choose AN implementation of SQL (Say, PostgreSQL, or Oracle, etc) and develop for it alone (or you have lots off time/money to burn). You can only develop cross platform appliccations in a fairly simple way, because of all the potential gotchas between SQL implementations. Anytime you need true ACID compliance, and true data integrity guaranteed at the database level, you're stuck.

    How different this would be if ANSI SQL came not just with a specification (does this, that, etc) but also came with an extensive set of statements and results that could be compared so that there was a strong, capable baseline that would be cross platform.

    Then, establish a non-profit agency that could enforce the standard, providing three degrees of certification: ANSI SQL based, ANSI SQL compliant and ANSI SQL certified.

    "Based" would refer to an incomplete implementation of the spec. The only difference between "compliant" and "certified" being that "compliant" could execute the statements to get the desired result, and "certified" has been independently tested by the enforcement agency to ensure that the test runs right. (and a fee has been paid)

    This would be a total BOON to developers who could write ANSI-compliant statements and be confident that their stuff would work everywhere.

    There are DOZENS of gotchas in SQL. For example, if you define a UNIQUE constraint across two fields where one of the fields could be null, does the UNIQUE constraint apply to rows where one of the fields is null? According to the spec, no. But numerous database engines will enforce the uniqueness despite NULL being one of the values.

    OOPS! NULL is not a value, it's a non value. It's an "I don't know". How can that be considered in an evaluation of unique?

    Usually not important if you're running a BLOG. Can be critically important if you're keeping track of financial transactions!

    I would *LOVE* it if ANSI treated SQL like Sun proposes dealing with JAVA....

    • Re:I don't get it. (Score:3, Interesting)

      by Decaff ( 42676 )
      How many implementations are there of Java? Sun's, IBM's (at least 2, including VisualAge), HP's (a clean-room implementation), GNU, Kaffe, TowerJ, Waba, and many, many more.
      Perl? 1
      PHP? 1
      Python? At least 3 - Python, Jython, and Python for .Net.
      Ruby? 2 - Ruby and JRuby.

      The difference is that with Java, there are compatibility tests.

  • Open Source means No Control (Score:4, Insightful)

    by Jay Carlson ( 28733 ) on Monday September 27, 2004 @02:20AM (#10360405) Homepage
    Open Source means No Control.

    That's the core of the various free software guidelines.

    You never need to ask permission before taking some 3D library and stuffing it into an SNMP monitoring tool, and then posting it on freshmeat---where some person on the other side of the world finds it and hacks up a web interface.

    You never have to be captive to a copyright owner. If you think RMS is making poor technical decisions [sourceforge.net] in FSFmacs, or XFree86 does silly things with licenses, or some guy neglects [sf.net] his [sourceforge.net] hobby projects [sf.net] (ahem), you can go off on your own without begging anybody. All you have to lose is the previous name and its reputation.

    On the other hand, there are about a zillion Linux distros out there that nobody's heard of. The ultimate penalty for doing a bad fork is being ignored.

  • Standardisation is the way (Score:5, Interesting)

    by ajs318 ( 655362 ) <sd_resp2NO@SPAMearthshod.co.uk> on Monday September 27, 2004 @03:15AM (#10360580)
    All SUN need to do is approach ISO and create a new international standard for a multi-platform programming language with certain features. Then, trademark the name "Java" and stipulate that it can only be applied to a programming language conforming to international standard MIL-TBD-1111 {or whatever it ends up being called}. Finally, release the Java source under something like the GPL, which would explicitly block the likes of Microsoft from releasing closed-source derivatives {as long as this is aggressively enforced}.

    So what would the consequences be? Regular users will be able to download a package for their own distro that Will Just Work, and get on with enjoying the Java experience. Your average "meddling hobbyist" won't care too much about the name, just about the kewlness of their latest mod. Packagers will be able to pass the compatibility tests with confidence {all they'll be doing is picking sensible defaults by the standards of their distribution}. And anybody who wants to create a closed-source Java replacement with the intention gradually to reduce compatibility with the original Java release-by-release, in order to steal SUN's market share, will be f??ked.

    Sounds like a win all round really!

  • It works for Common Lisp (Score:2, Interesting)

    by IWK ( 20254 )
    It seems to work for Common Lisp. Although this is a "real" standard (ANSI) and not one controlled by a single commercial entity, it does resemble the proposed solution in that multiple commercial and open source implementations closely follow the defined standard. No fragmented market there.

    The case of Common Lisp is rather illuminating in that it was not actively maintained (it lacks facilities like sockets etc) so the implementors did differantiate but only there where there was no standardisation.

    And
  • Quoting the FA:-

    There's been some debate recently on the license-discuss list hosted by the OSI on how to release code as open source while still requiring that it be compatible with a test suite that must be distributed as part of the code.

    Yes It's been done for years.

    The LaTeX Project Public License (lppl) [tex.ac.uk]

    In essence it says:-

    This software is copyright but you are granted a license which gives you, the "user" of the software, legal permission to copy, distribute, and/or modify the software. However

  • Maybe it's just me, but all those never-endings turns around java and the gpl is really getting boring no?

    If Sun want to do-it they will do-it, the rest is only noise and advertisement.

  • TeX (Score:4, Interesting)

    by Dunedain ( 16942 ) on Monday September 27, 2004 @05:38AM (#10360904) Homepage
    TeX works about that way -- your code must pass a test suite to be called "TeX", but otherwise it's in the public domain.
  • .. that Sun has a VERY STRICT testing procedure in declaring a VM "Java Compatible". Just because it can run Java code (see Microsoft's Java VM), the implementation being different can cause all sorts of problems. As a matter of fact, this is the major reason for compatibility problems with WINE... little implementation quirks in the win32s could be dependant behavior.

    Sometimes I wonder if all of these "Make Java Free!" actually even see the picture that they swear that they are looking at.

Slashdot Top Deals

If mathematically you end up with the wrong answer, try multiplying by the page number.

Close