[omniORB] omniORB licensing: Too strict for real life?

[David Riddoch]

Helge,

I am sorry, but the licence has to stick.  I expect that you have invested
a significant amount of time developing your application using omniORB, so
it really would be a shame if you had to stop using it.  I would like to
suggest an alternative solution:

There is no reason why you can't do your own implementation of the naming
service.  It is quite a simple specification, so probably less work than
migrating to an alternative orb.  If your platform/application doesn't
require a persistent naming service, then it becomes really easy --
reading and writing the log file is most of the work in omniNames!

I hope this 'solution' is good enough.
Regards,
David




On Tue, 25 May 1999, Helge Penne wrote:

> Clear but very very sad!
>=20
> Would this mean that if I create an executable that incorporates Naming
> Service code (to integrate the Naming Service with the program), then the
> source code for the entire program would have to be GPLed?  This would ma=
ke
> use of the Naming Service impossible for commercial distributed embedded
> systems.  In this case the Naming Service *must* be integrated with an
> application, as most real time OSes do not support more than a single
> process per CPU, and it is not acceptable to dedicate an entire CPU the t=
he
> Naming Service.  It is aloso not acceptable to GPL the entire application
> due to the use of the Naming Service, or to provide the customer with
> complete source code.  Object files will also be a problem in a case like
> this, as these would have to include code from the embedded operation
> system.  This will be illegal in most cases.  Many ebedded systems also
> lack decent support for dynamic link libraries, so static linking
> (executable image) or object files are the only options beside source
> code...
>=20
> Where does this leave us?  How can we use omniORB to develop this kind of
> systems in a legal way without GPLing the application, or breaking the la=
w
> by distributing object files from other third pary systems or libraries?
> If my understanding is correct, this is simply not possible...
>=20
> It seems to me that the GPL is not very well suited to handle this kind o=
f
> scenario.  It would be very sad to have to abandon omniORB entirely and
> switch to something less preferable, simply because of a legal technicali=
ty
> like this.  How do we work our way around this problem?
>=20
> Btw: The I received the following reply directly to me from a kind reader=
=2E
> As he did not clearly permit me to post it, I have left out his name:
>=20
> > That was a clear explanation of the library license - surprises me
how few people understand it at all (and are probably
> > violating it) - I have dealt with a similar situation where the
libraries from a commercial vendor could not be shipped -
> > however I assume you are allowed to ship executable files that are
dependent on other shared libraries - if the
> > commercial software is linked 'static' into your application then you
do not need to ship the library itself - if you leave
> > the OmniORB libraries linked in as 'dynamic' then those libraries can
still be altered by the customer (to other version
> > of Omni) (there may be Omni version problems but you met the spirit
and letter of the license) - you can still alter
> > OmniORB (as long as you ship the altered source) - just make sure it
links dynamically (may not even be possible on
> > your OS)
> >
> > be interesting to see what the Omni folks have to say.
> >
> --
> Helge Penne (helge.penne@datarespons.no)
> Senior Software Development Engineer
> Data Respons AS, Postboks 489, N-1323 H=F8vik, Norway
> Phone: +47 67112081 / 22719957 (work/home)
>=20
>=20