classpath
[Top][All Lists]
Advanced

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

Re: CORBA


From: Stephen Crawley
Subject: Re: CORBA
Date: Thu, 03 Mar 2005 12:47:00 +1000

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.)





reply via email to

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