🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.misc.discuss
Article #74100

Re: GLGPL and shared libraries

#74100
From: Aydin Edguer
Date: Wed, 26 Jun 1991 15:06
44 lines
3173 bytes
In article <1991Jun25.201714.13079@netcom.COM> craig@netcom.COM (Craig Hansen) writes:
>Basically, as a system vendor, I have no problem with distributing the source
>code to libraries derived from GLGPL-covered code, including upgrades, bug
>fixes, and so forth.

Sounds good so far.  I assume that "distributing the source code" includes both
your customers _and_ the Free Software Foundation.

>The problem that arises is that the GLGPL places restrictions on a "works
>that uses the library" as may be developed by a software hoarder that are
>significantly greater than the industry status quo.

Really?  The only "restriction" that I see is:
 + If you link a program with the library, you must provide complete object
 + files to the recipients so that they can relink them with the library,
 + after making changes to the library and recompiling it.

Admittedly, this may seem new to "applications" people, but it is standard
operating procedure for UNIX kernel objects.  The "applications" company is
not giving up any more information than they had released previously.
I fail to understand the objection to this restriction.  The "applications"
company is free to release a statically linked executable for those people
who do not wish to try relinking, just so long as they provide the objects
for those few (?) people who are interested.

This "restriction" of the GLGPL is becoming moot as time passes.

Currently GCC (as distributed) does not support dynamic linking with
libraries.  But as a "system vendor" you have the option of supplying DLD,
or helping rewrite GCC to support shared libraries.  By using and supplying
such software you automatically supply your "applications" programmers with
the capability of "relinking" (e.g. dynamic binding) their programs with
a GLGPL covered library.  If you feel a GLGPL covered library is not well
designed for use as a shared library - help rewrite it!!  Then everyone
can benefit.

>These restrictions make it tougher for me, a wanna-be software sharer
>and wanna-be system vendor to make the choice to use GLGPL-covered code.

Currently, yes, these restrictions make it tougher for some system vendors.
But then again, it also makes it easier for some system vendors.  They get
"free" support for their software by a large body of programmers.

Aydin Edguer
Technical Details
Message-ID: <1991Jun26.150617.20033@usenet.ins.cwru.edu>
Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!charlie!edguer
References: <1991Jun19.141134.19083@dg-rtp.dg.com> <ROCKWELL.91Jun22003222@socrates.umd.edu> <1991Jun25.201714.13079@netcom.COM>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 1025b4,1863b2678e8debd5
X-Google-Attributes: gid1025b4,public
X-Google-ArrivalTime: 1991-06-26 09:22:08 PST
Path: arc1-ca.pugleaf.net!gmdzi!unido!mcsun!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!charlie!edguer
From: edguer@charlie.CES.CWRU.Edu (Aydin Edguer)
Newsgroups: gnu.misc.discuss
Subject: Re: GLGPL and shared libraries
Message-ID: <1991Jun26.150617.20033@usenet.ins.cwru.edu>
Date: 26 Jun 91 15:06:17 GMT
References: <1991Jun19.141134.19083@dg-rtp.dg.com> <ROCKWELL.91Jun22003222@socrates.umd.edu> <1991Jun25.201714.13079@netcom.COM>
Sender: news@usenet.ins.cwru.edu
Distribution: gnu
Organization: Computer Engineering and Science, Case Western Reserve University
Lines: 45
Nntp-Posting-Host: charlie.ces.cwru.edu