Microsoft's takeover of free software is fascinating, but where can the line be drawn? I treat this as both a hypothetical question and a practical one, because I've spent years boycotting Microsoft and ever since they purchased GitHub, I've noticed that's become next to impossible. "A source repo on every desk..."

"Microsoft has Gtk yoked by something glib2 needs."The kernel isn't libre, I know. I've wanted a linux-libre kernel (or at least a Debian blob-free kernel) for TC for ages. Maybe the blobs are in tcz packages. But I think if TC had a blob-free kernel it would be advertised as such.

I once hoped Alex Oliva would consider making a libre kernel for TC, but that's getting ahead of ourselves a bit. I've never been interested in maintaining a kernel, I only got into remixing distros because I wasn't paying attention.

I created scripts a year or two ago to remix Tiny Core and create tcz packages. They're basically squashfs files, which TC "installs" by mounting them. Ok, that's no big deal. Oh, development of squashfs-tools has moved to GitHub. Lovely. But the kernel portion is still developed where it should be. I take this as meaning that the Linux kernel can mount tcz, it just can't produce them. Ok, I guess we can use files that are mkfs'd to ext3 instead. That's a GitHub-free solution, we can worry about compressing them later.

What we really need to do is figure out what to remove, and that's going to take some research. I've already started figuring out which TC packages can be dropped.

Those red boxes are packages for things based on GitHub, but the gold boxes are packages that need things like libffi which is based on GitHub. Just so you know, libffi is pulled in by glib2. The GUI apps (Gtk at least) need libffi, so that's at least one serious "Gotcha" already. Microsoft has Gtk yoked by something glib2 needs.

I don't always trust Debian dependencies, but they're certainly illustrative -- here's the page for glib2: https://packages.debian.org/buster/libglib2.0-0 it needs libffi6. Oh, fun -- it also needs zlib1g. This is needed for loading png graphics, so anywhere you find a png, you need GitHub. No, this isn't because of glib2. Zlib1g is also developed on GitHub, and is needed along with libpng for loading or saving png graphics.

In the past, Microsoft has killed off lots of its acquisitions to hurt competitors, so the scenario I'm assuming is one where it decides to start killing (or taking over) free software projects it doesn't care about.

"There ought to be an exodus."When Oracle tried this with OpenOffice, the developers simply left and forked it. That's exactly what they should do, but in this instance, developers have loads of warning. And they're just sitting on Microsoft's repos like it's no big deal, letting their projects become further and further entrenched. I'm well aware of the fact that not everybody who develops on GitHub actually cares about software freedom. That's another reason not to develop there.

So imagine Microsoft forcing several such forks at the same time. Build systems for distros everywhere would be thrown into disarray. It's not that the scenario will necessarily be worst-case, but I expect Microsoft intends to get their money's worth. There ought to be an exodus.

If we are trying to escape, at least we can figure out where free software has its foot caught in a proverbial bear trap.

Libffi? Not good. Zlib1g and png graphics? Whoa, someone fix that. Lately I'm saving screencaps with JPEG in protest, which is certainly not ideal. The GIF patent has expired, but it only does 8-bit colour. I guess there's still X PixMap, right? We can do 24-bit graphics with xpm.xz (XZ-utils are not GitHub-based. I think they originated with a couple of Slackware developers.)

I've made my way from Tiny Core to Trisquel looking for GitHub vulnerable projects, and finally from Trisquel directly to the GNU project itself. It isn't good, folks.

This is Part 1, implying that there will be a Part 2 if not a Part 3, but I've only looked through a fraction of the GNU projects and here's what I've already found:

The GNU project uses Perl -- a lot!

"The GNU project uses Perl — a lot!"I don't compile a lot of programs, personally. I've spent hours editing and recompiling one C++ program, I've edited and compiled one minor C program, mostly I work with scripting languages (though I do use source-to-source compilers a lot).

If there are obvious mistakes or less obvious misconceptions I'm presenting when I talk about some of the details, I hope you'll mention it in the comments. I'm sure there will be a few differences of opinion as well.

But let's start with Automake. Automake is used for a large number of GNU packages -- it depends on Perl. Perl is on GitHub. That's not good, hackers -- that's not good.

Many GNU sources have a file called "missing" which I believe is Automake-related. This file often informs the user that they will need Perl (and links to perl.org so they can get it) and it links to flex on GitHub. There's another one. Of course some of the GNU sources are so old they still link to the flex on SourceForge. Here's a fun fact: GNU Savannah is a fork of SourceForge from when it was still free software.

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. The problem is that flex is GitHub-based. This is not good. Plus, Automake also wants flex. So whatever sort of creek we are in, our paddle is slowly transforming into a tiny little stick.

A lot of GNU sources include texinfo files. Texinfo seems to need Perl as well.

