Folks, We need to understand the reasoning behind the OMG's publication of the files as copyrighted and unmodifiable. As I understand it (*), the current mode of publication is, in part, a reaction to things that have happened previously.
Historically, certain ORB vendors were in the habit of implementing CORBA language bindings in non-standard ways. The result was that it was easy for people implementing CORBA to tie themselves into specific vendor ORBs. Specifically, an application or service typically had to be compiled and linked against a specific vendor ORB. When the OMG issued the IDL->Java mapping RFP, it was a primary requirement that Java language bindings should be portable. Specifically, you should be able to compile an application against the Java bindings created by one ORB's IDL compiler, and run the same application bytecode against a Java bindings from a different IDL compiler. It took a couple of iterations, but they did get there eventually. (And with CORBA 2.3 it started to be feasible to implement the server-side portably as well.) 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. > 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. 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. 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. > 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. 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. 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. 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. -- Steve (* A few years ago, I worked on some OMG specifications, and in the process learned a fair bit about how the OMG works. I've also discussed this with someone at DSTC who is more knowledgeable.) _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
