Update: Add specific source design documentation.

I have described this in one manner or another since the start of the FLL project.
This explicitly states the behavior that the FLL project (and related projects) have always followed.

diff --git a/documents/source_design.txt b/documents/source_design.txt
new file mode 100644 (file)
index 0000000..bd48b3b
--- /dev/null
+++ b/documents/source_design.txt
@@ -0,0 +1,82 @@
+# fss-0002 iki-0000
+#
+# license cc-by-sa-4.0
+# version 2025/08/26
+#
+# This file (assumed to be named source_design.txt) can be more easily read using the following iki_read commands:
+#   iki_read source_design.txt +Q -w -rrr API API FLL FLL FSS FSS -WW character "'" "'" code '"' '"'
+#
+# To read the "Intent and Design of Source Code" section of this file, use this command sequence:
+#   fss_basic_list_read source_design.txt +Q -cn "Intent and Design of Source Code" | iki_read +Q -w -rrr API API FLL FLL FSS FSS -WW character "'" "'" code '"' '"'
+#
+
+Intent and Design of Source Code:
+  This project follows the bold:"Intent and Design of Source Code" of the FLL:"Featureless Linux Library".
+  The italic:"Intent and Design of Featureless Linux Library" section is a copy of the FLL:"Featureless Linux Library" intend and design text.
+
+Intent and Design of Featureless Linux Library:
+  The FLL:"Featureless Linux Library", and many of the related projects, follow specific designs on how the source code, the API:"Application Programming Interface", the ABI:"Application Binary Interface", and the numerous specifications are intended to be operated and used.
+
+  The biggest and most important of these is that this project is designed and intended to be used and optionally modified in an open-source and free manner.
+
+  There are several principles in which the FLL:"Featureless Linux Library" is designed around to help achieve this\:
+    1. All software can be a library; the distinction between an executable program and a library is not real and is a falsehood.
+    2. Proper use and understanding of terminology.
+    3. All functions can be added, removed, and modified at will; the behavior and functions can be changed in any manner.
+    4. Separation of a specification from its implementation.
+    5. The ability to combine, merge, separate, mix, and unmix any of the source code into different forms.
+    6. Leave the actual configuration setup to th users combining or distributing the software.
+    7. The software should ideally be functional examples where anything being present itself can potentially be fully used.
+
+  The first principle is easily achieved in languages like C and C++.
+  Use the dynamic linker and link the programs, aka executables, as a library and make the actual program more or less a shim.
+  This does not mean programs cannot have additional changes and behavior.
+
+  The second principle can be solved by closely observing actual meanings of technological terms and through the avoidance of "buzz" terms.
+  The terminology that has been historically established in the computer software field has seen some erosion.
+  One such example is with the API:"Application Programming Interface", which has been misused to represent request messages, like with REST:"Representational State Transfer" which is a protocol and rather than an API:"Application Programming Interface".
+  The second principle strongly supports the first by recognizing what is really happening verses what is an artificial or conceptual distinction.
+  A program, or executable, is ultimately no different from a library.
+  The distinction between the two is ultimately conceptual.
+  There are many libraries that can be executed like a program and there are programs that can be linked to by a library.
+
+  The third principle is solved through how the source code is structured.
+  In the case of C code, nearly every aspect has an code:"ifdef" (or similar) wrapping that allows for customization.
+  The files themselves are broken up into context and purpose.
+  This should allow for the dynamic cherry-picking style enable or disabling certain functions.
+  Alternative versions of functions, that may or may not operate differently, can be enabled or disabled in a similar manner.
+  Major groups of changes can be performed by swapping in or out different source files.
+  The ability to completely omit massive amounts of functionality can be accomplished through various combinations therein.
+  There are even pre-built "disable" files to help facilitate mass changes.
+  There are also guides on generating and using stand alone builds.
+  Something similar will likely have to be followed as appropriate for languages other than C and C++.
+
+  The fourth principle is achieved first by following the second principle and then by establishing differences between what a library is and what a specification is.
+  A specification has its own license, independent of the license of the source code, and also helps facilitate the distinction between a library and the specification.
+  A library can follow the specification or can deviate from the specification, by design.
+  When this deviation occurs should be properly documented or communicated.
+  Following the specification, be it in full, in part, or even minimally, is all allowed but should be properly communicated.
+  Whether any aspect of a specification needs to or needs to not be followed is entirely situational and such decisions should be made by the individuals or entities building and distributing such software (be it in binary or in source form).
+  This is not to say that the license can be violated.
+  Be aware, however, that it is the code or the specification that can be changed, not the license itself.
+
+  The fifth principle is achieved through numerous means.
+  The Featureless Make and related specifications provide a means to tweak and customize how the library is built.
+  The separation of the installation logic from the build logic is a major player here.
+  The source code does not impose, for the most part, any sort of restrictions on how the software is to be installed once compiled.
+  This is left to the distributor or the end-user.
+  Linking dynamically or statically is entirely optional.
+  Linking in one big library or many smaller pieces is entirely optional.
+  Excluding or including individual snippets or functions is configurable, such as how the stand alone builds are designed.
+
+  The sixth principle is achieved by providing a standard build structure for compiling that does not particularly relate to the system setup.
+  Many of the designs from the fifth principle help make the sixth principle possible, such as the Featureless Make build system.
+  The build system setup is laid out based on how the files are built rather than how they might be installed.
+
+  The seventh principle is achieved in several different ways.
+  The example bootstrap scripts are themselves used to help build or initialize projects if the Featureless Make software is not yet present.
+  Stand alone builds are functional examples that present how one might construct a stand alone project.
+  These stand alone builds are themselves formally released as convenience releases for individuals only desiring one program and not any other parts of the FLL:"Featureless Linux Library",.
+  The stand alone builds also present ways to mass disable unneeded functionality from the FLL:"Featureless Linux Library" dependencies.
+  The Featureless Make itself provides build examples that can simultaneously be used as manual runtime tests.
+  The FSS Read, FSS Write, IKI Read, IKI Write programs provide functional examples on how to implement and use the FLL:"Featureless Linux Library"  and follow the FSS:"Featureless Settings Specifications" while simultaneously providing a tool to process the associated specification.