l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2002 Mar 30 04:49

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] writing free getopt, ran into a dilemma...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] writing free getopt, ran into a dilemma...



On Thu, Mar 28, 2002 at 05:04:49PM -0800, Mark K. Kim wrote:
> On Thu, 28 Mar 2002, nbs wrote:
> > I don't have the LGPL in front of me, but I believe it says something
> > to the affect of:
> >
> >   * if you statically-link, you must also provide a version of the binary
> >     that will dynamically-link, if the user wishes to do so
>
> Really?

  No, not really.  However, you must provide the user with the ability 
to change the LGPL'd library inside your static application.

  The issue is you must provide the customer with the "freedom" to 
fix bugs in the LGPL'd library.  One of the main points behind the *GPL
is to allow users to fix/improve/change things themselves.

  If you think about it a statically compiled application using LGPL'd
code is as much a unmodifiable black box as a statically compiled
application using completely proprietary code... so in effect you have
placed additional restrictions on the down stream users of LGPL'd code
which Not Okay.

  Below are the relevant portions about static linking.  The license
as a whole makes more sense to read the whole thing, that reading
should take less than 10 mins.

> What if the software were commercial (used in a commercial product)?

  Then you do exactly what the license tells you to, provide the customer
with the object files so they can link your static application against
a changed version of the static LGPL'd library if they want to.

> I thought the whole point of all this LGPL discussion on SDL
> list way back when was because you couldn't statically-link at all if you
> wanted to keep the source closed...?

  You can staticly link, and ship the result, I'm not familar with those 
discussions.

    TTFN,
      Mike

from /usr/share/common-licenses/LGPL
#   For example, if you distribute copies of the library, whether gratis
# or for a fee, you must give the recipients all the rights that we gave
# you.  You must make sure that they, too, receive or can get the source
# code.  If you link other code 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.  And you must show them these terms so they know their rights.
[...]
#   Although the Lesser General Public License is Less protective of the
# users' freedom, it does ensure that the user of a program that is
# linked with the Library has the freedom and the wherewithal to run
# that program using a modified version of the Library.
[...]
#   6. As an exception to the Sections above, you may also combine or
# link a "work that uses the Library" with the Library to produce a
# work containing portions of the Library, and distribute that work
# under terms of your choice, provided that the terms permit
# modification of the work for the customer's own use and reverse
# engineering for debugging such modifications.
[...]
#     a) Accompany the work with the complete corresponding
#     machine-readable source code for the Library including whatever
#     changes were used in the work (which must be distributed under
#     Sections 1 and 2 above); and, if the work is an executable linked
#     with the Library, with the complete machine-readable "work that
#     uses the Library", as object code and/or source code, so that the
#     user can modify the Library and then relink to produce a modified
#     executable containing the modified Library.  (It is understood
#     that the user who changes the contents of definitions files in the
#     Library will not necessarily be able to recompile the application
#     to use the modified definitions.)

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.