Free Software Foundation Aims To Launch Code Hosting / Collaboration Platform This Year

[ssokolow]

50 years from now we probably wont have any distro currently in circulation today. But we will have GNU/Linux. After all, it is 100% open, no-one can take that away from us in theory.

Have you actually looked at what constitutes the GNU portions of a modern distro like Debian? It's not just the stuff under the systemd umbrella that's non-GNU. The stuff people think of as what systemd replaced is non-GNU (eg. sysvinit, OpenRC, the non-systemd syslog implementations like rsyslogd, vixie-cron, dhcpcd) as are a long tail of supporting utilities everyone depends on sooner or later, like e2fsprogs, bzip2, libmagic, all of the texlive stuff that GNU texinfo depends on, xz-utils, procps, vim, sudo, smartmontools, OpenSSL, OpenSSH, NSS, iptables, libarchive, CUPS, SANE, cURL, rsync, Samba, Info-ZIP, ntfs-3g, traceroute, and libexpat.

I wasn't just being lazy when I implicitly said that GNU's contributions to what you expect from a modern Linux have alternatives in a combination of musl-libc and BusyBox. You don't see someone referring to macOS as something like "GNU/macOS" just because GNU are the maintainers of the gzip implementation everyone uses.

Bear in mind that any Linux-specific userland bits aren't GNU bits. Hence my mentioning of things like e2fsprogs and procps. Likewise, pretty much the only really noteworthy thing specifically related to portability that GNU contributes, rather than being portable as a secondary facet of its function like GCC, is autoconf, which people are retiring in favour of things like CMake these days.

Beyond that, aside from copyright assignment, D-Bus, pkg-config, desktop-file-utils, xdg-user-dirs, Cairo, Mesa, Pixman, Plymouth, X.Org, fontconfig, libinput, uchardet, GStreamer, Poppler, PulseAudio, ModemManager, AppStream, Avahi, colord, Flatpak, FreeType, HarfBuzz, LDTP, libburn, PackageKit, Telepathy, udisks, and a ton of other things share about as much relation to FreeDesktop.org as a lot of GNU things do to the GNU project and the FSF. (ie. they were either created under the aegis of FDO or donated to it)

I'd say they have at least as much claim as the FSF, so maybe we should be calling it XDG/Linux. After all, glibc is only one package, while XDG provides a forest of packages and standards which define the APIs that portable software depends on, and you don't see them clamoring for it to be called "GNU/POSIX/Linux", so why should it be "XDG/glibc/Linux"?

Again, I wasn't being hyperbolic when I said that Stallman uses some very tortured logic to justify giving GNU top billing over all the other userland components. It's clear that, perfectly in line with his personality, he's refusing to concede that because they took a "make it perfect" approach to Hurd, the OS's name won't be "GNU".

In fact, there's a blog post I've been trying to re-locate for years which tallied it all up, including drawing graphs for things like "total lines of code", "total bytes", etc., to show just how much Stallman had to torture his logic to justify GNU getting that spot.

Besides, the problem isn't getting people to say "GNU/Linux" rather than "Linux", it's getting them to say "Ubuntu Linux" rather than "Ubuntu" and, as I said, when I say "Linux", I'm explicitly including distros that use no GNU componentry aside from tertiary bits like gzip, yet still "fit the silhouette". The overton window has to be moved before your efforts will be more than just counterproductive.

[kpedersen]

Have you actually looked at what constitutes the GNU portions of a modern distro like Debian? It's not just the stuff under the systemd umbrella that's non-GNU.

I see what you are saying but there is still a whole lot more GNU stuff in there than anything else (The system compiler is a fair chunk of that). If the weightings do change and Systemd replaces everything, it may sound like a joke but systemd/Linux isn't actually a bad name.

But in some extreme cases like if we ever did manage to get Linux running with a Windows userland, I do agree with you; calling it GNU/Linux in the standard way would be odd. Instead something like Windows/Linux.

