[omniORB] licensing

Richard Hardgrave hardgrav@ttd.teradyne.com
Fri, 7 Sep 2001 18:59:49 -0500 (CDT)


Hello,
	I will be incorporating omniORB, as a shared library, into our
Test System Controller application, which is proprietary.  I have changed
nothing in the library and will be distributing it as stipulated in the
LGPL.  Perhaps I'm just thinking too hard about this, but I noticed a
clause in the LGPL that refers to header files.

This is the clause I'm curious about:

When a "work that uses the Library" uses material from a header file that is
part of the Library, the object code for the work may be a derivative work
of the Library even though the source code is not. Whether this is true is
especially significant if the work can be linked without the Library, or if
the work is itself a library. The threshold for this to be true is not
precisely defined by law.

In addition, omniORB makes the following statement on its website:

We impose no restriction on the use of the IDL compiler output. The stub code
produced by the IDL compiler is not considered a derived work of it.

Would someone please fill in some of the "implications", here, for me?

Should I assume that the omniORB statement means ALL IDL compiler output?
omniidl puts both the client "stub" code and the servant "skeleton" code
in the same output file.  This statement covers ALL of this output, right?

Now, back to the LGPL - The <idl_output>.hh file generated by the IDL compiler
does "#include <omniORB3/CORBA.h>", which is certain to be in any servant.
Does this mean that the servant object code _may_ be a derivative work
of the library?  If the license uses the term, "may", what determines
whether it is derived or not?  Or, should I even be concerned?  Or, should
I inform management that we may have to publish the servant source code
but not the client?
Should I also make sure that none of the client code does,
"#include <idl_ouput>.hh"?
Or, does "not precisely defined by law" mean we can include the header
files for now, but it might change in the future?

Regards,

Richard