<?xml version="1.0" encoding="UTF-8"?>
<!--
Sane software manifesto
Copyright © 2019 František Kučera (Frantovo.cz, GlobalCode.info)
This manifesto is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.
https://creativecommons.org/licenses/by-nd/4.0/
If distributed, official website of Sane software manifesto must be provided: https://sane-software.globalcode.info/
-->
<manifesto
xmlns="tag:globalcode.info,2019:sane-software/manifesto"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="tag:globalcode.info,2019:sane-software/manifesto ../schema/ssm.xsd">
<title>Sane software manifesto</title>
<id>fd466b50-6abd-4294-b11f-a5b8f2f39c2a</id>
<url>https://sane-software.globalcode.info/</url>
<author>František Kučera (Frantovo.cz, GlobalCode.info)</author>
<license>
<name>Creative Commons Attribution-NoDerivatives 4.0 International License</name>
<abbreviation>CC-BY-ND</abbreviation>
<url>https://sane-software.globalcode.info/license/CC-BY-ND-4.0.txt</url>
<year>2019</year>
<prefix>This manifesto is licensed under the </prefix>
<suffix>.</suffix>
</license>
<preamble>In respect to user freedoms, privacy, liberty and software quality we create software according to the following guidelines. Developing Sane software is not easy, however we believe that this is the right way because this software is written once but used many times and maintained for years or decades.</preamble>
<chapter>
<name>Free software</name>
<id>ca4d0f6c-9996-49ac-8647-b7f15b049b03</id>
<item>
<id>a755410b-6264-4094-b339-aeca55448e8d</id>
<type>requirement</type>
<text>Every piece of Sane software is also Free software (as originally defined by Richard Stallman).</text>
<text>Which means that the user has freedom to</text>
<text>run the program for any purpose,</text>
<text>to study and change it (i.e. has access to the source code under a free software license)</text>
<text>and to distribute modified or unmodified copies.</text>
<link>
<url>https://www.gnu.org/philosophy/free-sw.html</url>
<type>compatible</type>
<title>What is free software? – The Free Software Definition</title>
<quotation>“Free software” means software that respects users' freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software. Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”. We sometimes call it “libre software,” borrowing the French or Spanish word for “free” as in freedom, to show we do not mean the software is gratis.</quotation>
<quotation>A program is free software if the program's users have the four essential freedoms: The freedom to run the program as you wish, for any purpose (freedom 0). The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this. The freedom to redistribute copies so you can help others (freedom 2). The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.</quotation>
</link>
<link>
<url>https://www.gnu.org/philosophy/who-does-that-server-really-serve.html</url>
<type>related</type>
<title>Who does that server really serve?</title>
<description>About Software as a Service (SaaS) and Service as a Software Substitute (SaaSS)</description>
<quotation>On the Internet, proprietary software isn't the only way to lose your freedom. Service as a Software Substitute, or SaaSS, is another way to give someone else power over your computing.</quotation>
</link>
</item>
<item>
<id>b7cd1a50-79eb-4df2-925c-7243a46d5ed8</id>
<type>information</type>
<text>The user controls his computer and software and owns the data. Not the author of the software or anyone else without user's explicit consent.</text>
</item>
<item>
<id>c78a9796-7862-4dd2-8ad9-3fdae094fe2c</id>
<type>requirement</type>
<text>Must be buildable using free software toolchain (like GNU/Linux + GCC or OpenJDK etc.).</text>
<link>
<url>https://www.gnu.org/prep/maintain/maintain.html#Ethical-and-Philosophical-Consideration</url>
<type>compatible</type>
<title>Information for Maintainers of GNU Software: Ethical and Philosophical Consideration</title>
<quotation>A GNU package should not recommend use of any non-free program, nor should it require a non-free program (such as a non-free compiler or IDE) to build. Thus, a GNU package cannot be written in a programming language that does not have a free software implementation.</quotation>
<quotation>Now that GNU/Linux systems are widely available, all GNU packages should provide full functionality on a 100% free GNU/Linux system, and should not require any non-free software to build or function.</quotation>
<quotation>Similarly, a GNU package should not require the use of non-free software, including JavaScript, for the coordination of its development.</quotation>
</link>
</item>
<item>
<id>b3c0daaf-dcaf-49a8-ae38-40590456a315</id>
<type>requirement</type>
<text>Must not promote non-free (proprietary) software or services.</text>
<link>
<url>https://www.gnu.org/prep/standards/standards.html#References</url>
<type>compatible</type>
<title>GNU Coding Standards: References to Non-Free Software and Documentation</title>
<quotation>A GNU program should not recommend, promote, or grant legitimacy to the use of any non-free program. Proprietary software is a social and ethical problem, and our aim is to put an end to that problem. We can’t stop some people from writing proprietary programs, or stop other people from using them, but we can and should refuse to advertise them to new potential customers, or to give the public the idea that their existence is ethical.</quotation>
</link>
</item>
<item>
<id>b2fd5d2d-4d47-48e8-8abc-4b1aa94a7951</id>
<type>recommendation</type>
<text>Copyleft licenses (like GNU GPL or GNU Affero GPL) are strongly recommended because they guarantee software freedoms to every single end-user and prevent possibility that freedom vanishes somewhere in the distribution chain and the user can not benefit from the free software albeit the software is build on originally free source code.</text>
</item>
<item>
<id>c3599313-338b-428d-885f-964a443d76c6</id>
<type>requirement</type>
<text>The license must be compatible with GNU GPLv3 in order to allow mixing with the GPL code.</text>
<text>The only exception is older software (created before this manifesto i.e. 2019) which is unable to change the license</text>
<text>due to the copyright owned by many authors who can not be reached anymore and who can not provide approval with the license upgrade.</text>
<text>Such software is called „Sane with exception“.</text>
<!-- TODO: provide exact wording of the exception e.g. XYZ is „Sane software (with GPLv2 license exception)“ -->
<note>Software versioned under GPLv2+ or GPLv3+ is compatible with GPLv3.</note>
</item>
<item>
<id>f39b90ae-0054-467e-a9e2-43379b7c2331</id>
<type>requirement</type>
<text>If the software is distributed with a hardware, the hardware must support installation of independently built software without any restrictions or requirements (e.g. digital signature from the original author).</text>
</item>
</chapter>
<chapter>
<name>Documented</name>
<id>e1c828c5-0a4f-4948-9943-db1ae16a42d5</id>
<item>
<id>c63ea2ac-c255-4f3e-a0e2-b49d1e145347</id>
<type>requirement</type>
<text>At least basic documentation must be released under a free license (GNU FDL is recommended).</text>
<link>
<url>https://www.gnu.org/prep/standards/standards.html#License-for-Manuals</url>
<type>compatible</type>
<title>GNU Coding Standards: License for Manuals</title>
<quotation>Please use the GNU Free Documentation License for all GNU manuals that are more than a few pages long.</quotation>
</link>
</item>
<item>
<id>fd8e3bbd-d46a-40fe-85a6-b902336456d4</id>
<type>requirement</type>
<text>Every advertised feature must be properly documented. Undocumented features can not be considered as features from the user/customer point-of-view.</text>
</item>
<item>
<id>e4dede5b-059e-4e47-b03d-80142b8467f1</id>
<type>information</type>
<text>There might be also other documentation/books released under any license and price.</text>
<link>
<url>https://www.gnu.org/prep/standards/standards.html#Reading-other-Manuals</url>
<type>related</type>
<title>GNU Coding Standards: Reading other Manuals</title>
<quotation>There may be non-free books or documentation files that describe the program you are documenting.</quotation>
<quotation>It is ok to use these documents for reference, just as the author of a new algebra textbook can read other books on algebra.</quotation>
</link>
</item>
<item>
<id>c0df4d14-43f8-4b61-83c4-fb5896161aeb</id>
<type>requirement</type>
<text>But average software engineer must be able to build and operate the software with just the free (basic) documentation.</text>
<link>
<url>https://www.gnu.org/prep/standards/standards.html#Configuration</url>
<type>related</type>
<title>GNU Coding Standards: How Configuration Should Work</title>
<quotation>Each GNU distribution should come with a shell script named configure.</quotation>
</link>
</item>
<item>
<id>e6cd9c52-0e66-402c-930c-901fa66acd22</id>
<type>requirement</type>
<text>There must be a free documentation with description of building and running the software on a fresh operating system installation including description of all dependencies.</text>
</item>
<!--
TODO: documentation target groups and big picture:
<item><id></id><text>documentation should focus on all target groups: users, administrators, developers</text></item>
<item><id></id><text>there must be a big picture and software architercure described</text></item>
-->
</chapter>
<chapter>
<name>Semantic versioning and upgrades</name>
<id>aa8bd952-842b-4391-aefe-d9b3750e432d</id>
<item>
<id>a8beddfc-11e3-4012-9f88-f79dc88eee16</id>
<type>requirement</type>
<text>Semantic versioning is required.</text>
<text>The version number consists of three numbers: major.minor.patch.</text>
<text>Major version is incremented if there is an incompatible change.</text>
<text>Minor version is incremented if a feature is added in a compatible way.</text>
<text>Patch version is incremented if a bug is fixed in a compatible way.</text>
<note>If authors are unable to distinguish between compatible and incompatible changes, they must always increment the major version. However this approach is not recommeded</note>
<note>Propper Semantic versioning is especially important if the software is suposed to be used as dependency by others.</note>
<note>If there is a need of some marketing or cool versioning/codenames like Ultrasonic Umbrella or 2016, they should be used in addition to semantic versioning, not instead of it.</note>
<link>
<url>http://semver.org/</url>
<type>compatible</type>
<title>Semantic Versioning</title>
</link>
<link>
<url>https://www.gnu.org/prep/standards/standards.html#Releases</url>
<type>compatible</type>
<title>GNU Coding Standards: Making Releases</title>
<quotation>You should identify each release with a pair of version numbers, a major version and a minor. We have no objection to using more than two numbers</quotation>
</link>
</item>
<item>
<id>cf557a11-b307-4c2f-a7b5-5d2485d23258</id>
<type>requirement</type>
<text>Once publicly released, the package must not be changed anymore – if a change (even a small fix) is needed, new version number must be assigned.</text>
</item>
<item>
<id>dd013325-bf22-43d3-9579-0e272e2ac344</id>
<type>information</type>
<text>APIs, file formats and protocols might (and usually should) be semantically versioned independently from the implementation.</text>
<note>In such case, there should be a table documenting which API/format/protocol version matches which implementation version.</note>
</item>
<item>
<id>dacb98cc-b558-4f0e-942d-e12004e45606</id>
<type>recommendation</type>
<text>The branching model in the version control system should reflect the semantic versioning.</text>
<text>The released version e.g. 2.3.1 should be tagged as v2.3.1 and be placed in the v_2.3 branch.</text>
<text>Where the v_2.3 branch was forked from the v_2 branch – from the v2.3 tag.</text>
</item>
<item>
<id>ae33d206-4988-44ec-b8e2-3120019fcf2f</id>
<type>recommendation</type>
<text>Do not remove features unless they are really obsolete, unused or irreparably broken.</text>
</item>
<item>
<id>c542336a-fce8-412c-a8dd-1328c1a884ec</id>
<type>information</type>
<text>The user interface might be simplified or redesigned while preserving the features under the hood.</text>
</item>
<item>
<id>ba8fecf0-5c02-4fdf-abdc-2650d428f82a</id>
<type>requirement</type>
<text>Incompatible changes must be planned and announced in advance.</text>
</item>
<item>
<id>f4826891-e732-45e8-b929-25d1182fa141</id>
<type>requirement</type>
<text>Upgrade scripts and upgrade documentation must be provided.</text>
</item>
</chapter>
<chapter>
<name>Names and identifiers</name>
<id>a416d88d-6a8f-4219-85f4-367a89396da9</id>
<item>
<id>b231cf73-6509-45d4-96c4-79060bf4f7bd</id>
<type>recommendation</type>
<text>The name of the product and its significant parts should be reasonably unique, so it can be found using full-text search or other standard methods.</text>
<note>Significant part is e.g. a protocol, a file format or a CLI command.</note>
<note>Global uniqueness is not necessary – such name is not a unique identifier. Collisions cannot be completely avoided, but we should make reasonable efforts to prevent them.</note>
<item>
<id>ebb8c013-a309-486d-b17b-04a73dd57969</id>
<type>recommendation</type>
<text>Avoid generic words like common verbs, nouns or adjectives.</text>
</item>
<item>
<id>d923f626-5fd9-4e6d-8f16-af9711ac6e2e</id>
<type>recommendation</type>
<text>Avoid name collisions with well known and used software.</text>
</item>
<item>
<id>fc3fab39-dfaa-4b90-b51d-11e6b9bf3f2f</id>
<type>recommendation</type>
<text>Use company or organization name as part of the name if the name itself would be too generic (e.g. „Speed“ is wrong while „SaneCorp Speed“ is right).</text>
</item>
</item>
<item>
<id>d71ec208-7657-4914-a00e-d9008c8d7138</id>
<type>recommendation</type>
<text>For globally unique identifiers, the URI format is recommended.</text>
<item>
<id>a60448ba-451d-4176-a3ef-fa537698dbc2</id>
<type>information</type>
<text>Besides the uniqueness, the most important feature of it is immutability and stability.</text>
</item>
<item>
<id>fea4993c-7405-4755-b66a-68cd1f57637b</id>
<type>information</type>
<text>Identifiers can be derived from an internet domain, an OID or PEN number etc.</text>
</item>
<item>
<id>eb3bb5fa-a99e-4ffa-b27f-2f024e43f3eb</id>
<type>recommendation</type>
<text>When deriving from internet domains use the tag URI scheme to create timeless identifiers that are not affected by the changes in domain ownership.</text>
</item>
<item>
<id>aa0554cf-0cac-47c2-8075-54a84cb20e74</id>
<type>recommendation</type>
<text>Use randomly generated identifiers when full decentralization is desired. These identifiers might be just random (e.g. UUID version 4) or derived from a public key (e.g. an SSH key or a Tor address) or a hash of a (secret) data.</text>
<note>When public key or a hash of secret data is used, then ownership of the name or namespace can be reliably proved.</note>
<note>Random identifiers must be picked from a sufficiently large space where we can assume that collisions are effectively eliminated.</note>
</item>
</item>
</chapter>
<chapter>
<name>Interfaces, formats and protocols</name>
<id>d34ce339-197c-44ee-9e5c-6d7e212f8c10</id>
<item>
<id>be4c72d1-c494-4c44-aeb4-c5847f5a3524</id>
<type>recommendation</type>
<text>Open standards (protocols, formats) should be used if they exist.</text>
</item>
<item>
<id>b2202690-8a6c-467f-a2b1-b154f470aa77</id>
<type>requirement</type>
<text>Already existing open protocol/format must not be modified or extended in a way which effectively creates a proprietary protocol/format.</text>
</item>
<item>
<id>dd206223-9525-4229-be2b-84b07c2b8244</id>
<type>information</type>
<text>New open standards (specifications) should be defined and published if needed.</text>
<text>Such standards must be semantically versioned.</text>
</item>
<item>
<id>d341b78e-15b9-4077-8b48-9e54c93391ac</id>
<type>recommendation</type>
<text>And they should be written in machine readable format (e.g. WSDL, ASN.1, XML Schema, Diameter dictionary, D-Bus) or at least formal language (Backus–Naur Form, EBNF etc.)</text>
</item>
<item>
<id>d61b3e31-bb9f-4333-87c8-9fb32f33a49d</id>
<type>recommendation</type>
<text>Also configuration should have machine readable description and the user should be able to test it by executing a command (validator).</text>
</item>
</chapter>
<chapter>
<name>Modular architecture and extensibility</name>
<id>c56e7e86-e480-4a5d-8a47-ab155dcd59b1</id>
<item>
<id>e50424e8-94f3-48aa-bf01-0ba984eb2349</id>
<type>requirement</type>
<text>Larger and multi-purpose software must be divided into smaller modules.</text>
<link>
<url>http://wiki.apidesign.org/wiki/NetBeans_Runtime_Container#Modularity_Manifesto</url>
<type>compatible</type>
<title>Modularity Manifesto</title>
<quotation>Splitting application into modules can greatly improve the design. It is not hard to guess that a monolithic piece of code where every line in any source code can access any other source file is much more interconnected and unreadable than a code which introduces many modules and allows such uncontrolled calls to happen just inside the module.</quotation>
<quotation>Modularity would give systems clearer design, control of dependencies between modules and give developers more flexibility in maintanence. Think about it when starting any new project - nevertheless big it is, do it in modular way. It is going to be big plus for the architecture of the whole application as it grows from its child days.</quotation>
</link>
</item>
<item>
<id>e752efae-75c9-4620-aa14-65c4949a3609</id>
<type>requirement</type>
<text>The modules must have defined dependencies (less = better).</text>
<note>Dependencies needed to write an extension/module (i.e. header files, API classes/interfaces) should be as small as possible (do not require large codebase to write a mere plug-in).</note>
<note>The required dependency should contain just interfaces (method/function signatures) and data structures but no implementation (executable code).</note>
</item>
<item>
<id>e9988ed0-d686-41a0-9f1e-3243ac5235d5</id>
<type>recommendation</type>
<text>Particular modules should be compilable and executable (installable) independently.</text>
<text>It should not be necessary to recompile the core and other modules if only one module is changed.</text>
<note>Whole system should be compilable (buildable) with only selected modules – must not require compilation or even distribution of all modules, if they are not necessary.</note>
<note>The goal is to reduce the complexity and the code footprint that comes into the play if the user needs only certain features.</note>
</item>
<!--
TODO: the package name and the version number should serve as a unique identifier for a set of features.
If there are any build-time options/parameters, they could tune the intarnal details of the package/module, or choose some alternative dependency (like cryptography library A vs. cryptography library B),
but the public interface and publicly provided features (the contract) should stay unchanged.
-->
<item>
<id>a7bc51ba-9832-4f75-983c-e75dc0801113</id>
<type>information</type>
<text>Another good ways to extend and customize the software are:</text>
<text>configuration (XML, INI, RegExp, SQL, XSLT, XPath etc.) and</text>
<text>scripting (Scheme, Bash, Python, Lua, ECMA Script etc.)</text>
<link>
<url>https://www.gnu.org/prep/standards/standards.html#Source-Language</url>
<type>compatible</type>
<title>GNU Coding Standards: Which Languages to Use</title>
<quotation>The more GNU components use Guile and Scheme, the more users are able to extend and combine them</quotation>
<quotation>Many programs are designed to be extensible: they include an interpreter for a language that is higher level than C. Often much of the program is written in that language, too. The Emacs editor pioneered this technique.</quotation>
<quotation>The standard extensibility interpreter for GNU software is Guile, which implements the language Scheme (an especially clean and simple dialect of Lisp).</quotation>
</link>
<link>
<url>https://www.gnu.org/software/guile/</url>
<type>related</type>
<title>GNU Guile</title>
<description>GNU implementation of the Scheme language (which is a dialect of Lisp).</description>
</link>
</item>
</chapter>
<chapter>
<name>Testable</name>
<id>a0376231-d53e-45fd-826f-47148721de3d</id>
<item>
<id>d99a69a5-2572-4517-a775-b69d036ad79c</id>
<type>information</type>
<text>Tests verify the compliance of the implementation with the documentation or specification.</text>
</item>
<!-- TODO: the software should be structured in a way which facilitates writing tests – e.g. separate the UI from the core and allow calling the core functions from the tests – which has also other positive side effects -->
<item>
<id>d95dc118-7473-4f18-8b9e-35830a87b269</id>
<type>recommendation</type>
<text>There should be automated build-time complex tests for the package. The test feeds the program with sample input and verifies expected output.</text>
</item>
<item>
<id>a9f6725d-ddf1-41ee-96b4-15f3b851cb50</id>
<type>recommendation</type>
<text>There should be also automated runtime/postinstall tests – in order to verify that software was installed properly, all required dependencies are met and basic function is guaranteed – the program should report problem during its start (as a warning if it is not fatal), instead of unexpected failures during operation.</text>
</item>
<item>
<id>d610c04b-cc44-48c7-b069-f41b90bdef0f</id>
<type>recommendation</type>
<text>Unit tests are recommended for code parts that are internally complex (algorithms, important business logic) and have simple interfaces.</text>
</item>
<item>
<id>e85baeda-8fcb-42d1-bb53-d7386a941ae7</id>
<type>recommendation</type>
<text>Each external interface should contain procedure/function that does nothing important or heavy, is idempotent and returns simple response which proves that the interface (connection) is working (e.g. echo, print version, status or current time). If authentication and authorization mechanisms are present, there should be one procedure/function callable anonymously and one that requires authorization.</text>
</item>
</chapter>
<chapter>
<name>Safe code and sustainability</name>
<id>f3afbaf2-0933-43d2-aed0-8dc568b9429f</id>
<item>
<id>a96206c9-3e69-483d-b575-6bab9dec4a30</id>
<type>requirement</type>
<text>Correctness, safety and readability is preferred to performance.</text>
</item>
<item>
<id>d8eba0dd-4305-44b9-80ea-4c38b6dfa633</id>
<type>recommendation</type>
<text>Strong data typing should be used, preconditions and possible exceptions should be declared in the interface and they are part of the contract.</text>
</item>
<item>
<id>ebea0c16-f820-444d-a73c-3054ca6a38c8</id>
<type>requirement</type>
<text>Data structures must be known and well documented. Do not use e.g. undocumented map keys or properties.</text>
</item>
<item>
<id>e24e600e-6542-4664-8cf0-2d8c6feb6c13</id>
<type>recommendation</type>
<text>Code, comments and specification should be written in the same natural language.</text>
<link>
<url>https://www.gnu.org/prep/standards/standards.html#Comments</url>
<type>related</type>
<title>GNU Coding Standards: Commenting Your Work</title>
<quotation>Please write the comments in a GNU program in English, because English is the one language that nearly all programmers in all countries can read.</quotation>
</link>
</item>
<item>
<id>fa92aa33-a69f-43b8-9051-9bfdcd3d293f</id>
<type>recommendation</type>
<text>There should be a dictionary of used terms, so whole team and also users and customers will speak the same language.</text>
</item>
<item>
<id>b9345a0e-c672-45d3-b93b-8d0fb4ece8b3</id>
<type>recommendation</type>
<text>Fail fast – errors in the code should be reported during build time or at least on first execution – do not silently continue if given error would lead to failure later in another part of the code – bad weak coupling leads to difficult debugging.</text>
<note>Avoid silent failures: e.g. if the computer runs out of disk space and the text editor is unable to save the file, it should immediately report error and allow user to choose different destination instead of silently failing and leaving the file empty.</note>
</item>
</chapter>
<chapter>
<name>Small code footprint</name>
<id>ba8fbf3a-9254-4dd8-bb77-b0cd4907c6aa</id>
<item>
<id>f5389468-2f8a-43c8-884a-8df6bc844453</id>
<type>recommendation</type>
<text>Less LOC (or cyclomatic complexity) = better.</text>
<note>Cyclomatic complexity is much better measure of the complexity than LOC (lines of code). But usually it is much easier to simply count lines and we can use it as a approximation.</note>
</item>
<item>
<id>b6b6c838-be6d-43d5-9f99-2098fa217c54</id>
<type>recommendation</type>
<text>Boilerplate and unused code should be reduced. Adequately high-level programming language or framework should be used.</text>
</item>
<item>
<id>b07fe0f0-2be7-4c1c-9b19-b671269c5e58</id>
<type>recommendation</type>
<text>Code generators should be used (during the build process, not to generate code to be manually edited and versioned).</text>
<link>
<url>https://www.gnu.org/prep/standards/standards.html#Releases</url>
<type>compatible</type>
<title>GNU Coding Standards: Making Releases</title>
<quotation>Building and installing the program should never modify any of the files contained in the distribution. This means that all the files that form part of the program in any way must be classified into source files and non-source files. Source files are written by humans and never changed automatically; non-source files are produced from source files by programs under the control of the Makefile.</quotation>
</link>
</item>
</chapter>
<chapter>
<name>Sane dependencies</name>
<id>afd8f6c7-8dac-4a83-a101-64f017ec7ada</id>
<item>
<id>c2d5a677-a721-40e3-b560-73afe76fe2b0</id>
<type>recommendation</type>
<text>Avoid NIH syndrome and reuse code but also avoid dependency hell.</text>
<text>Complexity is defined by the complexity of the program itself + complexity of its dependencies.</text>
</item>
<item>
<id>d214987c-881c-450b-8544-82141866f541</id>
<type>requirement</type>
<text>Know your dependencies, know why they are required.</text>
</item>
<item>
<id>cbeb9a6b-7b64-4452-8caf-246c082a853d</id>
<type>recommendation</type>
<text>Depend on small and useful libraries – not on bulky application packages or libraries with large transitive dependencies.</text>
</item>
<item>
<id>cbaf55be-8ffb-4109-9c83-083d1b3e793a</id>
<type>requirement</type>
<text>If dependency on bulky application package is inevitable, add a layer of abstraction – create a generic interface and connector and allow others to replace the bulky package with their own sane implementation.</text>
</item>
<item>
<id>d7655989-a5e4-4123-9147-3782fc05a5ee</id>
<type>recommendation</type>
<text>Complexity caused by helper tools should be also reduced:</text>
<item>
<id>a5307bc9-36ed-4d83-963a-30c5c67613aa</id>
<type>recommendation</type>
<text>If you e.g. use Bash and Perl during the build process, do not add also Python dependency, write it in Perl – or use Python instead of Perl.</text>
</item>
<item>
<id>b0237d84-7068-4b2b-bc28-ce5e0a0061e4</id>
<type>recommendation</type>
<text>Or if you use Java as your main language, consider not using Python/Perl for scripting and use some JVM language for it.</text>
</item>
</item>
<item>
<id>a0f42ec9-5032-4f6d-a50a-4b7bddde77f0</id>
<type>requirement</type>
<text>If possible, always depend on abstract interfaces, not on particular implementations.</text>
</item>
<item>
<id>c5974dcd-4855-40c5-ad22-894c128ca1dc</id>
<type>recommendation</type>
<text>From the whole system point-of-view, Bootstrappable builds should be taken into account.</text>
<link>
<url>http://bootstrappable.org/</url>
<type>related</type>
<title>Bootstrappable builds</title>
</link>
</item>
</chapter>
<chapter>
<name>Easily auditable</name>
<id>fb0c484b-d97a-4cb4-9b8f-04d386ef0f54</id>
<item>
<id>aeef6a5c-bafc-4fcf-9b21-5829e8a44c5e</id>
<type>recommendation</type>
<text>Small code footprint and sane dependencies make it easier to do security audit.</text>
</item>
<item>
<id>ab69d352-da68-40c2-a3e1-a8fd5c41ad0a</id>
<type>recommendation</type>
<text>Ungrounded refactoring and reformatting should be avoided – they make mess and noise in the version control system and impede the audit.</text>
<note>This rule is classified as a recommendation only because of the fact that past mistakes usually can not be reverted, which would disqualify the software forever. However it should be normally considered to be a requirement.</note>
</item>
<item>
<id>e4db77b8-f145-4e43-bf8b-eb775b9352c8</id>
<type>recommendation</type>
<text>Refactoring/reformatting changesets should be separated from substantive changes.</text>
</item>
</chapter>
<chapter>
<name>Reproducible builds</name>
<id>da6436f7-c352-4d52-915b-02d0d1880e40</id>
<item>
<id>e5154815-eeae-4664-8883-a29a64eea325</id>
<type>recommendation</type>
<text>Builds should be reproducible i.e. same code/version should lead to the same binary package.</text>
</item>
<item>
<id>a3b0c164-4dde-4e33-b3be-5478d2a187e2</id>
<type>requirement</type>
<text>If they are not reproducible, it should be documented, why and how build products might differ, and there should be plan/task to make builds reproducible.</text>
</item>
</chapter>
<chapter>
<name>Trustworthy packages and sources</name>
<id>e7ded437-aaa2-475a-9754-0b2d89394b24</id>
<item>
<id>a0d9322c-7d2b-4632-b543-7e0d75bb5f0b</id>
<type>requirement</type>
<text>Every released version (binary or source) must be cryptographically signed by the authors (GnuPG/OpenPGP is strongly recommended).</text>
</item>
<item>
<id>feb97ec0-c35c-49b8-b455-517a929b4a84</id>
<type>recommendation</type>
<text>There should be also checksums/hashes for every released package.</text>
</item>
<item>
<id>ff33e209-0460-4a43-997f-d6b32b73997b</id>
<type>recommendation</type>
<text>If HTTP is supported, HTTPS should also be – the attacker/eavesdropper should not even know what software/package/update is downloaded by the user.</text>
</item>
<item>
<id>c1f83b3a-e564-4483-91de-9c08723efd13</id>
<type>requirement</type>
<text>The attacker must not be able to suppress updates – the program (usually a package management system) must not be silent in such case and must warn the user that something possibly nasty and dangerous is happening.</text>
<note>This is relevant mostly to distributions and package managers which should be used for updates (the application should not update itself).</note>
</item>
<item>
<id>c6a755c9-a54e-4ffb-8f70-bfbd851b93c5</id>
<type>recommendation</type>
<text>Releases should be downloadable also (or exclusively) over BitTorrent or other P2P network.</text>
</item>
<item>
<id>f9275c3c-2b09-4aec-ac28-76ff827d52ce</id>
<type>requirement</type>
<text>Source code repository must be accessible through a secure and encrypted connection.</text>
<link>
<url>https://www.gnu.org/software/repo-criteria.html</url>
<type>compatible</type>
<title>GNU ethical repository criteria</title>
<quotation>Support HTTPS properly and securely, including the site's certificates.</quotation>
</link>
</item>
</chapter>
<chapter>
<name>Network interactions</name>
<id>d3edb71b-8668-4290-a669-19694956e3aa</id>
<item>
<id>c967092e-09e9-4c68-90bf-aa8cb441f7dc</id>
<type>requirement</type>
<text>Network connectivity must not be required during build – the build must be possible completely offline.</text>
<text>All dependencies must be downloadable and documented including secure hashes or preferably cryptographic signatures.</text>
<note>It should be straightforward to collect all dependencies transfer them in space or time and build the software (e.g. on another computer or in next decade).</note>
</item>
<item>
<id>b5515d33-1531-4361-8baf-a99ca461e763</id>
<type>requirement</type>
<text>If dependencies are optionally automatically downloaded during or before build, the packaging system must cryptographically verify that they are undamaged.</text>
<note>So it should not be possible to endanger the user by MITM attack.</note>
</item>
<item>
<id>f700413a-fde1-460c-8633-76985e98007c</id>
<type>requirement</type>
<text>Avoid unwanted network interactions during runtime.</text>
<text>There must be no „call home“ or update-checks without user's explicit consent.</text>
</item>
<item>
<id>f55c2ebd-c3ba-44f7-ae92-06f679780ec7</id>
<type>requirement</type>
<text>If any network connection is used, it must be by default cryptographically secured against MITM attacks.</text>
<note>It might be possible to disable the encryption on user's explicit request (in order to get better performance on a trusted private network).</note>
<note>For debugging and testing purposes it is better to allow dumping the private/session keys rather than disabling the encryption.</note>
<note>In special cases (like small microcontrollers without cryptographic capability connected to a trusted private network), it is possible to have no encryption at all, but the user must be properly informed about this issue and potential risks.</note>
</item>
</chapter>
<chapter>
<name>Internationalization and localization</name>
<id>fa655b7c-f22d-4b98-ab7b-c0d0f608aad8</id>
<item>
<id>e56aad13-f68e-47ea-8b88-65fee6b5331a</id>
<type>requirement</type>
<text>Any software with nontrivial user interface must be internationalized</text>
<text>which means that it allows localization (translation of the UI to national languages and other customization to national conventions).</text>
<link>
<url>https://en.wikipedia.org/wiki/Internationalization_and_localization</url>
<type>related</type>
<title>Internationalization and localization</title>
<quotation>Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. Localization is the process of adapting internationalized software for a specific region or language by translating text and adding locale-specific components.</quotation>
</link>
</item>
<item>
<id>ad2f572b-497b-4523-b435-f9752fd1518a</id>
<type>recommendation</type>
<text>It should be possible to localize the user interface independently from the original author by creating an additionally installable language pack.</text>
</item>
<item>
<id>c3827486-6bf5-45c0-9a6d-61ad659d8ba1</id>
<type>recommendation</type>
<text>GNU Gettext or other standard framework (like Java resource bundles) should be used.</text>
<link>
<url>https://www.gnu.org/prep/standards/standards.html#Internationalization</url>
<type>compatible</type>
<title>GNU Coding Standards: Internationalization</title>
<quotation>GNU has a library called GNU gettext that makes it easy to translate the messages in a program into various languages. You should use this library in every program.</quotation>
</link>
</item>
<item>
<id>a57f4fc8-1f64-46e2-a91d-3a598c37f2e9</id>
<type>recommendation</type>
<text>Error messages should have assigned unique error codes, so it is possible to find relevant information regardless the current locale.</text>
</item>
<!-- GEC is recommended for such unique error identifiers -->
<item>
<id>eba92867-5c1b-45b6-943a-a3fa6ea67e38</id>
<type>requirement</type>
<text>Data formats and protocols must be language/locale independent.</text>
<item>
<id>fee73fee-4940-47ac-84b6-15646f5f61c7</id>
<type>requirement</type>
<text>e.g. use decimal point instead of comma and no thousand separators for numbers, use standardized date formats</text>
</item>
<item>
<id>f1a00487-ed89-4443-99b5-63ab4c635690</id>
<type>requirement</type>
<text>in general: everything that is expected to be machine-readable or machine-generated must be independent from the current locale</text>
</item>
</item>
<item>
<id>e6603e06-0b2c-439e-82ce-45f9744b2ef8</id>
<type>requirement</type>
<text>Character encoding:</text>
<item>
<id>abd42a7f-bd4b-4034-98ee-85a33094b5c1</id>
<type>recommendation</type>
<!-- TODO: requirement? -->
<text>The software should always be aware of it and do not just blindly use current platform's default.</text>
<note>The other side might run on different platform with different default. Or a file might be opened later on different platform.</note>
</item>
<item>
<id>abd48eae-d287-4729-80ee-52dd018b0ba7</id>
<type>requirement</type>
<text>If given software/format/protocol has some default encoding, it must be clearly defined in its specification and this default must not be changed without changing the major version number.</text>
</item>
<item>
<id>c9f4d9f4-f959-48ad-bc68-6720dd4596e3</id>
<type>requirement</type>
<text>If there is no default, the encoding must be specified in the metadata attached (e.g. protocol headers, extended attributes on filesystem) to the actual data or at least at the beginning of the data (like declaration in the XML format).</text>
</item>
</item>
<item>
<id>ce45c382-6ec5-41e8-869a-a0e758621b13</id>
<type>recommendation</type>
<!-- TODO: requirement? -->
<text>The metric system should be used as default.</text>
</item>
</chapter>
<chapter>
<name>Communication with users and developers</name>
<id>a931dcbb-8043-4e21-838f-8e8122bb8af3</id>
<item>
<id>fff90688-907e-48eb-a48a-2ae6d6b42f0a</id>
<type>recommendation</type>
<text>Following information should be provided in RSS/Atom or other machine readable format:</text>
<text>announcements (security, new versions, infrastructure outage),</text>
<text>blog posts, tutorials</text>
<text>and AFK events (e.g. conferences, meetings or hackatons).</text>
<note>for calendar data iCal format is strongly recommended</note>
</item>
<item>
<id>e8b18e02-d7b2-4584-8eee-dbaf823f6800</id>
<type>recommendation</type>
<text>A mailing list (e-mail conference) or other equivalently open and decentralized technology should be used for the many-to-many communication.</text>
<note>Having an „old school“ mailing list is not mandatory – it might be e.g. a P2P distributed technology or some self-hosted forum.</note>
<link>
<url>https://www.gnu.org/prep/maintain/maintain.html#Standard-Mailing-Lists</url>
<type>related</type>
<title>Information for Maintainers of GNU Software: Standard Mailing Lists</title>
</link>
</item>
<item>
<id>e746eb5b-8d8b-4ec8-9315-a311f35e156a</id>
<type>requirement</type>
<text>Users must not be pushed to register at proprietary social networks (at particular providers of such services).</text>
<text>Users without such account must not be disadvantaged – use open and decentralized networks/protocols instead.</text>
<link>
<url>https://www.gnu.org/prep/maintain/maintain.html#Ethical-and-Philosophical-Consideration</url>
<type>compatible</type>
<title>Information for Maintainers of GNU Software: Ethical and Philosophical Consideration</title>
<quotation>Please don’t host discussions about your package in a service that requires nonfree software. For instance, Google+ “communities” require running a nonfree JavaScript program to post a message, so they can’t be used in the Free World. Google Groups has the same problem. To host discussions there would be excluding people who live by free software principles.</quotation>
<quotation>Of course, you can’t order people not to use such services to talk with each other. What you can do is not legitimize them, and use your influence to lead people away from them. For instance, where you say where to have discussions related to the program, don’t list such a place.</quotation>
</link>
<link>
<url>https://www.gnu.org/software/repo-criteria.html</url>
<type>related</type>
<title>GNU ethical repository criteria</title>
<quotation>The site's terms of service contain no odious conditions.</quotation>
</link>
</item>
<item>
<id>ff537045-819e-4dec-a020-d2c9f2c3292b</id>
<type>recommendation</type>
<text>There should be a second-level internet domain for the project or its team.</text>
<note>But do not buy an internet domain if you are not prepared to mainain it for decades – rather use third level domain under some reliable second level domain maintained by a credible group or person – think of that every expired domain helps spammers and scammers and hurts the users.</note>
</item>
<item>
<id>a1141312-5177-4d68-bb14-fce952d542c3</id>
<type>recommendation</type>
<text>URLs should be as stable as possible – accessible in next decade.</text>
<note>Do not break old links, set up redirections if needed.</note>
</item>
<item>
<id>c5b6d3d7-2f1f-4371-acfa-d6af1588c2cb</id>
<type>requirement</type>
<text>The website must be independent and must contain everything needed – any content (JavaScripts, CSS, fonts, images etc.) downloaded from other domains must not be required to browse/use the website.</text>
<note>Embedded content from the third-party servers causes leaks of sensitive data (tracking of the users) and also denies decentralized nature of the internet.</note>
</item>
<item>
<id>d5fbcc9e-a12c-44ce-909b-f514a579ab7e</id>
<type>requirement</type>
<text>JavaScript or other code executed on client computers must be also free software with properly declared license.</text>
<link>
<url>https://www.gnu.org/philosophy/javascript-trap.html</url>
<type>compatible</type>
<title>The JavaScript Trap</title>
<quotation>When the site transmits a program to the user, it is not enough for the program to be written in a documented and unencumbered language; that program must be free, too. “Transmits only free programs to the user” must become part of the criterion for an ethical web site.</quotation>
</link>
<link>
<url>https://www.gnu.org/software/librejs/</url>
<type>related</type>
<title>GNU LibreJS</title>
</link>
</item>
<item>
<id>e02c3fba-93f3-4f16-bd23-f49a203e40bc</id>
<type>recommendation</type>
<text>The website should not require a modern complex browser for basic tasks like reading the documentation, downloading a release or submitting a bug report.</text>
<text>Such tasks should be feasible even with simple text browsers (e.g. Lynx or Links2).</text>
<note>Modern browsers consists of 20 or 25 millions lines of code. Requiring such complex software for basic tasks is not reasonable.</note>
<link>
<url>https://www.gnu.org/prep/maintain/maintain.html#Freedom-for-Web-Pages</url>
<type>related</type>
<title>Information for Maintainers of GNU Software: Freedom for Web Pages</title>
<quotation>Please make sure it is possible to use the web site fully using the Lynx browser, and with the IceCat browser with LibreJS enabled.</quotation>
</link>
</item>
<item>
<id>c89e8699-574c-4b28-9f65-6284d6051f68</id>
<type>requirement</type>
<text>There must be a crpyptographically secured (GnuPG/OpenPGP or X.509) e-mail address or a secure web form for receiving security vulnerabilities reports.</text>
<note>Particular authors should publish their public keys.</note>
<note>Every security incident must be clearly documented and investigated – do not obscure it.</note>
</item>
<item>
<id>fed07648-106a-4b7c-9026-509c82109448</id>
<type>requirement</type>
<text>Source code repository (versioning system) must be public. Do not publish just source code snapshots of released versions.</text>
<note>The purpose of this rule is that anybody can study who, when and why updated, created or deleted which portion of the code.</note>
<link>
<url>https://www.gnu.org/prep/maintain/maintain.html#Old-Versions</url>
<type>related</type>
<title>Information for Maintainers of GNU Software: Recording Old Versions</title>
<quotation>The history of previous revisions and log entries is very important for future maintainers of the package, so even if you do not make it publicly accessible, be careful not to put anything in the repository or change log that you would not want to hand over to another maintainer some day.</quotation>
</link>
</item>
</chapter>
<chapter>
<name>Accepting contributions</name>
<id>eae0f528-a5ce-4809-a25d-9f9ab6311f3d</id>
<item>
<id>efae935b-fef1-4bbd-a2c5-e12048524e35</id>
<type>recommendation</type>
<text>Good quality code contributions with appropriate copyright and patent licenses or assignments should be accepted from anyone.</text>
</item>
<item>
<id>ea429f77-44db-4eb4-9925-0d28f9abf47a</id>
<type>information</type>
<text>The „good quality code“ is defined by the project and might involve code style, idioms, design patterns, software architecture, required tests, documentation etc.</text>
<link>
<url>https://www.gnu.org/prep/maintain/maintain.html#Clean-Ups</url>
<type>compatible</type>
<title>Information for Maintainers of GNU Software: Cleaning Up Changes</title>
<quotation>Don’t feel obligated to include every change that someone asks you to include. You must judge which changes are improvements—partly based on what you think the users will like, and partly based on your own judgment of what is better. If you think a change is not good, you should reject it.</quotation>
</link>
</item>
<item>
<id>b0022cea-4caf-4663-ae24-5fc5da31333b</id>
<type>recommendation</type>
<text>Such requirements and rules should be available to the contributor before he begins.</text>
<text>However (especially smaller) projects might communicate such code quality requirements and provide consultations and guidance during the contribution.</text>
<link>
<url>https://www.gnu.org/prep/standards/</url>
<type>related</type>
<title>GNU coding standards</title>
<description>example of such rules and guidelines</description>
</link>
</item>
<item>
<id>ea4a8d23-b2df-42eb-84ae-7687d35838c8</id>
<type>requirement</type>
<text>In order to contribute, it must not be required:</text>
<note>The term „contribution“ includes not only source code (patch) but also bugreports, feature specifications, documentation, assets (graphics, music etc.) or similar artifacts.</note>
<item>
<id>da7dabf6-f2d8-43bc-8121-6e4527eaa691</id>
<type>requirement</type>
<text>to have an account on any particular third party service like particular e-mail or hosting provider,</text>
</item>
<item>
<id>dfd6a77f-7c4a-430a-8199-8ea71ec7ee8c</id>
<type>requirement</type>
<text>to sign a contract (which includes accepting „Terms and conditions“) with any particular third party (e.g. source code hosting provider),</text>
</item>
<item>
<id>af6a589f-d419-483f-b7b2-07b6e9da3924</id>
<type>requirement</type>
<text>to sign any political, religious or other proclamation or agree with it.</text>
<link>
<url>https://www.gnu.org/prep/maintain/maintain.html#Other-Politics</url>
<type>compatible</type>
<title>Information for Maintainers of GNU Software: Other Politics</title>
<quotation>A GNU package should not seriously advocate any other political causes. Not that the GNU Project opposes those other causes. Rather, it is neutral on them, and GNU packages should be neutral too. </quotation>
</link>
<link>
<url>https://www.gnu.org/philosophy/kind-communication.html</url>
<type>compatible</type>
<title>GNU Kind Communications Guidelines</title>
<quotation>Please don't raise unrelated political issues in GNU Project discussions, because they are off-topic. The only political positions that the GNU Project endorses are (1) that users should have control of their own computing (for instance, through free software) and (2) supporting basic human rights in computing. We don't require you as a contributor to agree with these two points, but you do need to accept that our decisions will be based on them.</quotation>
</link>
</item>
</item>
<item>
<id>b4319392-8d6a-4f07-8a94-7ae2ed97c787</id>
<type>information</type>
<text>In order to contribute, it might be required:</text>
<item>
<id>f9f52f2f-b057-4a2f-9131-682fac54c853</id>
<type>information</type>
<text>to have an e-mail address (but not at particular domain),</text>
</item>
<item>
<id>ef9e64cc-90b0-4002-ab5a-a1135332c7fe</id>
<type>information</type>
<text>or use similar decentralized technology which has open standard and free software implementations,</text>
</item>
<item>
<id>d7a94eba-efd6-471f-9c32-6ee9d3b8ab29</id>
<type>information</type>
<text>to assign the copyright to the project and grant a free license for all patents relevant to the contribution.</text>
<link>
<url>https://www.gnu.org/prep/maintain/maintain.html#Copyright-Papers</url>
<type>related</type>
<title>Information for Maintainers of GNU Software: Copyright Papers</title>
<quotation>When copyright is assigned to the FSF, the FSF can act to stop GPL violations about the package. Otherwise, legal actions are up to the author(s).</quotation>
</link>
</item>
</item>
<item>
<id>e394c792-8294-4f15-a356-89cd0a7aa255</id>
<type>recommendation</type>
<!-- TODO: requirement? -->
<text>The project should record all accepted contributions and maintain a public list of all authors/contributors.</text>
<link>
<url>https://www.gnu.org/prep/maintain/maintain.html#Recording-Contributors</url>
<type>compatible</type>
<title>Information for Maintainers of GNU Software: Recording Contributors</title>
<quotation>Keep correct records of which portions were written by whom.</quotation>
</link>
</item>
<item>
<id>b5a128a2-31d9-49df-890c-59a770f7afa9</id>
<type>requirement</type>
<text>The contributor must not lose the right to use or distribute the contributed code under any license (of his choice).</text>
</item>
</chapter>
</manifesto>