[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Licensing issues



This has been brought up a while ago:

----------  Forwarded Message  ----------
Subject: LGPL interpretation
Date: Thu, 14 Sep 2000 18:42:42 +0100
From: Jose Orlando Pereira <jop@di.uminho.pt>
To: gnu@gnu.org


[This is a question concerning the interpretation of the LGPL
 If I should direct this query elsewhere please feel free
 to disregard it, or be so kind as to direct me to the
 appropriate forum.]

Dear sir,

Some time ago I've released a library using the GNU LGPL
(http://xtl.sourceforce.net). As it is a C++ template
library, it cannot be distributed separately as a
dynamically linked shared object for updating as
required by the LGPL (and neither the program that uses
it as an object file for relinking). It is in fact similar
to a C library that only includes macros and not functions,
so I'd like to know if this problem has come up before.

I've considered three solutions:

 - the impossibility of separate linking voids the
   relinking clause and everytinhg is ok;
 - I should explicilty state that the relinking clause
   is not applicable;
 - I could (but I certainly shouldn't) add a couple
   of functions so the relinking clause can be formally
   met.

As such I'd like to hear your opinion on the subject, as
it would not be correct to advertise  my software as licensed
under the GNU LGPL if it subverts the spirit of the license,
even if formally correct.

Thank you in advance,

--
Jose Orlando Pereira
* mailto:jop@di.uminho.pt * http://gsd.di.uminho.pt/~jop *

-------------------------------------------------------

----------  Forwarded Message  ----------
Subject: Re: LGPL interpretation
Date: Tue, 19 Sep 2000 01:09:00 -0400
From: Free Software Foundation <licensing@gnu.org>
To: Jose Orlando Pereira <jop@di.uminho.pt>


Jose Orlando Pereira wrote:
> Some time ago I've released a library using the GNU LGPL
> (http://xtl.sourceforce.net). As it is a C++ template
> library, it cannot be distributed separately as a
> dynamically linked shared object for updating as
> required by the LGPL (and neither the program that uses
> it as an object file for relinking). It is in fact similar
> to a C library that only includes macros and not functions,
> so I'd like to know if this problem has come up before.
>
> I've considered three solutions:
>
>  - the impossibility of separate linking voids the
>    relinking clause and everytinhg is ok;

If it is technical infeasible to distribute a library as a dynamic library,
then issues of dynamic linking simply don't come up.  I believe everything
is ok.


--
Bradley M. Kuhn
Free Software Foundation     |  Phone: +1-617-542-5942
59 Temple Place, Suite 330   |  Fax:   +1-617-542-2652
Boston, MA 02111-1307  USA   |  Web:   http://www.gnu.org

-------------------------------------------------------


-- 
Jose Orlando Pereira
* mailto:jop@di.uminho.pt * http://gsd.di.uminho.pt/~jop *