3

SDL 2's installation page contains the following comment on static linking:

However, we encourage you to not do this for various technical and moral reasons

I totally get why they would mention technical reasons, and the document linked in the same paragraph makes some very good points about the advantages of dynamic linking and a "best of both worlds" approach.

However, how can there be moral reasons to avoid static linking? What?

Wingblade
  • 207
  • 2
  • 6

2 Answers2

8

However, how can there be moral reasons to avoid static linking? What?

You (ethically) should be helpful to your user, and make his life easier. If you link dynamically to some free software libraries (like zlib), he could upgrade his system and your software on it would profit of the upgraded library immediately.

If you distribute a statically linked executable against an LGPL library and do not provide means to re-link it to some newer (or improved, or modified) version of that library (typically by releasing object files for your application), you probably are violating the LGPL license (and it might happen that some organization -or some competitors- would sue you, see http://gpl-violations.org/ & https://www.gnu.org/licenses/gpl-violation.html ....).

The http://www.fsf.org/about/what-is-free-software page is mostly about ethics

And some customers might actually care about a software using free software and being unfriendly to it. For that precise reason, I avoid buying Nvidia products.

Also, some potential hires might also be turned off by such behavior.

And using often shared libraries (and avoiding static ones) decrease the total disk space required on the user's computer, and decrease RAM usage (since the code segment of shared libraries used by several processes is mapped only once).

Basile Starynkevitch
  • 32,434
  • 6
  • 84
  • 125
  • 10
    Counterpoint: If you link dynamically to some library and the user upgrades it and it contains new bugs (as is frequently the case) or compatibility-breaking changes, he could end up with a broken program that used to work. We have learned by decades of sad experience that dynamic linking sounds really nice in theory, but frequently fails to live up to its promise in practice, and sometimes (in the case of system-wide shared libraries) can cause catastrophic problems. – Mason Wheeler Feb 26 '17 at 11:29
  • 2
    It really depends a lot. Some Linux distributions take seriously compatibility issues. – Basile Starynkevitch Feb 26 '17 at 11:31
  • 2
    The other moral reason you didn't mention is that dynamic linking or re-linking allows you to use modified versions of those libraries with the software, which may be of use to someone. – whatsisname Feb 26 '17 at 14:39
  • 3
    @MasonWheeler: Also; link time optimisation is ruined by dynamic linking, and cheating in online/multiplayer games (the user replacing a shared library with a modified version) is enabled by dynamic linking. – Brendan Feb 26 '17 at 15:57
  • 5
    "he could upgrade his system and your software on it would profit of the upgraded library immediately" Assuming the upgraded library doesn't break your software, which is a pretty big assumption. The kind of assumption DLL hell was based on. – Andy Feb 26 '17 at 16:17
  • 1
    I just don't get Dynamic linking. It sounds like a terrible idea all around. -"Assuming the library is already in the user computer to save a few .mb"... pff, The most likely scenario is the user doesn't even have the library and will run into a ".dll not found" at start-up. -"Upgrading the library independently from your software" sure, very nice but, wouldn't you like to, you know... TEST your software with the new library version. Always static link – frankelot Apr 17 '20 at 17:35
  • There two main reason two encapsulate your software statically: compatibility and easy distribution. Cross-platform development can be a nightmare. But some companies take the dark side of that and use it to obfuscate and "keep safe" their knowhow. – Teocci Nov 18 '21 at 05:46
5

I think the author is trying to be a little bit comical, but it seems there is a bit of history behind this, as can be seen in the readme file:

We like the zlib license, but the biggest complaint from the open source community about the license change is the static linking. The LGPL forced this as a legal, not technical issue, but zlib doesn't care. Even those that aren't concerned about the GNU freedoms found themselves solving the same problems: swapping in a newer SDL to an older game often times can save the day. Static linking stops this dead.

John Wu
  • 26,032
  • 10
  • 63
  • 84
  • 1
    I always find it puzzling when open-sourcers complain about things getting *too* free, e.g. programmers being given the freedom to statically link a library if they so choose. Very possible that the author was poking fun at the ideological sillyness involved in license changes like these. – Wingblade Feb 25 '17 at 10:15
  • 2
    @Wingblade Seems pretty serious to me. I don't think they were poking fun. "Libre" software matters to a lot of people... – Andres F. Feb 25 '17 at 19:43
  • 2
    @Wingblade: Freedom does not mean you are allowed to do whatever you want, unless you mean that there would be more freedom if we were allowed to steal, if we so choose. As far as I understand, freedom in LGPL means "You are free use, extend, study... a piece of software, as long as you do not integrate it into a larger piece of software making it indistinguishable from the whole.". So, you are granted many freedoms with the software, but not the freedom to steal it. I am not an expert in LGPL though, and my observations may be incorrect. – Giorgio Feb 26 '17 at 08:56
  • 1
    @Giorgio: you can't steal software unless you delete it from the remote servers in the process. A better description of the GNU philosophy is "if you want to benefit from others you need to contribute back" – whatsisname Feb 26 '17 at 14:42
  • @whatsisname: As far as I know, it is OK to use free software without contributing back. What is not acceptable is to use a piece of free software A as a module in a piece of software B (so that all the work that went into making A becomes part of the work that went into making B) without (1) acknowledging the contribution of the original creator of A to product B, and (2) granting users of B certain rights regarding the A-part of B. I imagine that problems arise with static linking because this makes A indistinguishable from B. – Giorgio Feb 26 '17 at 14:54