classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CORBA


From: Dalibor Topic
Subject: Re: CORBA
Date: Thu, 03 Mar 2005 05:18:41 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5

Stephen Crawley wrote:

So ... the reason that the OMG publishes files the way that they do is
to maximize portability. They want to avoid ORB vendors (or anyone else) publishing nonstandard versions which result in issues with Java bytecode portability across different platforms. Absent a comprehensive compliance
testing / badging regime, this is about the only option they have.

That's all fine and well-meaning, but that's no reason to restrict modifications. Sun likes to sing the same tune. :)

Bascially we have two choices, which we can of course tackle in
parallel.
1) We use the specification and write a free implementation of it. Jeff
Bailey started work on this, I don't know the status of that. This
doesn't seem that much work actually since it would only be for the
org.omg interface classes which aren't that large actually. There are
just a lot of them. Most aren't difficult at all though. If we can
bridge these with an existing corba implementation like [sic]


a) It is not clear (to me) that this can be done without damaging the
cleanroom status of ClassPath vis-a-vis the OMG's intellectual property.

Does the OMG really claim the specs as some form of intellectual property? I have seen nothing of the kind of Sun's claims in OMG's specs, for example ftp://ftp.omg.org/pub/javartf/IDLtoJava-2000-11.pdf doesn't seem to explicitely say it's a poisonous apple. It does contain a funny paragraph on 'allowed modifications' though, which may or may not apply to someone claiming conformance, but so far noone seems to want to claim anything, afaict ...

b) It is not clear (to me) that this does not violate the OMG's
copyright.  Certainly, it is doing something that they were
(historically) trying to prevent.

Copyright claims on interfaces would be dubious, but it doesn't seem as if they are making them. I've found no mention of either the words copyright nor license in that pdf file above.

c) I'm not sure that a Classpath-based VM can claim CORBA compliance if
it uses a version of the org.omg classes that come from a different
source. It might mean that (for example) all Linux distros that include
a Classpath-based Java implementation needs to get the CORBA compliance
testing done themselves if they want a "CORBA-x.y" compliant badge.

That's not a problem for Classpath, though. If people want some extra marketing pixie dust, they can do what that takes on their own. That's no different then when a Linux distro wants to bear Sun's marks, it's up to them to do the TCK dance with Sun. Classpath doesn't do badges yet :)

2) We ask the OMG to release their org.omg interface classes as
GPL-compatible free software and include them as external libraries with
GNU Classpath. Chris Burdess wanted to take a stab at that.


You would need to provide a very convincing argument to the OMG.  It is
likely that an OMG decision to change copyright notices would entail
consultation with the relevant TF, the PTC and the Architecture Board.
Ultimately, it would require OMG Board approval.  At each level, you are
likely to find companies representatives who are cautious about (or
worse, antipathetic to) the Open Source movement in general and the GPL
in particular.

You will need a stronger case than the current one, which really boils
down to: "We need you to change so that we can be true to our ideology".
(Or at least, that is how some OMG members will construe this.)

I'm not saying that asking the OMG to change the copyright notices
will definitely fail.  But it is likely to be a long and painful process,
and will require a committed "champion" who can spend time and money
attending OMG meetings, etc, etc.

Given that multiple open source and free software Java ORB implementations exist, and the OMG seems to be able to deal just fine with open source projects ignoring them according to http://www.omg.org/docs/omg/04-10-02.txt , and in contrary seems quite happy about open source and free software implementations of their specs, I don't see why they'd be opposed to disambiguating their license.

Actually, there are a couple more options that you have not mentioned:

3)  Convince ourselves, and then the relevant people in the GNU
hierarchy that it would be a GOOD THING for the Classpath distros
to include the OMG files as-is.  This is my position on this issue.
Ideology aside, I don't see that it is anyone's interest to allow people
to hack around the "omg.org" classes and redistribute the hacked
versions. It will cause nothing but problems.

I think it's pretty useful for people who can not ship the org.omg classes from the OMG as they are.

One alternative would be to add another exception clause to the GPL
variant that we use for Classpath.  Specifically, it could say that
the "org.omg" classes are not considered part of Classpath for the
purposes of clause 2) of the GPL.

Why kowtow to a percieved threat from OMG without working with on them fixing their licensing ambiguity? I've had a similar discussion with Mark offlist, and he convinced me that planning for bowing one's back before IP claims which may or may not be claimed and may or may not be bogus would be the wrong thing to do. In particular as the change in OMG's license wording would be rather small in this case, afaik.

A second alternative would be to flag this problem to the people who are
devising GPL version 3, then hope and pray that they work out how to
address this. 4) Continue to distribute the OMG files as a part of a GPL incompatible add-in module.

Not an option if you're a GPLd work, though. I don't think that practice has ever been started, though, so nothing to continue there :)

More poetically spoken, as GNU Classpath is in the trap-smashing business, it would be a bit self-refuting to exchange the shackles of the Java trap for the shackles of the CORBA trap, if there is such a trap. :)

cheers,
dalibor topic




reply via email to

[Prev in Thread] Current Thread [Next in Thread]