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

[Helge Penne]

Thank's Jon for a thorough summary of the problem.  I'd like to add that the Naming
Service is not the biggest problem.  We can reverse engineer this if we are forced
to do so.  The major problem is the licensing terms for omniORB itself...

- Helge

jon.kristensen@kongsberg-simrad.com wrote:

> 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
>