Slashdot Mirror

← Back to Stories (view on slashdot.org)

Open Source And Closed Standards?

Posted by timothy on 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."

6 of 219 comments (clear)

  1. Maybe a bit off topic by jmcmunn · · Score: 5, Interesting


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

  2. But yes by Sinner · · Score: 5, Interesting

    Actually, they work together all the time. A major example is Samba, which implements Microsoft's mostly-closed SMB protocol. Or the open-source implementations of Microsoft's video codecs.

    But what Sun is after is different. They want an open source license that only permits those modifications which preserve compatibility with Sun's specifications.

    Sun is suffering from a classic misinterpretation of what on open source license is. They're thinking if they can just get the right secret handshake, they can gain entry to the club.

    The real secret is, there is no secret handshake. While it certainly helps if a license is phrased in such a way that it appears to match the Open Source Definition, the only real test of a license is whether it lets people do what they need/want to do.

    Sun's problem is that they know that people want to produce non-conformant implementations. They feel they have to stop them doing that. This goal is, by its very nature, incompatible with an open source license. No amount of clever wording is going to change that.

    --
    fish and pipes
  3. Re:Why even bother open sourcing Java then? by anonymous+cowherd+(m · · Score: 5, Interesting
    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?

    --
    http://neokosmos.blogsome.com
  4. Re:Open source + Closed standard = Closed by iabervon · · Score: 5, Interesting

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

  5. there is a precedent for this by JoeBuck · · Score: 5, Interesting

    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.

  6. Re:Its called a trademark silly by OverflowingBitBucket · · Score: 5, Interesting

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