[Discussion] Non-free software points of entry

[Uptorn]

Keeping one's sources.list clear of non-free repositories is no guarantee that one's system will remain free of proprietary software. I have often avoided third party package installers for this reason. If it doesn't come from a Debian mirror, with deb-src available, or if I haven't compiled it from source myself, then I want nothing to do with it. Here are some common vectors:

• Mozilla addons (AMO)
• Other Firefox bits
• Webpage-supplied javascript
• Python Pip
• Ruby Gems

• Rust cargo crates?
• Gnome extensions?
• Kernel modules?
• (Many more that are not at the forefront of my memory)

Some of these are grey area. For example, do we count projects which simply forgot to supply a license as proprietary? As in the Gem example, do accidental inclusions of proprietary software merit distrusting the repo? Interpreted languages, by design must supply source code, so it is only proprietary in legality. But what of interpreted code that is minified or obfuscated in some way? Or what of software that is properly libre but still is textbook malware designed with intent to abuse those who run it?

[lindi]

Fun fact: Debian does include software without source code. Check the game beneath-a-steel-sky. As far as I am aware, even the original developers have lost the source code.

[jmgibson1981]

With all due respect while Debian does the best it can to keep free software and non free separate there is entirely too many ways stuff can get in. They can't catch every single one of them. The only way you can get what you seem to want (by the essence of the thread) is to build your own from LFS / (Gentoo?). Only then will you be 100% aware and able to verify everything that goes in. Unless you do something you are entirely in control of then you can only hope for the best.

[Uptorn]

With all due respect while Debian does the best it can to keep free software and non free separate there is entirely too many ways stuff can get in. They can't catch every single one of them. The only way you can get what you seem to want (by the essence of the thread) is to build your own from LFS / (Gentoo?). Only then will you be 100% aware and able to verify everything that goes in. Unless you do something you are entirely in control of then you can only hope for the best.

Debian and other distributions utilize a build system. If I'm not misunderstanding, each package is compiled from source for each architecture for which it builds successfully, the resulting binaries & packages then distributed via the repository system. There are many reasons that a package may fail to build, one of them being unavailable source files.

I understand that you are probably aware of this, and are simply referring to the licensing. So I think there is a distinction to be made programs which are functionally free (the source is made available) and programs which are legally free via appropriate copyleft licensing.

I only really care about the former. If a package has accidentally included some font or asset which is technically under a proprietary license, as long as it builds and runs from source I'm happy (since I will be using said program privately and not redistributing it (that would then be Debian's problem) )

[xuhdev]

I'm not sure what you would like to focus discussion on. You listed some gray areas. IMO, the criteria should be similar to the definition of free software by FSF:

the users have the freedom to run, copy, distribute, study, change and improve the software.

Unlike FSF, I do not see this definition as clearly cut; I see this definition as referring to an ideal 100% free software. A close example is a piece of software in the public domain. The other extreme is 100% non-free, in which the users do not have the freedom to exercise the said actions. A close example is a piece of software with only a blob which the author holds all rights and does not grant any permissions. Some software would fall in the middle, such as a software with source code freely available for copying and studying but requires permission to run.

No software is 100% free or non-free; it is always a matter of degree. For example, consider a well-documented MIT-licensed software with source code publicly available. While it is very close to satisfying the definition, it still hinder user's ability to distribute by requiring attribution. This hindrance can become practical when the number of dependencies is large. A real-world example of such hindrance relates to the NPM system. A browser project often depends on a huge number of NPM packages, but eventually it needs to deliver a bundle including all of the dependencies to the browser. It is not always an easy task to attribute the authors of all dependencies properly according to a license that requires attribution. I've also written a blog post on the practical side of this matter.

Applying this principle to your gray area examples, some of them would become clear:

• Forgot to include a license: This might be OK in some jurisdictions since there might be an implied license. Depending on the jurisdiction, it can range anywhere between 0% to 100% free.

• Accidental inclusions of proprietary software: Depend on how free or proprietary the included software is.

• Minified or obfuscated interpreted code: Assuming the user is permitted to run, copy, distribute. While technically a user can still study, change, and improve, the practicality has been greatly hindered by the obfuscation. Therefore, this would be partly free (somewhere in the middle between 0% and 100% free).

• Properly libre but with intent to abuse users: I don't know what "properly libre" means. For the sake of argument, let's say it means the same thing as the free software above. By definition, it is 100% free. However, because users can study and change the software, soon a non-malicious fork of the software would surface. VSCode and VSCodium may be a real-world example along this line, while VSCode is not 100% free and not everyone sees it (mostly the telemetry part) as malicious.