Classpath and org.omg.*

[Stephen Crawley]

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