05.05.20
Gemini version available ♊︎Microsoft GNU-Hub (Part 2)
Guest post by figosdev
Summary: “Does the GNU project have any policy about trusting Microsoft with control of vital free software projects at all?”
In part 1 of this series, various parts of the GNU project were looked at where Microsoft may have too much potential control over important components. To recap:
1. Perl is heavily used by the GNU Project, including by Automake. Several projects that need Perl were mentioned in Part 1, and several more will be mentioned in Part 2.
2. Zlib1g is needed by libpng, so we list projects that have png files (even in the documentation) as this GitHub-based library is needed to save and load png files with free software. If you know of a free alternative that doesn’t need zlib1g — libpng itself is not on GitHub — let us know in the comments.
3. Libffi is needed by glib2, which is needed by Gtk. Gtk1 is also based on GitHub.
4. CPython is developed on and continues to migrate further to GitHub. PyPy is a drop-in replacement for some Python scripts, but not all. For this reason, projects that use Python code are mentioned in this series.
5. C Sharp code is included in WB B-tree Associative Arrays.
6. LibreJS uses the Jasmine library, which is based on GitHub — build.sh even downloads it directly from Microsoft.
7. Gitea is also developed on GitHub, but they have had a goal of migrating since 2017 at the latest. One of the arguments for this is quotable, and is also part of the reason for this series:
“We build Gitea so everyone can use it, even users who are banned from GitHub (after recent ban wave from GitHub a lot of those users started using Gitea).”
“How could the GNU project possibly benefit from letting Microsoft gain control of Bison development?”This isn’t just about where the code is, but where the development takes place and who controls access. Trusting Microsoft with free software development while they continue to fund various manoeuvres against it makes no sense. In that context, Part 2 will include some new items that somebody ought find surprising.
In Part 1, it was mentioned that “Flex, lex, Yacc and Bison are all related — lex is a lexer, flex is an alternative, Bison is an alternative to Yacc and Bison often uses flex to get tokens.”
Flex is GitHub-based, but it’s not a GNU project — though GNU Automake uses it.
But GNU Bison has also moved to GitHub — along with Mac Changer (ages ago) and GNU Radio, Bison is actually using GitHub for development. The GNU git repo is only a mirror. Usually, GitHub mirrors are a mirror of something being developed OFF GitHub. For Bison, it’s the other way around:
https://git.savannah.gnu.org/cgit/bison.git/commit/
“GNU bison (git mirror)”
Most of the projects on git.savannah.gnu.org just have the name of the project, where it says ‘(git mirror)’. This is a mirror of akimd/bison on GitHub, where as of this writing there are 3 issues and 2 pull requests.
“Does the GNU project have any policy about trusting Microsoft with control of vital free software projects at all?”As of this writing, the most recent commit on git.savannah.gnu.org/cgit/bison.git is dated 2020-05-05 08:21:12 +0200 and also from akimd, who the GNU Savannah page says is the project admin.
Why would they do this? How could the GNU project possibly benefit from letting Microsoft gain control of Bison development? Akimd (not his full name, only his user) has 29 repos on GitHub, most of which are forks of other well-known GitHub projects. This is far from a positive move for GNU. It would be nice if this was the only new GNU project that was found on GitHub, though it’s not.
While Compact Disc Input and Control Library (better known as libcdio — as in libcdio-paranoia, not to be confused with cpio which is used to make archives and initrd images) seems to be still be based on Savannah, libcdio-paranoia (which is also available for download from http://ftp.gnu.org/gnu/libcdio/) is being developed on GitHub by the same person who maintains it for the GNU project. And he has 113 repositories there.
Does the GNU project have any policy about trusting Microsoft with control of vital free software projects at all? If they do, it isn’t being enforced in the mailing lists. Without more than a moment’s effort, this GNU mailing list conversation from as recently as last October was found, where potential GNU contributors are being encouraged to use GitHub:
“I recommend keeping your own fork of the repository somewhere, e.g. on Github. That way you have somewhere where you can push your changes for backup, in case you lose your local machine due to whatever reason. You would have to manage two remote git repositories then, your fork and the official upstream repo. But there’s plenty of documentation out there on how to do that.”
This isn’t to admonish the author for not following a rule that doesn’t exist, but to highlight the more-than-hypothetical threat that the GNU project faces from projects moving from GNU’s own hosting to Microsoft’s.
The GNU project may need to create a policy — so it’s a terrible shame that the FSF are presently without legitimate, strong or non-corrupt leadership. What a time for that, eh?
Those are the big stories, here are other findings that while they may have small problems individually, may contribute to a bigger picture issue overall:
Liquid War is a mix of Perl, Python and png files. The latter are for the program, rather than documentation.
LibreDWG seems to need Perl, Python support could be optional.
Kawa and Java Training Wheels have png files in the docs, iGNUit uses png for icons and help. Gxmessage has a png, GWL uses png, gsegraphix uses png, gnats has png in the doc. Gperf uses perl (texi2html) in /doc.
Idutils — Perl is optional?
“The GNU project may need to create a policy — so it’s a terrible shame that the FSF are presently without legitimate, strong or non-corrupt leadership.”Guile-opengl, gnatsweb, gmediaserver use Perl. Gnash uses Python, Perl in tests and png in /doc. Grep uses Perl in tests. Guile uses png in doc, libffi and flex, all of which are based in part on GitHub.
Gforth uses libfii, what’s sacrificed if ffcall or fflib is used instead? Gnowsys uses lots of Python.
GCompris is interesting. Built on Gtk and Python, it’s in the process of moving to Qt, qml and Javascript. Javascript often means GitHub, though so far the new GCompris repo seems to be GitHub-free. It’s unknown at this time if Qt has any GitHub deps like libffi, which glib2 from GNOME needs.
Findutils have Python in tests, freefont has Python in tools, Articulatory Speech Synthesis has Perl and Python, Autoconf has a Perl module, Autogen, cppi and classpath use Perl, Ball and Paddle has png in levels, ACM is Perl, so is the GNU Image Finding Tool.
“…Gitea devs at least seems to understand the importance of migration — hopefully they will be done moving away from GitHub in the near future.”DDD and Denemo have png files in the program, Electric VLSI Design System and BPEL2oWFN have png in the docs, Bayonne and ERC have Perl, C-Graph has png in the docs and cgicc has png in the demos.
Emacs uses Perl in the tests and /doc, Debian compiles it with png support, so even their “nox” version of emacs requires zlib1g from GitHub.
In part 3, we may get to tallying some statistics. Good news is welcome, and it’s nice to be able to say that Gitea devs at least seems to understand the importance of migration — hopefully they will be done moving away from GitHub in the near future. It’s really nice to have options, it’s even nicer to have real options. Sincerest and best luck to Gitea’s migration from GitHub — and where applicable, yours as well!
Long live rms, and happy hacking. █
Licence: Creative Commons CC0 1.0 (public domain)
______
* If this article uses a parody of the GitHub logo based on the GNU head, I almost certainly used this one from Wikipedia
ᶃ Gemini Space
This post is also available in 
Content is available under CC-BY-SA
arm said,
May 6, 2020 at 9:29 pm
Perhaps you should actually research where projects host their code a bit more and you would find that most of them only use github for a mirror.
As a case in point check this link and you will see that the canonical source for perl is not github.
https://perldoc.perl.org/perlhack.html#GETTING-THE-PERL-SOURCE