[omniORB] omniORB licensing: Too strict for real life?
Helge Penne
Helge.Penne@datarespons.no
Tue, 25 May 1999 09:32:37 +0200
--------------8A48281F376E3C5B0BA852B7
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
I'm wondering if somebody could clarify some issues regarding omniORB
licensing.
I found the following in the arcives (subject "omniORB questions", dated
Tue, 15 Jul 1997 14:54:53 +0100, replyer is Sai-Lai Lo):
> >>>>> Lars Jarnbo Pedersen writes:
>
> > I'm using omniORB to gain some insights on basic CORBA ORB
> > infrastructure. After studying your very well structured and modular ORB
> > architecture I'm considering using omniORB for some prototyping
> > projects. But before I start my internal "lobbying" I have a couple of
> > questions:
>
> > 1) My understanding of the GNU General Public License vs GNU Library
> > General Public License in omniORB is that we can write CORBA programs
> > link it with omniORB.lib and sell it without having to make our source
> > available under GPL (because omniORB.lib is under the GNU library
> > license). However if we modify or extend the ORB core we have to provide
> > our source modification under GPL. Is this a correct understanding?
>
> This is correct.
>
When I read the actual GNU Library Public License, things seem a little
more complicated than this answer could suggest. Could someone please
take a good look at the two questions below:
1. I assume that it is correct that we do not have to make the source
code for programs that use omniORB available to the program's
customers. However, when reading the GNU Library Public License, it
seems that we may have to make the complete object code (with the
exception of omniORB) available, in order to make the customer able to
link in new or modified versions of omniORB. This includes the object
files for any other third party tools that are part for the program, and
will thus be in vialoation of the license policy of most such
libraries. If this is the case, it would make use of omniORB impossible
in many real life projects.
2. We build a lot of embedded systems at our company. Most real time
operating systems support muliple threads, but only a single process per
CPU. Since it is not acceptable to dedicate a CPU to the Naming Service
alone, it has to be modified slightly and included as part of the
application that we develop, in order to share a CPU with the
application. Would this constitue a "work using the library" or a "work
based on the library" as defined by the GNU Library Public License, and
how would this affect what we would have to make available to the
customers (source code, object files, object files for third pary
libraries, source code for third pary libraries)?
3. If the license, as it is today, makes the use of omniORB impossible
due to the problems mentioned above, will it be possible to negociate a
modified license for such a project?
The answers to these questions could be very important to most
professional users of omniORB, as a too strict license policy in these
areas will make it very difficult to use omniORB in many real life
projects.
--
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)
--------------8A48281F376E3C5B0BA852B7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I'm wondering if somebody could clarify some issues regarding omniORB licensing.
<p>I found the following in the arcives (subject "omniORB questions", dated
Tue, 15 Jul 1997 14:54:53 +0100, replyer is Sai-Lai Lo):
<blockquote TYPE=CITE>
<pre>>>>>> Lars Jarnbo Pedersen writes:
> I'm using omniORB to gain some insights on basic CORBA ORB
> infrastructure. After studying your very well structured and modular ORB
> architecture I'm considering using omniORB for some prototyping
> projects. But before I start my internal "lobbying" I have a couple of
> questions:
> 1) My understanding of the GNU General Public License vs GNU Library
> General Public License in omniORB is that we can write CORBA programs
> link it with omniORB.lib and sell it without having to make our source
> available under GPL (because omniORB.lib is under the GNU library
> license). However if we modify or extend the ORB core we have to provide
> our source modification under GPL. Is this a correct understanding?
This is correct.</pre>
</blockquote>
<p><br>When I read the actual GNU Library Public License, things seem a
little more complicated than this answer could suggest. Could someone
please take a good look at the two questions below:
<p>1. I assume that it is correct that we do not have to make the source
code for programs that use omniORB available to the program's customers.
However, when reading the GNU Library Public License, it seems that we
may have to make the complete object code (with the exception of omniORB)
available, in order to make the customer able to link in new or modified
versions of omniORB. This includes the object files for any other
third party tools that are part for the program, and will thus be in vialoation
of the license policy of most such libraries. If this is the case,
it would make use of omniORB impossible in many real life projects.
<p>2. We build a lot of embedded systems at our company. Most real
time operating systems support muliple threads, but only a single process
per CPU. Since it is not acceptable to dedicate a CPU to the Naming
Service alone, it has to be modified slightly and included as part of the
application that we develop, in order to share a CPU with the application.
Would this constitue a "work using the library" or a "work based on the
library" as defined by the GNU Library Public License, and how would this
affect what we would have to make available to the customers (source code,
object files, object files for third pary libraries, source code for third
pary libraries)?
<p>3. If the license, as it is today, makes the use of omniORB impossible
due to the problems mentioned above, will it be possible to negociate a
modified license for such a project?
<p>The answers to these questions could be very important to most professional
users of omniORB, as a too strict license policy in these areas will make
it very difficult to use omniORB in many real life projects.
<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>
--------------8A48281F376E3C5B0BA852B7--