LGPL legal questions about SMPEG

“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.”

So basically, I spend time and effort gathering versions of SDL, freetype
etc. that actually work together, spend time debugging the whole damned
thing, and packaging it up into a form that I KNOW works, only to have
numerous people relinking it with OTHER versions of the library…

errr. that sux.

So basically we can have no quality control over this at all…
Backwards compatibility is never reliable enough to say for
example “…SDL versions 1.1.8 and upwards”, experience with a large
variety of libraries tells me that you can never count on future
versions being 100% compatible no matter how well intentioned the author
is…to say nothing of the troubles of certain library versions being
bugged on some platforms and not others…

I work in a job where we do customer support (as well as dev) and you can
never underestimate the stupidity of the end user, to my mind the LGPL is
a license designed by programmers for programmers.
Joe public doesn’t WANT to be able to relink his app, but forcing us to
dynamically link libraries allows for all sorts of problems customer-side
that would not be there in a single-executable deployment.

Example… Joe Public gets my program and installs it. It installs v1.1.8
of SDL amongst other things, and sets up any environment settings
needed for dynamic libraries (eg PATH or LD_LIBRARY_PATH, or
registering them on windows)…

the Joe Public installes a different older SDL app, which itself installs
a version of SDL, say v1.1.2

now on linux this could change the symlink libSDL.so to point to the older
library…screwing up my app. Or it could conceivably install in a
different location and screw over my PATH’s so that it finds the other
version first…
Sure it’s all solvable, but not by Joe Public.
Windows too. Though windows should check the local folder first, thne the
path , then the system(32) folder, experience has taught me that this is
not always the case, esp. on 95 etc… where DLLs stay loaded…
hurrah, DLL hell.
Again solvable, but not by Joe Public. Only by those with some knowledge.
(oh, and on windows most installers will default to putting DLLs into the
system directory, and most programmers just let them do this, leaving it
up to Joe Public to get the “a Newer/Older version” dialog on install,
thus there is no certainty what is on their system)

It’s stupid to allow end users to relink with libraries…
The version they get sent with the product is the one proven to work…
If there is a problem then fixes should come from the app vendor, so the
fixes are present in the current source tree/ditribution…

Users should not be encouraged to “jury Rig” applications…
For every user that hacks a bugged app into working, that’s (usually) an
bug that goes unreported.

not quite so sure I can be bothered with ANY LGPL stuff anymore…
it seems like a support nightmare…

Yours,
Andy Gordon-----------------------------------------------------------------
QueriX UK
36A London Road http://www.querix.co.uk
Southampton
Tel: +44 23 8023 2345 andy at querix.co.uk
Fax: +44 23 8039 9685

“Andy Gordon” wrote in message
news:mailman.1014026707.20009.sdl at libsdl.org

Example… Joe Public gets my program and installs it. It installs
v1.1.8
of SDL amongst other things, and sets up any environment settings
needed for dynamic libraries (eg PATH or LD_LIBRARY_PATH, or
registering them on windows)…

A good installer should install SDL in the same directory as the game
and not make any changes to the system outside of that directory. It
works under Windows, but I’m not sure how viable it is under Linux.–
Rainer Deyke | root at rainerdeyke.com | http://rainerdeyke.com

“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.”

So basically, I spend time and effort gathering versions of SDL, freetype
etc. that actually work together, spend time debugging the whole damned
thing, and packaging it up into a form that I KNOW works, only to have
numerous people relinking it with OTHER versions of the library…
So basically we can have no quality control over this at all…
Backwards compatibility is never reliable enough to say for
example “…SDL versions 1.1.8 and upwards”, experience with a large
variety of libraries tells me that you can never count on future
versions being 100% compatible no matter how well intentioned the author
is…to say nothing of the troubles of certain library versions being
bugged on some platforms and not others…
I work in a job where we do customer support (as well as dev) and you can
never underestimate the stupidity of the end user, to my mind the LGPL is
a license designed by programmers for programmers.
Joe public doesn’t WANT to be able to relink his app, but forcing us to
dynamically link libraries allows for all sorts of problems customer-side
that would not be there in a single-executable deployment.
Example… Joe Public gets my program and installs it. It installs v1.1.8
of SDL amongst other things, and sets up any environment settings
needed for dynamic libraries (eg PATH or LD_LIBRARY_PATH, or
registering them on windows)…

the Joe Public installes a different older SDL app, which itself installs
a version of SDL, say v1.1.2

It’s stupid to allow end users to relink with libraries…
The version they get sent with the product is the one proven to work…
If there is a problem then fixes should come from the app vendor, so the
fixes are present in the current source tree/ditribution…

