99% of the time, letting Microsoft have influence or control over your software is a negative -- and that's being generous.
"Too much depends on too much else, and the only "freedom" will come from forking projects and making them optional again."No one calling for this modularity assumes that there won't be dependencies in software; that is a straw man. But when the dependencies all depend on Microsoft GitHub, that should give serious pause.
Whatever your feelings on that are, a stated goal of the research in this series was to figure out what it would take to produce a GitHub-free software distribution -- as a protest, thought experiment and illustration of the amount of leverage Microsoft has gained.
It also shows, beyond a shadow of a doubt, I think -- that too many GNU developers are apathetic about the fact that Microsoft now controls GitHub. GitHub activity by GNU developers (not all of them, as far as we know) has not ceased since the purchase of GitHub more than a year ago. On the contrary -- the GNU project has made little known effort (from the top or otherwise) to move away from GitHub since the acquisition.
The FSF's stance as usual, is to broaden the scope of the problem until it can support a nearly-lukewarm plan of action (if any at all). Unless there is a dramatic change, the FSF might as well just hand over the GNU project to Microsoft altogether.
Bit by bit, GNU is moving more in that direction than the other. When will they actually change heading? The future of the Free software movement -- if it has one -- is from people who are less apathetic than the FSF or even the GNU developers. Prove me wrong, devs -- very little would make me happier.
Not that rms didn't try, but not enough GNU maintainers are listening.
Although this part will serve as a summary, it is not a summary alone. Part 5 adds several projects to the list, concluding (for now) the study of the full list of official GNU projects as listed on GNU Savannah.
To answer the question -- what would it take to have a GNU distro that is free of GitHub, I would start with a modular, low-frills but still generally practical distro like Tiny Core. It's systemd-free and uses BusyBox. I prefer the "real", full version of these utilities, which I usually install on top of this.
I already have a system that can automate the remastering of Tiny Core, including its packages, but (like most distros with a live image) Tiny Core relies on squashfs for some of its filesystem. In fact it relies on squashfs for its packages as well.
"Unless there is a dramatic change, the FSF might as well just hand over the GNU project to Microsoft altogether."Since squashfs is based on GitHub -- the utility, but not the kernel portion, I take this to mean that we can mount sfs packages and images but not repack them. Therefore to go GitHub-free, we could produce a tool that converts sfs images to files that are formatted with the ext3 filesystem.
This would increase the size of each package, which we could then compress with gzip or xz-utils. That would at least make packages tolerable in terms of download size. Whether we could develop a way to mount packages without first decompressing them is an exercise left for the reader, at least for now.
Since GNU tar relies on GNU Bison, which is based on Microsoft GitHub, simply having tar available would require moving GNU Bison. If there is a way to use GNU tar without GNU Bison, that would also help.
In part 1, it was recommended that the GNU project fork or at least mirror Perl 5 on some non-GitHub repo. A mirror in and of itself wouldn't satisfy the standard of "GitHub-free" followed by this series per se, but it would be a start -- and it's assumed that "the world will move to Perl 6" (Raku) anyway. This is a very premature assumption if the move from Perl 5 to 6 is anything like the move from Python 2, but for the sake of consistency, a hard fork of Perl is recommended.
Then after you move GNU Bison off GitHub and also fork Flex, you will have enough GitHub-free software to use Automake again.
We aren't out of the woods yet, because we have no compiler. Both Clang and GCC have some dependencies on GitHub, and it is assumed that GCC is more valuable to the GNU project than Clang is. So remove or hard fork D language (GitHub) which is included in GCC, and hopefully at this point you won't need to remove the Perl scripts that are used for unit tests or building the compiler or glibc.
"Both Clang and GCC have some dependencies on GitHub, and it is assumed that GCC is more valuable to the GNU project than Clang is."Again, if you know an easier way, please let us know in the comments.
I've never used linux-libre to deblob the kernel, but a lot of it is shell scripts. The deblob-check script can use awk, Python or Perl -- with Perl discouraged and awk recommended. We could try to find out if the Python part works with PyPy, or remove it. Linux-libre also calls tar, so that would probably need to be sorted first.
It would be interesting to know if you can really use and maintain the GNU project without Perl. We now have statistics on it (they are incomplete, but mostly complete -- so we use the phrase "at least" a lot) and we can now say things like...
At least 54 (or 16%) of the 338 listed GNU projects (FriBidi isn't listed) use Perl: (GIFT) GNU Image Finding Tool, ACM, Articulatory Speech Synthesis, GNU Autoconf Archive, autogen, bayonne, classpath, cppi, ERC, GMediaServer, Gnatsweb, GNU a2ps, GNU Anubis, GNU Aspell, GNU Automake, GNU C Compiler, GNU CLISP, GNU Common Lisp, GNU Core Utilities, GNU FreeIPMI, GNU gcal, GNU GLOBAL, GNU Go, GNU gv, GNU gzip, GNU Midnight Commander, GNU Networking Utilities, GNU Octave, GNU Parallel, GNU Pem, GNU Pth, GNU radius, GNU SpaceChart, GNU Stow, GNU troff, GNU Typist, GNUbatch, GNUnet, GNUpod, GNUspool, Guile-OpenGL, LibreDWG, Liquid War 6, M <MetaHTML>, make, PSPP, Sather, Taylor uucp, texinfo - GNU documentation system, The GNU Hurd, The GNU Readline library, units, V.E.R.A. and vc-dwim.
Another 10 (or 3%) use Perl in unit tests: emacs, Gnash, GNU Datamash, GNU Internationalized Domain Names Library, GNU Parted, GNU sed, GNU source-highlight, GNU Zile, GnuCOBOL and grep.
Still another 5 (or 1%) have Perl in docs: GNU awk, GNU Gama, GnuTLS, gperf and Proxyknife.
In total, at least 69 or 1 in 5 listed GNU projects use Perl, which is based on Microsoft GitHub.
"Gtk1 is based on GitHub these days, so any old stuff that needs that you'll want to bring up to at least Gtk2."Png graphics are another thing we probably want to liberate. While libpng is thankfully not based on GitHub, libpng is one of two libraries needed for loading and saving png graphics, the other being zlib1g. Zlib1g is based on Microsoft GitHub. So when we start counting files that need zlib1g to load or save them...
At least 31 (or 9%) of the listed GNU projects use png graphics: Ball and Paddle, DDD, Denemo, GNU Chess, GNU CIDE, GNU FM, GNU FreeDink, GNU gradebook, GNU GRUB, GNU Hyperbole, GNU libmicrohttpd, GNU Mailman, GNU mifluz, GNU Optical design and simulation library, GNU remotecontrol, GNU Smalltalk, GNU Solfege, GNUbik, GNUjump, gnuschool, GNUsound, GSEGrafix, Guix Workflow Language, iGNUit, Liquid War, oleo, PowerGuru, PSPP, The GNU Telecom Subsystem, XBoard and Xnee (which includes pnee).
An additional 28 (or 8% of) projects have png graphics in the docs: BPEL2oWFN, C-Graph, Electric VLSI Design System, Gnash, gnats, GNU Astronomy Utilities, Gnu Circuit Analysis Package, GNU CLISP, GNU Core Utilities, GNU Crypto, GNU Gama, GNU Go, GNU Guix, GNU Internationalized Domain Names Library, GNU Libtasn1, GNU LilyPond Music Typesetter, GNU MIX Development Kit, GNU Prolog, GNU Scientific Library, GNU Shishi, GNU Wget, GnuTLS, Guile, Java Training Wheels, Kawa, SQLtutor, TeX for the Impatient and The GNU Shepherd.
Together, these 59 projects represent 17% of the GNU project by count.
But png graphics are not the only thing we need to worry about. Graphics in general are a problem if we want to be free of GitHub. As a small protest, I was saving graphics as jpeg instead of png for a week or two -- but I've discovered that OpenJPEG is GitHub-based as well. Does anybody still use libj2k?
"So right now, Gtk and Qt are pretty much out unless we do some forking."If we don't care about compression, we can do all sorts of things. RAW files, xpm, pcx (basically an RLE-encoded means of compression -- not great, but helps sometimes and it's easy to implement). Presumably however, we care about compression.
Plus, after you fork Perl and zlib1g, you can have most of your graphical toolkits back... or at least you can have Qt back.
Gtk1 is based on GitHub these days, so any old stuff that needs that you'll want to bring up to at least Gtk2.
Gtk 2, 3 and 4 (in development) all bring in glib2 (that's GNOME lib, not GNU libc) which brings in libffi and zlib1g. Presumably we have already given in and forked zlib1g -- there will be more reasons to do so. But libffi we've made no decisions about yet, and it's based on Microsoft GitHub. Shall we wave goodbye to GNOME then? (If only it were just GNOME...)
As with glib2, qt4core and qt5core bring in zlib1g, which is on Microsoft GitHub. So right now, Gtk and Qt are pretty much out unless we do some forking.
Libtk also brings in zlib1g from GitHub; from what I've read, directfb is AWOL, except for GitHub. GGI is alright -- the most recent stable version is from 2007. SVGAlib is good! The most recent stable version is from 2001. But you're probably better off stability-wise with GGI.
X.Org itself is not based on GitHub, so as with png vs. xpm graphics, if you're content to use X directly without any additional libraries or toolkits... You're thinking about motif, right? libmotif brings in libmrm4 which brings in libxm4, libpng and zlib1g. But good thinking.
8 (or 2%) of projects use Gtk: GNU gradebook, GNU HaliFAX, GNU MIX Development Kit, GNU Paint, GNU Robots, PSPP, Spread Sheet Widget and Xnee (which includes pnee).
"Stallman warned against this in 2015."You know what else is typically compiled with png support and needs zlib1g? Libgs from ghostscript. So now we are counting projects that use pdf or postscript files:
At least 11 (or 3%) of projects include pdfs in docs, including GNU Astronomy Utilities, Gnu Circuit Analysis Package, GNU Crypto, GNU Go, GNU Guix, GNU Internationalized Domain Names Library, GNU Linear Programming Kit, GNU Prolog and Gnu Slip. GNU Libtasn1 and GNU Shishi contain pdfs as well, and additionally include postscript files in docs. Another two projects, GNU LilyPond Music Typesetter and GNU Screen, make use of postscript files. All of these bring in zlib1g from Microsoft GitHub.
By far the most egregious thing that has ever happened to the GNU Project, is that some of the projects themselves have moved to GitHub. Stallman warned against this in 2015. That didn't stop GNU Radio from moving there in September the following year. In fact, one GNU maintainer (of a different project, however) emailed the GNU Radio list in 2017 to say the following:
“Please do not use github. It runs non-free JavaScript, hosts non-free software discover-able by its users, and encourages poor licensing practices."
This was not simply one developer's personal feelings or opinion; it was more or less what Stallman himself had said in 2015. One person on the list (a non-maintainer) replied:
"I get your concerns, but AFAIK it’s currently very unlikely that GNU Radio will leave GitHub. It is still the place-to-be for open source code. If you feel uncomfortable using GitHub, we also have the repo self-hosted at http://gnuradio.org/redmine/projects/gnuradio/repository ."
Don't bother going to the redmine repository, as of this writing it gives a 404.
Then an actual GNU Radio maintainer piped in, albeit with something less helpful than the non-maintainer's reply:
"I’m going to paraphrase your position, to highlight the absurdity of it:"
"Please don’t house Gnu projects in buildings in which other, non-free, software development takes place, also, not in cities in which the by-laws allow such non-free entities to conduct business".
"Can you see how absurd your position is?"
That wasn't the emailer's actual position, however.
So you have at least one active GNU maintainer who isn't merely unimpressed with Stallman's word on being on GitHub, but considers any similar mention an absurdity. A year or so later, Microsoft purchased GitHub. Has GNU Radio moved away yet? Not yet.
"In order to clear a project as GitHub free, we want to know that it works with PyPy -- as CPython is based on Microsoft GitHub."8 (or 2%) of projects have actually moved partially or entirely to GitHub: GNU Bison, GNU Radio, GNU Smalltalk (perhaps unofficially, but then it appears they may have had the good sense to move to their own Git again after the Microsoft purchase -- we are still piecing together some of the details with these projects), GNU FriBidi (listed more than once as a GNU project, though presently unlisted as one) as well as part of GNU VCDImager and part of libcdio (libcdio-paranoia specifically). MAC Changer is on GitHub though nobody has touched it in years. GNU Freetalk moved to GitHub at least 3 years ago: http://git.savannah.gnu.org/cgit/freetalk.git/commit/ https://github.com/GNUFreetalk/freetalk/commits It's right there in the source files and documentation: freetalk-4.1/doc/freetalk.1 "Report bugs at https://github.com/GNUFreetalk/freetalk/issues"
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 and GNU Bison are both GitHub-based.
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. As I said in Part 4, I stopped counting things that use flex or bison for building because there are so many.
Given that it's difficult to say what really does and doesn't need them, at least 4 (or 1%) of projects have a scanner generated by flex: GNU MIX Development Kit, GNU radius, GNU Rush and GnuCOBOL.
Another 3 projects seem to require flex for some of their functions: GNU nano, Automake and Guile.
At least 4 (or 1%) of projects have a parser generated by or call GNU Bison, which is based on Microsoft GitHub: GNU gv, GNU patch, GNU SpaceChart and GNU tar.
"Incidentally, both PyPy and CPython need zlib1g and libffi. Both zlib1g and libffi are based on GitHub, so while CPython is developed on GitHub and PyPy is not, both need two key libraries from GitHub regardless."Regarding Python in the GNU Project and in general, CPython is the most often-used implementation overall. PyPy is a great drop-in replacement, though it doesn’t work on everything. Therefore Python is worth watching for, but only proves to be a GitHub hostage sometimes. In order to clear a project as GitHub free, we want to know that it works with PyPy -- as CPython is based on Microsoft GitHub.
Incidentally, both PyPy and CPython need zlib1g and libffi. Both zlib1g and libffi are based on GitHub, so while CPython is developed on GitHub and PyPy is not, both need two key libraries from GitHub regardless. It's very important to rescue zlib1g and libffi from GitHub. PyPy is still the more GitHub-free of the two Python implementations.
At least 33 (10%) of projects use Python: Articulatory Speech Synthesis, Free UCS Outline Fonts, Gnash, Gnowledge Networking and Organizing System, GNU a2ps, GNU C Compiler (to build?), GNU C Library (What is it like if you remove the Python scripts?), GNU EDMA, GNU Enterprise, GNU FM, GNU FreeDink, GNU GLOBAL, GNU Go, GNU GRUB, GNU Health, GNU Hyperbole, GNU Jami, GNU LilyPond Music Typesetter, GNU Mailman, GNU Mailutils, GNU MediaGoblin, GNU Solfege, GNU source-highlight, GNUbatch, GNUspool, GNUtrition, Liquid War, Occhiolino, PowerGuru, pyconfigure, PythonWebkit, swbis and units.
If you noticed, GCC and glibc both use Python, which requires libffi from GitHub. So perhaps that's the entire GNU Project relying on Microsoft GitHub, right there -- unless Python and libffi are really optional for these (that would be great).
Also won't GNU GRUB work without Python? It must, as I've booted distros without it (Tiny Core can). But it contains Python scripts, whatever they're needed for.
There are 339 projects (plus some additional dependencies) covered in this series. I've looked through the entire GNU Project for all the information I could find, including in the source code -- and I've verified as much as possible. Though I can hardly say I'm familiar enough with the entire project to rival what the developers or maintainers know. I've compiled very few C programs, as a matter of fact.
For all these grim findings, it would be nice to get some reassurances from maintainers. I feel confident that a decent amount of this data will prove accurate -- and I hope that at least some of it is wrong.
It's particularly difficult to determine what's optional. For GNU diff utilities, Perl seems to be truly optional. GNU make may let you choose between Perl or Python.
GNU CSSC, findutils and GNU Parted have Python in tests.
Guile, Gforth and GNU Guix all seem to need libffi. What’s sacrificed if ffcall or fflib is used instead? I couldn't tell you if that's possible.
Gnu-pw-mgr and gnulib both use gnulib-modules/bootstrap from GitHub.
"GNU social uses HTTP_Request2 from GitHub."GNUzilla is built with rust, which is developed on GitHub. It also includes LibreJS, which uses Jasmine from GitHub.
Gnu Guix uses elogind, which a GNU maintainer forked on GitHub. Why didn't they choose another repo?
GNUsound includes modules for both ALSA and Jack audio. This is understandable, but both are based on Microsoft GitHub.
GNU Wget is sometimes compiled with support for brotli compression from Google's GitHub repo, or zstd from Facebook's GitHub repo.
GNU GRUB may use zstd and Bison as well.
GNU Mes appears to depend on two projects from GitHub, mescc-tools and hex2 linker.
GNUnet uses wolfssl from GitHub.
WB B-tree Associative Arrays includes C Sharp code, which runs on Mono from GitHub.
GNU nano gets OS/2 support from GitHub. This may not apply when compiled for other platforms.
GNU social uses HTTP_Request2 from GitHub.
The readme for GNU Guile-CV says Guile-CV is based on vigra, which is on GitHub. Does that make it a hard fork?
"GNU MediaGoblin uses Docker, from Microsoft GitHub."The GNU Source Release Collection is a metarelease of all GNU sources. As long as any part of the GNU Project uses GitHub, so will it.
GNU MediaGoblin uses Docker, from Microsoft GitHub.
Finally, Doxyfile is something to watch for in the sources. I believe this is created by Doxygen, which is used to create documentation from source code. Doxygen is based on GitHub.
If you put all these together, at least 163 projects -- or 48% of the GNU Project -- is using software that's based on Microsoft GitHub.
Originally I had hoped to simply remaster Tiny Core and remove the packages that were GitHub-based. A true fork of Perl -- even a GitHub-free fork of GCC, is more than one person would likely or reasonably do for the sake of a protest or thought experiment. This isn't going to work unless the GNU project (or a fork of the GNU project) decides to take it seriously. I certainly don't expect that to happen.
Instead, I have to ask -- how much leverage is the GNU project going to leave in the hands of its most significant opponent? While Roy is more optimistic, I believe this is all more damning than it first appears. For years now, the free software movement has shifted from making progress in the face of new threats to getting better at making excuses to do nothing.
There are a few things to be hopeful about -- despite my condemnation of Free software supporters who deny the role of copyright in all this or the need for reform (one does imply the other, really!) Some high-profile advocates (such as David Revoy) do stand for both. Despite my criticism of what Trisquel has turned into and my overall pessimism about the GNU project itself, I continue to take note of the efforts by Hyperbola -- which please me a great deal.
"If you put all these together, at least 163 projects -- or 48% of the GNU Project -- is using software that's based on Microsoft GitHub."It's the fact that the overall movement does not understand the significance of the previous paragraph, and the trouble they will go to in order to minimise its points when brought up that trouble me. I do not hold any major hope for the free software movement itself. I strongly believe that years from now, only a (sincere) effort to reboot Free software -- an effort much unlike the fake, corporate sellout "Open source" will save the movement.
It troubles me that the original movement does not do much to encourage or cultivate the growing effort from this new breed of support, but this fits the model of what typically happens to old 501(c)(3) organisations. I believe the only long-term hope for Free software is grassroots -- Open source is astroturfed, and we should be careful to watch for more "help" from big corporations in activists' clothing.
As for GitHub, it's true that Microsoft is not the only threat to free software. But underestimating it is dangerous, and reeks of hubris. Even if apathy doesn't kill GNU, it certainly doesn't make it stronger. Apathy begets apathy, and if the Free software movement itself doesn't take threats like this seriously, one has to wonder why people will consider it important in the future. If it's going to become just a way of gluing stuff from GitHub together, why not simply call it Microsoft GNU?
"The time to step up and do something isn't in 5 years. It's right now."Of course software freedom matters either way. But will GNU developers continue to stand up for freedom, or will they settle for words and excuses when action and firmness are needed? Their choice to trust Microsoft will likely be downplayed before it is ever rectified.
And I know they will vary on this, but if the GNU developers care so little about what happens to this software, how can we be sure they still care about your freedom? The time to step up and do something isn't in 5 years. It's right now.
Long live rms, Save the GNU, and happy hacking. ⬆
Licence: Creative Commons CC0 1.0 (public domain; Except for fair use quotes from mailing lists, which are Copyright their respective authors).