Date: Mon, 23 Jun 1997 11:09:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: gclarkii@main.gbdata.com, msmith@atrad.adelaide.edu.au, hackers@FreeBSD.ORG Subject: Re: use of readline() Message-ID: <199706231809.LAA00997@phaeton.artisoft.com> In-Reply-To: <8693.867068734@time.cdrom.com> from "Jordan K. Hubbard" at Jun 23, 97 05:25:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I belive that readline is the GNU version correct? > > Would this not make all of these programs fall under the GNU Copyleft? > > No. Go read the LGPL. Jordan's right. They will not fall under GNU "Copyleft". What will happen, however, is that they *will* all fall under the "relink clause" of the LGPL (ie; you must allow users to relink your application against a newer version of the library). Unfortunately, the BSD version of shared libraries can not meet this clause, and the LGPL does not take notice of shared library technology, being an antiquated document. The BSD shared libraries can not meet this clause because the agregate initialized data from the library *must* be linked into the executable image. This is because the default BSD executable format, a.out, does not support section attribution; if it did, the shared library image could have seperate sections for code and data, and there would not be a collision with the data section in the program itself. BSD *happens* to place non-agregate global data for the library (uninitialized global and static data) into the image as well. Sun Microsystems recognized this problem early on, and went to a scheme where they compile the shared libraries with special compiler flags to note the data references, and then seperated the code and data into seperate files in /usr/lib. They did this to save image size more than to support use of LGPL libraries. Although ELF technology has the capability to support section attribution, and thus resolve this issue, even Linux, a native ELF system making heavy use of LGPL'ed libraries, currently do not use this technique to meet the relink clause. Because of this, it's possible that, after a library change in which the only change was to the size of data objects, programs which were formerly in compliance with LGPL would be in noncompliance. Under the terms of the LGPL, this would allow users to demand linkable object modules from commercial vendors as the minimum remedy. I have argued with Richard Stallman for specific recognition of shared library technology, and an exception to the code inclusion and relink clauses, nearly ever since the LGPL was published... to no avail. My advice is to not use LGPL'ed libraries unless you are prepared to ship linkable objects for your products, or until such time as FreeBSD moves to ELF (or a similar section attributable object format, like ELF -- ELF64, etc.) and implements seperate data sections for library data so that tey need not be linked with the image. Nay-Sayers: This issue has been discussed before under the topic "LGPL"; linkage and "nm" based data dumps proving location of agregate initialized library data were provided in those discussions; see the -hackers and -current list archive on www.freebsd.org for details before counter-claiming that shared library data is not linked into a.out images to save yourself embarrasment. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706231809.LAA00997>