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

Thu, 27 May 1999 11:45:04 +0200

--0__=qP6pbVKmuiyev42YnvNv7fFUE9goePsXM2latZFbITw3V93EJwPUai4T
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

David,

I am working with Helge Penne on an embedded project where we are planning to
use omniORB.
This thread has been going on further after your reply of May 25th, but I am
replying to this message as it is somewhat conclusive on this matter.

I think I understand the motivation behind the GPL/LGPL licencing terms, and I
think they work reasonably well in a conventional software application on
non-embedded platforms. In these cases the software is your product, and the
hardware platform and the OS is maintained by the customer. Most OSes for such
platforms support shared libraries and multiple processes on a single CPU, and
thus poses no problems with regard to the licencing terms.

Embedded systems are a different story. The hardware itself is the product, and
the hardware, (RT)OS and software is tightly integerated. Every software release
has to be tested thoroughly on the hardware platform before installation. This
also applies to updates in any third-party libraries and the (RT)OS itself.

Most embedded systems have software linked to the OS and the software package is
often stored in EPROM or Flash-PROM. In most cases it is impossible for the
customer to modify the software in any way, and it is almost always very
undesirable that he does so.

Any customer tampering with software or hardware usually voids the warranties,
and as we are talking about equipment worth $100.000+ most customers are very
careful about this.

In our case we are talking about an Untehered Underwater Vehicle with several
computer systems onboard. A sw failure is fatal in such systems, and we as a
manufacturer would not be very happy if a customer changed the sw without our
permission. We would be happy to incorporate any changes he wants, but we would
also want to test this ourselves before installing it.

My point in writing this is:
The GPL/LGPL licencing terms was not written with embedded systems in mind, and
much of the motivation behind these terms does not apply to most embedded
systems. Consequently, most GPL/LGPL licenced sw may not be used in embedded
systems.

I would like to suggest a change in the licencing terms for embedded systems. I
do not know if this is possible, but it would certainly  help for companies
making embedded sw. We would then be able to use products like omniORB without
to much hassle. The required changes are:
   Relaxation in the requirement that the customer should be able to rebuild the
   sw with modified libraries.
   If required, the manufacturer could then instead be obliged to generate a new
   build based on a modified library provided by a customer.  A fee covering the
   work involved would normally be required.

If 2) is required, the manufacturer should be able to void any warranties on the
product, limit his support responsibilities and take no responsibility for
correct operation of the product after the upgrade unless the customer is also
willing to pay for a complete system test.

Of course, any source code changes should still be published, and the full
source for the libraries should be made available.

In our case, it should then also be possible to modify the omniORB naming
service and rebuild it as a library. Then publish this code and link the library
with our code (statically).
-
Jon Kristensen (jon.kristensen@kongsberg-simrad.com)
R&D engineer
Kongsberg Simrad AS, P.B.111, N-3191 Horten, Norway
Phone: +47 33 03 43 62

David Riddoch <djr@uk.research.att.com> on 25.05.99 15:21:19
To:   Helge Penne <Helge.Penne@datarespons.no>
cc:   omniorb-list@uk.research.att.com (bcc: Jon Kristensen/NOHRT/KS/KM/KOG)
Subject:  Re: [omniORB] omniORB licensing: Too strict for real life?

--0__=qP6pbVKmuiyev42YnvNv7fFUE9goePsXM2latZFbITw3V93EJwPUai4T
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

Helge,

I am sorry, but the licence has to stick.  I expect that you have inves=
ted
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 t=
o
suggest an alternative solution:

There is no reason why you can't do your own implementation of the nami=
ng
service.  It is quite a simple specification, so probably less work tha=
n
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!
>
> Would this mean that if I create an executable that incorporates Nami=
ng
> Service code (to integrate the Naming Service with the program), then=
 the
> source code for the entire program would have to be GPLed?  This woul=
d make
> use of the Naming Service impossible for commercial distributed embed=
ded
> systems.  In this case the Naming Service *must* be integrated with a=
n
> 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 t=
he the
> Naming Service.  It is aloso not acceptable to GPL the entire applica=
tion
> 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 al=
so
> lack decent support for dynamic link libraries, so static linking
> (executable image) or object files are the only options beside source=

> code...
>
> Where does this leave us?  How can we use omniORB to develop this kin=
d of
> systems in a legal way without GPLing the application, or breaking th=
e law
> by distributing object files from other third pary systems or librari=
es?
> If my understanding is correct, this is simply not possible...
>
> It seems to me that the GPL is not very well suited to handle this ki=
nd of
> scenario.  It would be very sad to have to abandon omniORB entirely a=
nd
> switch to something less preferable, simply because of a legal techni=
cality
> like this.  How do we work our way around this problem?
>
> Btw: The I received the following reply directly to me from a kind re=
ader.
> As he did not clearly permit me to post it, I have left out his name:=

>
> > 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 y=
ou
do not need to ship the library itself - if you leave
> > the OmniORB libraries linked in as 'dynamic' then those libraries c=
an
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 i=
t
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)
>
>

=

--0__=qP6pbVKmuiyev42YnvNv7fFUE9goePsXM2latZFbITw3V93EJwPUai4T--