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
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
