On Sat, 2003-12-13 at 02:08, Robert Collins wrote: > On Fri, 2003-12-12 at 09:28, Benno wrote: > > >2) To a user of the system, the OOP COM object is hidden - it's not > > >directly visible or usable as a standalone entity. > > > > Yes true. > > > > I think you are saying that this goes to making it a derived work, > > or covered by the GPL? If so does that mean I can't use any GPLed > > CORBA components on a Linux system without also releasing under GPL? > > I don't know enough CORBA to answer that.
It goes like this.
IDL (Interface Definition Language) defines CORBA interfaces. IDL is
compiled to generate code in a specific language. That code is in turn
compled using a native compiler to create the local CORBA artifacts used
interact with the CORBA objects. Note that an IDL compiler produces
*source* code in another language, e.g. C, C++, Smalltalk.
So, as a client wanting to use a GPLed CORBA server, I'd grab the IDL
and compile it (in my case to Smalltalk classes). I would then write
code to interact with the new classes generated by the IDL compiler.
The generated classes would translate messages I send into IIOP packets
sent to the appropriate places (e.g. processes offering CORBA services).
I don't need to even see the code of the GPLed CORBA server to interact
with it. I do need to *read* the IDL (well, the IDL compiler reads it)
in order to generate native (e.g. Smalltalk) code.
It seems to me then that the only issue might be how the IDL is
licensed. So perhaps the way to use CORBA is to GPL your servers, and
put the IDL under BSD? But perhaps even having the IDL under the GPL
would be OK in this case as the IDL itself is only ever read, and never
directly included in new software?
HTH
All the best,
Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.com
signature.asc
Description: This is a digitally signed message part
-- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
