In the previous article, the overall methodology for this series was discussed, and Tom has since written this article outlining some of the reasons these things are problems, and what can and probably ought to be done about them.
"gnu.org/software" url for Fribidi immediately redirects to the Microsoft-controlled GitHub repo. Let me tell you what I think of this fact.
"Microsoft doesn't say they love your freedom, because their model isn't based on freedom."Microsoft claims to "Love Linux", but lots of very bad people claim to love their victims. Microsoft doesn't say they love your freedom, because their model isn't based on freedom.
They don't say "free software" because they aren't trying to make you free. In fact Techrights has covered the money they paid to politicians to get the City of Munich to ditch free software -- and go back to Microsoft instead! Then there are the bogus patents and royalty-seeking attacks on free software, which both FSF-sponsor IBM and Microsoft have continued to support.
More than a year before Microsoft purchased it, the FSF gave GitHub an "F" in its evaluation of code repo criteria: https://www.gnu.org/software/repo-criteria-evaluation.en.html. They cited:
* Important site functionality does not work without running nonfree JavaScript.
* Specific information may not be available in all countries
* The worst thing that GitHub does is to encourage bad licensing practice
The FSF also links to other reasons for avoiding GitHub, which were valid before the acquisition but are all the more relevant now.
"In fact Techrights has covered the money they paid to politicians to get the City of Munich to ditch free software -- and go back to Microsoft instead!"The lock-in for some users (or perhaps we should consider a different term for people stuck with GitHub -- useds, because Microsoft is using them more than they're using Microsoft) could be enough to create tension between developers and GNU leadership, as of the 33 people on this anti-rms petition nearly 2/3 of them have remained active on GitHub since they were purchased by Microsoft.
We are going to avoid using the names of individuals (though they already name themselves) but some of the people on the list have even contributed to the connections between GitHub and the GNU project. What isn't being said here is that this is definitely the reason for the petition. While the timing "seizes the day" in terms of trying to kick out rms while he was already stepping down from FSF leadership, the real motivations of the signed are unknown unless we take them at their word.
When no fewer than 20 of them have written or forked code on Microsoft GitHub in the past year, in some instances even for the GNU Project -- (at least 7 of them appear to work for Red Hat, which develops on GitHub and is now owned by the FSF's largest sponsor) we have to point out the possibility that opportunism was a factor.
Either way, trusting one of the most infamous opponents of software freedom with moderation of projects like GNU Bison, GNU Fribidi and other projects key to the GNU project seems like either hiring or working for your own client's opponent -- this sounds like textbook conflict of interest to me, though Tom is the person I would go to for his greater experience with organisational process. Perhaps instead of formally being a conflict of interest, crossing the GNU project with GitHub is merely a really terrible idea -- one of those instances where "compromise" isn't a word denoting reason and cooperation as much as failure.
A bit outside the reach of GNU developers to be certain, GNUzilla is built with rust, which is developed on GitHub.
I'm now trying to catch projects that include jpeg, pdf and postscript files. Why? Because pdf and postscript files use ghostscript, which is typically compiled with png support and brings in zlib1g from GitHub. Help me find a way that's not so.
"...of the 33 people on this anti-rms petition nearly 2/3 of them have remained active on GitHub since they were purchased by Microsoft."For a week or two I was saving screencaps as jpeg instead of png, but it looks like OpenJPEG is GitHub-based as well. Does anybody still use libj2k?
Packages that include one or more png files include gnuschool, GNUjump, GNUbik, GNU remotecontrol, GNU Optical design and simulation library, GNU mifluz, GNU Chess and GNU libmicrohttpd.
GNU Crypto, GNU Astronomy Utilities and Gnu Circuit Analysis Package have png and pdf in docs. GNU Generic Security Service Library has png, pdf and postscript.
GnuTLS has Perl and png in the docs, GNUtrition has Python, png, and pdf.
GNUspool and GNUbatch have Perl, Python and png.
GNUsound has png files, as well as modules for ALSA and Jack, both of which are GitHub based -- though I still don't believe that and will have to check it a few more times before I do.
GNUpod is Perl based.
GNUnet uses Perl, and wolfssl from GitHub.
GNUlib uses https://github.com/gnulib-modules/bootstrap which I found because gnu-pw-mgr uses bootstrap.
GnuCOBOL has a scanner generated by flex, and Perl in tests and docs.
With gnubg, I'm hoping someone can explain this one. It contains Python scripts, there's code written in C which is alright (I'm not going to check how these are related) and someone who appears unrelated to the project is working on something on GitHub which is also called "GNU Backgammon" at ytani01/ytBackgammon--
This is free software, so it's certainly alright if someone forks it or creates what appears to be a Javascript project (if it is indeed a fork). It's unfortunate that they've chosen GitHub for this, but if it's not one of the actual GNU maintainers, we can't blame the GNU Project for this. We can only hope that ytani01 decides to DeleteGithub and move their project somewhere else.
"GNU Smalltalk really shouldn't be developed on Microsoft Github."GNU Zile has Perl in tests and build.
GNU Wget has png in docs and could be compiled with support for brotli (from Google's GitHub) or zstd (Facebook's GitHub) or libpsl for cookie domain checking, which appears to be from GitHub.
GNU VCDImager is being developed on GitHub.
GNU Typist has Perl and Perl modules in tools.
GNU troff and GNU Stow use Perl.
GNU tar calls GNU bison, which is GitHub-based.
GNU SpaceChart uses Perl and contains a parser made for or with bison.
GNU source-highlight has Python and Perl in tests.
GNU Source Release Collection will depend on GitHub as long as any official GNU software does, as its purpose is to "maintain a rolling release of the latest version" of GNU projects.
I would be more comfortable with someone trying to make an official distro-like collection of all GNU projects if the project admin wasn't someone who has continued to develop on Microsoft GitHub for the past year. Why not just bring the entire GNU project into a GitHub staging area?
What is this, anyway? https://github.com/gitGNU
"gnu_bash C GPL-3.0 37 61 0 2 Updated 5 days ago"
"I stopped counting things that use flex or bison for building because there are so many."GNU Solfege uses Python and png.
GNU social uses HTTP_Request2, from GitHub.
GNU Smalltalk has a story, of sorts. It was being developed on GitHub as far back as 7 years ago, well before the Microsoft purchase but by now-inactive contributor bonzini/smalltalk. I only noticed this because of a dead link to MrGwen/gst-visualgst in the /packages folder of the GNU Smalltalk sources.
The current GNU maintainer is also active on GitHub, though it does not seem to be where the most recent Smalltalk development has taken place. For clarity, here is a quick timeline...
* The most recent commit from the actual GNU Smalltalk maintainer on GitHub appears to be from 2015 on janvrany/gst, except for the following fork:
* The most recent commit on GitHub related to GNU Smalltalk appears to be on a fork of Smalltalk at Synss/smalltalk (it also includes a more recent commit from the current GNU maintainer) in 2017 -- this is before the GitHub purchase.
* After the 2018 acquisition, the most recent commit to GNU Smalltalk (typo fixes in the tutorial) appears to be on the GNU git -- this is ideal if it's accurate. GNU Smalltalk really shouldn't be developed on Microsoft Github. http://git.savannah.gnu.org/cgit/smalltalk.git/commit/
So there's probably nothing sinister there, but it's worth watching. The /examples include Gtk, cairo (either gtk1/github or cairo2 < zlib1g) and it uses png.
Gnu Slip uses or used bison, uses or used flex, includes a pdf user manual.
GNU Shishi is a Kerberos 5 implementation with pdf, png and postscript in the docs.
GNU sed uses Perl in tests.
"Even without being based on nixos, the fact that Guix is/has a package manager with package data means that its going to pull in applications from GitHub."GNU Screen includes postscript in docs, while GNU Scientific Library includes Python and png in the docs.
GNU Rush includes cflex.c which is generated by flex, which is from GitHub.
I suppose there are two ways you can treat a parser or lexer created with bison or flex. You can treat them as compiled output of bison or flex, or as a program or fork in their own right. How you decide to think of them determines how vital bison or flex is to changing that project.
You can certainly change the output of bison or flex without running bison or flex again. Anybody who has written their own parsers understands this. But if the source includes the input for bison and flex or calls it from a script, then it's difficult to say they aren't required as well.
I stopped counting things that use flex or bison for building because there are so many.
GNU Robots uses Gtk. When you see Gtk, it pretty much means glib2 or gtk1 -- one of which needs libffi, the other of which is on GitHub. This is irritating -- somebody show the way out of this. I don't love GNOME at all, but I do like Gtk.
GNU radius has a scanner written by flex, it also uses Perl. GNU Pth uses Perl and includes postscript documents.
GNU Prolog has Perl in examples, pdf and png in docs. GNU Pem uses Perl.
GNU patch appears to use bison. GNU Parted uses Perl and Python in tests.
"As to whether Guix depends on GitHub, I would say so."GNU Parallel is based on Perl, and has pdf in /src.
GNU Paint is written in Vala, and uses glib, cairo and Gtk.
GNU Octave uses Perl and png, GNU Networking Utilities use Perl.
GNU nano has OS/2 support which comes from GitHub, and seems to need flex. The Debian package inexplicably requires zlib1g, I was unable to determine why (it's not mentioned in the source) https://packages.debian.org/buster/nano
GNU MIX Development Kit has png in the docs, a scanner generated by flex, and uses Gtk.
GNU Midnight Commander uses Perl and optionally builds with glib2 (which needs libffi which is from Github).
The NEWS file in GNU Mes says: "Mescc now depends on M1" from mescc-tools on GitHub, and "Mescc now depends on the hex2 linker" from mescc-tools on GitHub.
GNU MediaGoblin uses Python, as well as Docker (Docker is based on GitHub).
GNU Mailutils uses lots of Python and may need bison or flex.
GNU Mailman uses Python and png.
GNU Linear Programming Kit has pdf in examples, /doc.
GNU LilyPond Music Typesetter uses Python, postscript, has png in docs.
GNU Libtasn1 may need bison, has postscript, png and pdf in docs.
"First, I use basic automation and string matching to isolate relevant data, then to present it to me one project at a time so I can process hundreds of projects."GNU Internationalized Domain Names Library has Perl in tests, pdf and png in docs and may have other components from GitHub.
GNU Hyperbole uses Python, png -- this one is worth watching with regards to GitHub.
GNU Health is largely Python-based.
GNU HaliFAX uses Gtk. GNU gzip uses Perl. GNU gv has a parser generated with bison and uses Perl.
GNU Guix has png in docs, pdf in docs and probably needs libffi from GitHub.
NixOS being Github-based means GitHub is probably impossible to avoid for Guix -- though that wouldn't mean Guix had no potential as a fork.
Even without being based on nixos, the fact that Guix is/has a package manager with package data means that its going to pull in applications from GitHub. No effort is being made to make that more than it is, because practically every known distro pulls in packages that are GitHub-based -- like Python, for example. Also libgd (GitHub) which the changelog says was added then removed. Very relevant to Guix? Perhaps not, but due to looking it up I know libgd is GitHub-based.
As to whether Guix depends on GitHub, I would say so. Elogind is forked on GitHub for guixSD: https://github.com/elogind/elogind The fork is for a good cause, but why use GitHub for this?
From README.md: "All of the credit for elogind should go to the systemd developers." "All of the blame should go to Andy Wingo, who extracted elogind from systemd." "All complaints should go to Sven Eden, who is maintaining elogind."
The readme for GNU Guile-CV says Guile-CV is based on vigra (which is based on GitHub).
GNU GRUB uses Python, png, jpeg. Riscv-isa-manual is GitHub-based. The changelog implies that zstd from Facebook's GitHub is supported, which possibly means it's included. And m4/intl.m4 says "dnl because plural.y uses bison specific features".
"As to how to devote hours at a time to this, it really takes a soundtrack. Half of this research was not possible without Green Velvet and Tiësto sets on loop -- I would have gotten really bored."GNU gradebook uses png and Gtk. GNU Go uses Perl, Python and has png in docs and pdf in docs.
GNU GLOBAL uses Python and Perl. It also appears to include jQuery, which is GitHub-based.
GNU Enterprise and GNU EDMA use Python.
GNU C Library uses Perl and Python. Serious question -- what is it like if you remove them? I'm glossing over a lot of details there, sorry about that.
This was incredibly tedious work to research and put together, how did I sit through this?
"With a soundtrack, it's also quite interesting to discover all these Lilliputian strings linking the GNU project with stuff developed increasingly on GitHub -- Microsoft tries, as it always has year after year -- to take all the marbles and win."First, I use basic automation and string matching to isolate relevant data, then to present it to me one project at a time so I can process hundreds of projects. The automation and results prove nothing -- they only show where to pay more attention. I take the data and go from there.
As to how to devote hours at a time to this, it really takes a soundtrack. Half of this research was not possible without Green Velvet and Tiësto sets on loop -- I would have gotten really bored. With a soundtrack, it's also quite interesting to discover all these Lilliputian strings linking the GNU project with stuff developed increasingly on GitHub -- Microsoft tries, as it always has year after year -- to take all the marbles and win.
Will Part 5 have some good news? You tell me.
Long live rms, and happy hacking. ⬆
Licence: Creative Commons CC0 1.0 (public domain)