Re: Suggestions for FSD Documentation Regarding Adding New Pages

[Adonay Felipe Nogueira]

Hi all,

Regarding the lack of tools to aid on the review/evaluation, I also felt 
the same some years ago. Often the tools suggested in some of the pages 
required installing a software that wasn't even updated when downloading 
from the system distribution's repository that I used. At one point I 
made a script aid to ease some of the review process [1].

My script aid generates a CSV that can be opened with LibreOffice. It's 
been a while since my last contribution, but the script aid still exists 
at [1], which in turn is linked from the list of scripts to manage the 
directory [2], and that is referenced by the page about the directory's 
workflow and in turn is referred by the "Administration" section of the 
Participate page [3].

I know that finding the above script normally requires lots of clicks, 
but given that not all directory contributors are reviewers/evaluators, 
then I think that section is mostly fine.

Particularly, I'm not in favor of approving entries just because they 
have a given license. This may create a scenario where a distribution 
package may have metadata suggesting that the contents of such package 
are supposedly under a free/libre software license, but the *only* usage 
and function of that package [5] is to download a proprietary software 
for use as it is or the package itself has that piece of malware, and in 
the last case the metadata is just there to please automated license 
checkers. I know of one package that has metadata like so, but as far as 
I know it is not in any free/libre system distribution repository.

As for how to get a list of dependencies, I may have some hints, but 
they may not be ready-to-use tools:

a) The README, and general documentation regarding the source files are 
mostly your friend.

b) You'll often face source files using a minifier or obfuscator, which 
function somewhat like compilers. I know little on whether these are any 
good, but sticking to the point, I advise you to disarm or understand 
how those work before reading into other points. Try to catch the 
reviewed source code's configuration used for the minifier/obfuscator, 
which is mostly like a configuration file. For example, disregarding the 
software freedom status, there are projects in Lua which use a tool 
called Squish, and that expects a 'squishy' file to tell what to do.

c) Know the programming language and build system you're dealing with. 
Throwing out some of the names that may be involved here: ldconfig; 
pkg-config; make; Python's setuptools. Most languages also have a 
standard on how some dependencies should be called inside the project 
prior to the first use, you may leverage that to build a quick recursive 
search using `grep`.

# References and notes

[1]: 
https://directory.fsf.org/wiki/Free_Software_Directory:Participate/Script_aid

[2]: https://directory.fsf.org/wiki/Free_Software_Directory:Scripts

[3]: https://directory.fsf.org/wiki/Free_Software_Directory:Workflow

[4]: https://directory.fsf.org/wiki/Free_Software_Directory:Participate

[5]: I know that there are distinctions to be made for generic 
downloaders which accept any address the user wants and do not predefine 
such addresses.

Em 06/09/2024 18:25, Jacob K escreveu:
> Hello,
>
> When adding a new entry to the FSD, it's not clear to me what the 
> expectations are for how we should make sure that the program fits the 
> directory. The Requirements page [1] is good but it mostly focuses on 
> what the problems are and not how to check for them. There's also some 
> instructions on the Custom entries page [2], and it mentions some tools 
> like licensecheck but doesn't elaborate on how to use them.
>
> I knew how to check if software is free based on discussions in #fsf , 
> but clearer documentation could make this easier, and mentioning a 
> single script that runs the checks currently listed on the wiki would be 
> helpful.
>
> Currently when I check software I run scancode and get a csv with lots 
> of licenses and files, and then I manually filter out the 
> free/compatible licenses. This means I have to know what all of those 
> licenses are. I don't have a good consistent way to get dependencies. A 
> better script could automate some of this work.
>
> I propose we combine information from those pages as well as information 
> from IRC logs about how to scan [3] and new information that makes 
> checking whether a program is free software as easy as possible while 
> increasing accuracy. This page would have a list of steps as well as a 
> script to automate what can be automated, for example, getting 
> dependencies in some cases using deplock [4] or hiding licenses that 
> never cause conflicts like CC0 and Expat (probably also hiding copyleft 
> licenses is fine [5]).
>
> If we want people who submit entries to scan them, maybe this info 
> should go on the Custom entries page [6]. Otherwise, maybe there could 
> be a new page called Scan or something, with encouragement to scan 
> entries people have submitted that haven't been approved yet [7].
>
>   - Jacob K
>
> [1] https://directory.fsf.org/wiki/Free_Software_Directory:Requirements
> [2] 
> https://directory.fsf.org/wiki/Free_Software_Directory:Custom_entries#Searching_in_source_trees
> [3] e.g. a suggestion I got one time to use `./scancode -n `nproc` -l -p 
> --license --csv file-name.csv ../directory-of-code-base/`
> [4] https://github.com/aboutcode-org/dependency-inspector
> [5] I think it's okay to auto-approve all free licenses because the only 
> reason there would be a problem here is if some licenses are 
> incompatible, in which case the project would be copyright infringing 
> and addressing this can be the project's responsibility.
> [6] https://directory.fsf.org/wiki/Free_Software_Directory:Custom_entries
> [7] 
> https://directory.fsf.org/wiki?title=Special:ApprovedRevs&show=unapproved

OpenPGP_signature.asc
Description: OpenPGP digital signature