VERA includes a Perl script, vc-dwim is a Perl script (missing wants flex anyway) WB B-tree Associative Arrays seems to include C Sharp code (so you'll need Mono, which the FSF warned against and which is based on GitHub) XBoard uses png files, Xnee includes pnee which uses Gtk and png.

As mentioned, Gtk brings in glib2 which brings in libffi, which is based on GitHub -- while Gtk2 and Gtk3 are not based on GitHub, if you're looking for Gtk1, GitHub is where it appears to be.

Some of these old GNU programs appear to use Gtk1, so whether each one is GitHub-based because of libffi or GitHub-based because of Gtk1, is a detail I've mostly ignored.

Units includes units_cur which is a Python script and texi2man which is a Perl script.

"Texinfo seems to need Perl as well."The thing about Python is that CPython is the most often-used implementation, including in the GNU project, and CPython is based on Microsoft GitHub. PyPy is a great drop-in replacement, though it doesn't work on everything.

You can't always tell when you find yourself in front of a Python script, whether it needs CPython (thus GitHub) or not. So Python is worth watching for, but only proves to be a GitHub hostage sometimes.

Taylor UUCP uses Perl, Tex for the impatient uses png files in docs, Texinfo uses Perl, Hurd includes gitlog-to-changelog which calls Perl, GNU Readline includes texi2html and texti2dvi, which use Perl.

GNU Shepherd has png files in /doc and perl and flex in missing. Gnu Telecom has a png file. Sather has a Perl script called ps2gif. Spread Sheet Widget uses Gtk, SQLtutor has pngs in the docs. Swbis appears to need Python and python-devel.

Queue is dumped in favour of GNU Parallel, which uses Perl. Ring redirects to GNU Jami, which uses Python.

PythonWebkit obviously needs Python; pyconfigure may get away with PyPy as a replacement. PSPP uses Perl and png files with a GUI in Gtk. Proxyknife has Perl code in the docs and in configure.

Doxyfile is one to watch for in the sources. I believe this is created by Doxygen, which is used to created documentation from source code. Doxygen is based on GitHub.

PowerGuru has a png and lots of Python code, oleo has png in docs and uses plotutils, which support png. Ocrad has a png in /archive. Occhiolino uses Python. MetaHTML uses perl.h.

Mac Changer hasn't updated in years, but like GNU Radio is a GNU project that's based on GitHub -- really not good. I can't figure out why GNU Radio hasn't tried to move though. That still gets worked on, unlike Mac Changer.

GNU LibreJS, a tool I cheered on for ages waiting for it to be created, uses Jasmine, a Javascript library which is based on GitHub: http://git.savannah.gnu.org/cgit/librejs.git/tree/build.sh

In fact build.sh downloads it directly from Microsoft, which I think shows a bit too much trust given that this plugin goes directly into GNU IceCat:

JASMINE_URL="https://GitHub.com/jasmine/jasmine/releases/download/v$JASMINE_VER/jasmine-standalone-$JASMINE_VER.zip" curl -L -o "$JASMINE_LIB.zip" "$JASMINE_URL" && unzip -d test/ $JASMINE_LIB.zip lib/**

We've all done something like this, but this is exactly where it shouldn't be done.

Make also seems to need Perl, it may or may not need Python.

"The FSF already warns people against non-free repos such as GitHub. While self-hosting is certainly better, many people won't and my advice to them is at least choose a non-profit organisation for hosting their code."This only covers a portion of the GNU project, but let's tally up what needs to happen for the GNU Project to not rely so heavily on the good will of its most dedicated foe:

1. Fork or make an official GNU mirror of Perl. If Perl goes, GNU is just about done.

2. The same applies for zlib1g as well. This library was invented and/or promoted specifically to avoid GIF-related patent traps! Now it's controlled by the world's second-biggest patent troll (the other sponsors the FSF. Great.)

3. Figure out libffi. I can't tell you more, I only know it helps things like Python use things like ctypes ("foreign functions").

4. Start using PyPy more, when possible. CPython is a trap. Note that PyPy has some major limitations. I'm very fond of it, any limitation it has I'm hoping for the best.

5. Write something justifying support of Mono in WB B-tree Associative Arrays. I would suggest removing that part of the code, but that seems unlikely.

6. That LibreJS code could be fixed today. At least mirror Jasmine in the LibreJS tree.

7. The FSF already warns people against non-free repos such as GitHub. While self-hosting is certainly better, many people won't and my advice to them is at least choose a non-profit organisation for hosting their code.

Gitea is also developed on GitHub, so it's a bit odd that they're touting it as an alternative. If it's an alternative, why not move Gitea off GitHub then? (at least move it to GitLab).

I never did trust Google Code, of course. For-Profit code repos technically have the same problem that GitHub has: they can be bought just like GitHub. Non-profits have to be infiltrated like the FSF or FSFE instead, which is harder.

"What's lacking now is leadership, and though I think it would take more than putting Stallman in charge again (which is the right thing to do as the efforts to remove him were dishonest and corrupt, plus it would probably help) there doesn't seem to be anybody who is doing a better job."A decentralised, peer-to-peer means of hosting would be ideal, though currently the main project I know of related to hosting code that way is through feneas.org, which I already associate with the typical trend of Codes-of-Censorship (along with a "FOSS" manifesto which combined with their Code of Conduct is ultimately going to lead to a hardline, de facto "be nice to the Open Shills" policy. It's not like there aren't precedents.

Don't get me wrong, so far the software looks good. But you can say the same for the GNU Project.

The importance of leaving GitHub is really not stressed enough by what's left of the Free Software Foundation.

What's lacking now is leadership, and though I think it would take more than putting Stallman in charge again (which is the right thing to do as the efforts to remove him were dishonest and corrupt, plus it would probably help) there doesn't seem to be anybody who is doing a better job.

Unless "better" means "bigger events funded by Microsoft and Google". No thanks, the Linux Foundation was doing that already, and it didn't help at all.

Long live rms, and happy hacking. ⬆

Licence: Creative Commons CC0 1.0 (public domain)

Not including the code snippet, which is from http://git.savannah.gnu.org/cgit/librejs.git/tree/build.sh

And if this article uses a parody of the GitHub logo based on the GNU head, I almost certainly used this one from Wikipedia.