Should we include the entire sources of the libraries used in our project?

Question

I'm used to using static link libraries in my projects. This doesn't make the solution heavier and allows to be updated more easily.

However, I see some GitHub repos providing in their sources the code of the libraries they use (the example that made me raise this question is the libffi library entirely taken in the source code of the Racket language).

Why such a choice? If I want to make a project public on GitHub, should I use the source in the project, or consider using the static libraries?

EDIT

I'm asking this question in a somewhat encompassing way, although I imagine the answers will vary depending on what is being used as well as the target audience.

To focus the question a bit more, I was looking at projects written in C, for non-embedded platforms. I have a virtual machine project (under the Apache 2.0 license), which uses MIT and LGPL license libraries. I'm targeting x86 architectures.

Answer 1

Putting the entire source of a library in your project allows you to:

1. Maintain and update the library in the event that it is abandoned.
2. Make alterations to the library to advance goals for your specific project.
3. Run static code analysis tools on the library like Fortify and Coverity Prevent as part of your DevOps process.
4. Educate your developers on the project's internals.

Answer 2

Should we include the entire sources of the libraries used in our project?

If your code is written in C, it (generally) uses the C standard library. If it is coded in C++, it uses the C++ standard library. I usually see no reason to include in your code the source code of them (e.g. GNU glibc on Linux).

And if your code uses very common libraries (think of libcurl as an example on Linux), I am not sure that including their source code (e.g. the source of libcurl inside your GitHub repository) in your code makes practical sense.

I'm used to using static link libraries in my projects. This doesn't make the solution heavier and allows to be updated more easily.

I am not convinced it is always a good idea.

If all the processes running on your computer are statically linked, total memory consumption is higher, because there is no shared libraries. On Linux, read Drepper's paper How to write shared libraries. So using static libraries does make your user computer "heavier" (in the sense of requiring more physical memory, since virtual memory becomes less efficient : the code segment of a library used by several processes can be shared by paging only if it is a shared library).

Details are of course operating system specific and related to the expertise of your audience users.

A motivation for using static libraries is to fight the dependency hell. But that core issue is supposed to be solved by package managers. And at the source level, what matters is API compatibility (related to semantic versioning).

Notice also that your software is less likely to becomes packaged and redistributed in binary form if it uses LGPL libraries, whose license practically almost requires them to be shared libraries and linked dynamically (this is an oversimplification).

My personal recommendation is to use (on Linux) shared libraries when then are usually packaged in major Linux distributions. Of course, the evil is in the details and your mileage may vary.

You might be interested by the SoftwareHeritage project and the research these nice folks (notably Roberto Di Cosmo) are doing.

In my RefPerSys and Bismon projects (both are GPLv3+ free software), I definitely use shared libraries.

On my Debian desktop, almost all software are dynamically linked, and for a good reason. Exceptions include low level utilities like sash.