But converse to that if we got the majority of what we use now in a typical Linux distro running with Microsoft's NT kernel, then yeah, why not GNU/NT.

<userland>/<kernel> seems to make sense. Yes, the best we can do is use the "majority" as the userland label. For example for ages FreeBSD, OpenBSD used the GNU compiler, but it was still predominantly a BSD userland.

[mulenmar]

As for Criterion A9, (Insists that each nontrivial file in a package clearly and unambiguously state how it is licensed.), I agree with Drew that a COPYING or LICENSE file in the project root should be all that's insisted on. Anything more is too onerous and, depending on the file formats involved, may not be possible.

While I agree on the rest, calling this onerous is silly at best, and disengenious at worst.

Find files, grep them for common license keywords, echo "license not detected in file 'foo', please verify manually" for text (source files/headers, etc.

I suspect there's something in imagemagick for images, to search for tags, but I do not know. Sounds like a good project! Or add the functionality to file?

Or, simply have a defined folder structure, and have the script check for the existence of a LICENSE file... and echo whether it was found or not.

UNIX-alikes are real operating systems, with tools for easily doing and checking this tedious stuff. Just requires a minimal amount of creativity and moderate checking for gotchas.

[ssokolow]

I see what you are saying but there is still a whole lot more GNU stuff in there than anything else (The system compiler is a fair chunk of that). If the weightings do change and Systemd replaces everything, it may sound like a joke but systemd/Linux isn't actually a bad name.

That statement is exactly why I lament not bookmarking that old post that did a breakdown of things. I have no handy citation, but GCC is the only thing that makes for "a whole lot more GNU stuff in there than anything else". If you omit GCC, then X.org alone is bigger than all the GNU stuff combined. (And, for a typical binary distro install, unless you're a C or C++ programmer, having the compiler installed means that the distro failed in their mission.)

GNU may provide the most commands, but counting by number of commands is unfair to BusyBox... especially when the UNIX design philosophy encourages trivial commands like echo, yes, and cat. Bytes or lines of code, minus comments, is much more reasonable.

That's why I called Stallman's logic tortured when I said that he justifies GNU's place in the name by arguing that an OS should be defined as including the compiler and excluding the GUI, regardless of how OSes are actually installed and used in reality. (Remember, he coined this at a time when you have to pay good money for a Windows compiler, and even if Programmer's Workbench was free (which it may not have been at that time), you still had to send away to Apple for it and at least pay for shipping.)

<userland>/<kernel> seems to make sense. Yes, the best we can do is use the "majority" as the userland label. For example for ages FreeBSD, OpenBSD used the GNU compiler, but it was still predominantly a BSD userland.

Except that, as I said, GNU/Linux also has too many syllables to catch on... especially when you pronounce the slash (which is awkward in and of itself) to make it clear that GNU is not a distro name or the vendor responsible for developing the Linux kernel. We have enough trouble getting people to say "Ubuntu Linux" rather than "Ubuntu".

You have to take the human factors into account. (That's why, here in Canada, we pronounce "kilometer" as "kəLAWmətər". If you successfully pushed people to say "GNU slash Linux", they'd probably turn it into something like "G'nələnəx" in an effort to condense it down to something quicker and easier to pronounce. Calling it "Linux" is equivalent to how people create slang abbreviations of longer words for use in day-to-day speech.)

...and just trying to get people to know that they're supposedly abbreviating GNU/Linux is "being that guy" because it's such an awkward and technical thing. Stallman needs a marketing guy.

[ssokolow]

While I agree on the rest, calling this onerous is silly at best, and disengenious at worst.

Find files, grep them for common license keywords, echo "license not detected in file 'foo', please verify manually" for text (source files/headers, etc.

I suspect there's something in imagemagick for images, to search for tags, but I do not know. Sounds like a good project! Or add the functionality to file?

Or, simply have a defined folder structure, and have the script check for the existence of a LICENSE file... and echo whether it was found or not.

UNIX-alikes are real operating systems, with tools for easily doing and checking this tedious stuff. Just requires a minimal amount of creativity and moderate checking for gotchas.

My point is:

1. I shouldn't be expected to reinvent that wheel.
2. You'll have trouble convincing people to use your hosting if you enforce that people do that.
3. I don't want to drive away potential Windows-using contributors.
4. Depending on the programming language, it can be a pain to keep that from resulting in "every single page of the auto-generated API documentation starts with a big, annoying license declaration blob".
5. In some ecosystems, you'll draw ire if you "unnecessarily" alter the MD5/SHA1/etc. hash of the image files, reducing the utility of indexing systems which don't decode and hash the raw pixmap of every image... and that explicitly includes altering the embedded metadata.

You want to make it a built-in linter that runs on every upload, and fires off a warning e-mail, combined with multi-platform builds of an open-source tool to do the check offline? We can talk... but it has to be possible to ignore-list things like *.png if you want it to see success outside "This is the self-hosted code-hosting service for projects under our umbrella. Requring these license standards is part of the same policy that you run prettier/autopep8/gofmt/rustfmt/etc. before you commit."

[mulenmar]

My point is:[*]I shouldn't be expected to reinvent that wheel.

Fair, it should be done as a reusable library anyway.

[*]You'll have trouble convincing people to use your hosting if you enforce that people do that.

"Hey, our curator script will automatically be run upon your tree to detect common problems We suggest doing so on your end first, to reduce load on our end and to avoid your tree being marked as not visible to anyone but you. Don't like it, get lost. Love, Stallman".

Seems legit.

[*]I don't want to drive away potential Windows-using contributors.

This is specifically for FSF-hosted projects, yes? The percentage of contributors using Windows for anything but porting would be very small, and have the appropriate tools installed, or would be working inside VMs running a real operating system.

Even Microsoft is winding down Windows and porting their stuff to other operating systems. They'll just keep Azure for hosting and release their own, closed-source compatibility libraries on a Linux or BSD base, assuming Fuschia doesn't prove more profitable.

[*]Depending on the programming language, it can be a pain to keep that from resulting in "every single page of the auto-generated API documentation starts with a big, annoying license declaration blob".

Then don't auto-generate the documentation. Have a script to run on the client-side to do that on their own machine, and save the space and load on the server.

[*]In some ecosystems, you'll draw ire if you "unnecessarily" alter the MD5/SHA1/etc. hash of the image files, reducing the utility of indexing systems which don't decode and hash the raw pixmap of every image... and that explicitly includes altering the embedded metadata.

Tough, do it once and be done with it, with automated logging and compression thereof... and checks for space to do the work, first, of course.

Perhaps an extension to a file system, to have inodes specify the license without altering the file, is in order here?

Or just use the simple option, and have commit scripts which require inputting a keyword to specify the license, validate that it is the one desired AND is one of the ones the project has defined as valid for the file type, and slap the result in a file in the same directory listing the non-text file's name and license. That just pushes the work from filesystem and utility maintainers to the FSF, so whether it proves simple with the not-keeping-abreast-of-how-besf-to-solve-problems tyrant still in charge is a whole separate matter.

You want to make it a built-in linter that runs on every upload, and fires off a warning e-mail, combined with multi-platform builds of an open-source tool to do the check offline? We can talk... but it has to be possible to ignore-list things like *.png if you want it to see success outside "This is the self-hosted code-hosting service for projects under our umbrella. Requring these license standards is part of the same policy that you run prettier/autopep8/gofmt/rustfmt/etc. before you commit."

I would prefer a set of AGPL-licensed POSIX scripts which run automatically the contributor's end, before the commit ever gets pushed to the hosting service. The FSF doesn't have unlimited money for bandwidth and processing, then firing off emails. Such a design doesn't sound scalable, to me.

And no ignoring, or at most only ignore until the problem is solved at the correct level., as suggested earlier.

Of course, given how late it is now, my ideas here may be completely laughable!

[mulenmar]

Can I please have my post approved? I can't even edit it for typos.