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:
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:
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.the users have the freedom to run, copy, distribute, study, change and improve the software.
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.
Statistics: Posted by xuhdev — 2024-04-29 03:58