There are very good reasons for the LGPL’s requirement to allow users to
relink with modified libraries. See the FSF’s web site for an explanation.

There is also quite a difference between “allow” and “encourage”.

If I’m not mistaken, Loki shipped statically linked versions of its games,
but also made dynamically linked versions available to satisfy the terms of
the LGPL. However, I seriously doubt Loki support would provide help for
modified versions of the app.

You could also satisfy the LGPL’s requirements by making the object files
for the application available (say, on your FTP site), and just shipping a
statically linked binary. The AC3D modeller does this to permit motivated
users to replace the linked OpenGL library with one better suited for their
hardware.

Of course, if you don’t wish to use LGPL’ed code, that’s fine too. However,
I would be seriously surprised if you would save more effort than you would
gain from this large body of code.

-JohnOn Mon, Feb 18, 2002 at 10:03:11AM +0000, Andy Gordon wrote:


John R. Hall - Resident, Sol System, 3rd Planet Out
Student, Georgia Tech; Author, Programming Linux Games

So basically, I spend time and effort gathering versions of SDL, freetype
etc. that actually work together, spend time debugging the whole damned
thing, and packaging it up into a form that I KNOW works, only to have
numerous people relinking it with OTHER versions of the library…

errr. that sux.

[rant chopped].

You can do what Loki did, which worked rather well.

Shipped two binaries. Make the one that everyone uses, that the pretty
icons point to, etc, be statically linked with everything possible (SDL,
freetype, etc). Have another binary that is dynamically linked. Put it in
an “unsupported” folder. The real hackers, if they need it, will be able
to use it, the rest of the world won’t even notice it, you don’t have to
help anyone with it, the LGPL is satisfied, and everyone wins.

Coincidentally, the LGPL has been very helpful in this case. I’ve been
able to debug problems in Descent3 after leaving Loki by working around
them in SDL with the dynamic binaries (reference the null video driver
being used with D3 dedicated servers). This is going to be more important
now that Loki won’t be supporting these games.

–ryan.

Es schrieb “John R. Hall”:

You could also satisfy the LGPL’s requirements by making the object files
for the application available (say, on your FTP site), and just shipping a
statically linked binary. The AC3D modeller does this to permit motivated
users to replace the linked OpenGL library with one better suited for their
hardware.

Es schrieb Andy Gordon:

That’s the main disadvantage to dynamic libraries…
And why, size allowing, I’d rather have the freedom to use static
libraries, and govern my products’ QC myself, including what versions of
what libraries I use.

Es schrieb Rainer Deyke:

A good installer should install SDL in the same directory as the game
and not make any changes to the system outside of that directory. It
works under Windows, but I’m not sure how viable it is under Linux.

the linux/solaris ldso at elf allows -rpath : to link your binaries from
a specific place, and this is almost similar to the windows localdir
thing, as the rpath gets prepended to the ld_library_path by ldso
(in windows, the localdir is always up front of the libsearch path).
Note that automake/libtool programs will have rpath automatically in
the project makefile. However, installing into a different path on
these systems will need to relink the rpath, but there is a tool at
freshmeat that can do that. Well, just like on windows, the user is
not prevented from placing a modified library in the same place, and
the LGPL will ensure that even for the case that the default startup
binary is shipped statically linked, as you are required to ship a
relinkable format too, atleast alternatively.

Es schrieb “Ryan C. Gordon”:

Coincidentally, the LGPL has been very helpful in this case. I’ve been
able to debug problems in Descent3 after leaving Loki by working around
them in SDL with the dynamic binaries (reference the null video driver
being used with D3 dedicated servers). This is going to be more important
now that Loki won’t be supporting these games.

exactly! in a way, using an opensource library will lower support cost
as the bugs are trackable by someone else, and might be fixed outside of
the original support staff of the enterprise using this lib in question.

Es schrieb “Ryan C. Gordon”:

… You can do what Loki did, which worked rather well. …
Shipped two binaries. Make the one that everyone uses, that the pretty
icons point to, etc, be statically linked with everything possible (SDL,
freetype, etc). Have another binary that is dynamically linked. Put it in
an “unsupported” folder. The real hackers, if they need it, will be able
to use it, the rest of the world won’t even notice it, you don’t have to
help anyone with it, the LGPL is satisfied, and everyone wins.

the definite answer. the final answer. (end of thread).

cheers,
– guido http://freespace.sf.net/guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(±) s+a- r+@>+++ y++ 5++X- (geekcode)