Folks, If >>all<< we have to do to keep GNU / FSF happy for now is to remove the link to the OMG from the website, lets just do it. I hardly think this is a major issue.
In the long term though, there is a bigger problem looming. At some point, Classpath needs to support the org.omg.* classes. Without them, you cannot run CORBA ORBs and CORBA-based applications over Classpath. This includes free Java ORBs and free J2EE platforms. Before proceeding, we need some background on the OMG and their way of thinking. [My employer (DSTC) is a current member of the OMG. In the past, I've done a lot of work for DSTC on OMG standard submissions and revisions. (MOF & XMI if anyone is interested.) As a consequence, I've learned a fair bit about the processes and politics of the OMG. I've also done a lot of CORBA-based product development in Java.] The critical org.omg.* classes are the Java interfaces for the OMG's CORBA-to-Java and Java-to-CORBA mappings. These interfaces are an integral part of the respective standards. They NOT implementations of the standard. There are other org.omg.* classes as well, but they are not published by the OMG. Instead, the OMG publishes the IDL from which they can be generated using an IDL->Java compiler. The reason the critical Java interfaces are part of the standard mappings is to enable binary compatibility between different CORBA for Java platforms. This allows someone to write CORBA based applications for one Java ORB platform and have them run on other platforms without recompilation. To achieve this aim, it is necessary for the interfaces be the same on all ORB platforms. The main reason for the OMG's copyright notice forbidding changes is to prevent ORB vendors from slipping in extensions and the like that would destroy cross-vendor binary compatibility. This kind of thing has happened in the past, and it causes major problems for people who write multi-platform software. (Like when the 'org.omg.*' interfaces in a Sun JDK didn't comply with the OMG standard, and the "Visibroker for Java" ORB had its own clean copy of the 'org.omg.*' classes that you had to put on the bootclasspath ...) IMO, it is a GOOD THING that the OMG defends the integrity of these interfaces as best they can. It so happens that they have decided that a restrictive copyright notice is their most effective tool for doing this. They are probably right. [You may disagree, but then you need to understand the nature of the organisation and its relationship with the ORB vendors.] While OMG staffers are generally supportive of Open Source (AFAIK), they are >>not<< going to be persuaded to do things that openly undermine the integrity of the CORBA standards. It would be against the interest of the OMG's 700+ member organisations, and the OMG Board would stomp on them with big boots. So where does this leave the Classpath project in the long term? * In the long run, we cannot leave out the org.omg.* interfaces. They are an important part of the J2SE & J2EE platform APIs. * We should not try provide a clean-room version of the OMG's org.omg.* interfaces. AFAIK, there is insufficient public information (apart from the OMG's copyrighted interfaces) to allow this. Besides we'd risk being incompatible with other Java implementations and/or Java ORBs and Java/CORBA applications. In other words we'd be potentially subverting the CORBA standard. This would be a BAD THING. * We could try to persuade the FSF to allow a specific exception for non-FREE code provided by standards organisations like the OMG. I cannot see that FSF intends to undermine open standards by removing their ability to protect integrity via copyrights. If this and other possible alternatives fail, we may eventually need to take steps to disassociate Classpath from GNU. That would be a shame. -- Steve _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
