[omniORB] licensing

[Richard Hardgrave]

Jason,
	This should help you out.  I had a similar question and Duncan
responded as follows.  I remember needing to include a header or two
in some classes that weren't directly generated by but were called by
the servant skeletons.  I think it's safe to say you just can't write
any servant code without some headers being included.  And, it's the
IDL compiler that's generating the include statements.

Regards,

Richard

> On Friday 7 September, Richard Hardgrave wrote:
> 
> >       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.
> 
> I am not a lawyer, but I can speak for our intentions with omniORB. We
> intend to permit omniORB to be used in closed-source commercial
> applications, so any language in the license which could be construed
> to mean otherwise can be ignored. We won't go after you for it.
> 
> The only thing we intend to prevent is someone taking a large piece of
> the omniORB source and using it in their own closed-source program, or
> taking omniORB and claiming it to be their own. Simply using omniORB
> as a CORBA ORB, with all the IDL compilation and so on that that
> requires, is not a problem at all.
> 
> > 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?
>  
> That statement covers all the IDL compiler output.
> 
> The things in the LGPL about header files are interesting, and perhaps
> we should think about adding a clarifying statement to the omniORB
> distribution. We certainly don't intend to force people to LGPL their
> code just because they've #included our header files.
> 
> Cheers,
> 
> Duncan.
> 

> From owner-omniorb-list@uk.research.att.com Sun Apr 21 16:41 CDT 2002
> 
> Hello all,
> 
> I know there have been many discussions about this, but please bear with me.
> I would like to know if it is possible to obtain a commercial license for
> OmniORB that satifies the requirements of the developers. From previous
> license discussions on this mailing list, I understand that the developer's
> requirements are basically:
> 
> If I am going to compile and link (dynamically) a proprietary software
> package with OmniORB and distribute it, I must:
> - Tell my customers that I am using OmniORB (no problem!)
> - Distribute the source code for OmniORB along with the application or tell
> the customer where they can obtain it (no problem!).
> - Allow the customer to modify the OmniORB libraries and run my application
> with them. (no problem! At their own risk, of course!).
> - Not claim that OmniORB is my work (no problem!).
> - If I display a copyright notice onscreen, I must show that the software is
> using OmniORB (no problem!).
> 
> I would like to use OmniORB as a shared library, but the LGPL is very
> restrictive when it comes to headers (see section five of the LGPL for
> reference), even when dynamically linking. Since a lot of OmniORB headers
> have templates and extensive inline code, according to the LGPL, if my
> software includes the OmniORB headers, the files including that code
> automatically become a work based on the library and as such I must provide
> the source code for those files. Based on earlier postings, it is my
> understanding that the authors of OmniORB do not want to impose these
> restrictions on users of the OmniORB libraries, but still, the default
> license that we are required to distribute with the package imposes these
> requirements. It is not written anywhere in any documentation in the OmniORB
> package that the intentions are anything different, so while the authors of
> OmniORB may not go after anyone for letting section 5 of the LGPL 'slip
> through the cracks', a customer may go after someone as the license clearly
> states they have the right to do so.
> 
> Has anyone else had this concern, if so, how did you resolve it?
> 
> Anyway, who should I get in contact with to find out how to obtain a
> commercial license that guarantees the developers demands and will allow me
> to use compile and link with OmniORB without losing any sleep? I've heard
> some mentioning of obtaining a commercial license for the statically linked
> version of OmniORB, that is why I brought it up for the dynamically linked
> version.
> 
> Thanks a bunch,
> Jason.
> 
> 
>