[omniORB] omniORB licensing: Too strict for real life?
Helge Penne
Helge.Penne@datarespons.no
Tue, 25 May 1999 14:56:50 +0200
--------------03F8C3CBA4871A6A766CDE0A
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
David Riddoch wrote:
> Helge,
>
> It must be possible for your customers to link a modified version of
> omniORB with your object code. This requirement can be met either by
> using shared libraries, or alternatively providing object code so that
> they can relink a static library.
>
> OmniNames is distributed under the GPL. This means that any derivative
> work must be GPLed. If any of the code is incorporated into another
> program, then that program must be GPLed.
>
> I hope that is clear!
> David
Clear but very very sad!
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 make
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 the
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...
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 law
by distributing object files from other third pary systems or libraries?
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 kind of
scenario. It would be very sad to have to abandon omniORB entirely and
switch to something less preferable, simply because of a legal technicality
like this. How do we work our way around this problem?
Btw: The I received the following reply directly to me from a kind reader.
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 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øvik, Norway
Phone: +47 67112081 / 22719957 (work/home)
--------------03F8C3CBA4871A6A766CDE0A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
David Riddoch wrote:
<blockquote TYPE=CITE>Helge,
<p>It must be possible for your customers to link a modified version of
<br>omniORB with your object code. This requirement can be met either
by
<br>using shared libraries, or alternatively providing object code so that
<br>they can relink a static library.
<p>OmniNames is distributed under the GPL. This means that any derivative
<br>work must be GPLed. If any of the code is incorporated into another
<br>program, then that program must be GPLed.
<p>I hope that is clear!
<br>David</blockquote>
Clear but very very sad!
<p>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
make 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
the 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...
<p>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 law by distributing object files from other third pary systems or libraries?
If my understanding is correct, this is simply not possible...
<p>It seems to me that the GPL is not very well suited to handle this kind
of scenario. It would be very sad to have to abandon omniORB entirely
and switch to something less preferable, simply because of a legal technicality
like this. How do we work our way around this problem?
<p>Btw: The I received the following reply directly to me from a kind reader.
As he did not clearly permit me to post it, I have left out his name:
<blockquote TYPE=CITE>
<pre>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.</pre>
</blockquote>
<p>--
<br>Helge Penne (helge.penne@datarespons.no)
<br>Senior Software Development Engineer
<br>Data Respons AS, Postboks 489, N-1323 Høvik, Norway
<br>Phone: +47 67112081 / 22719957 (work/home)
<br> </html>
--------------03F8C3CBA4871A6A766CDE0A--