I have posted a note about the way FSF (America) started acting like a dictator with the GNU project and the software maintained under its umbrella, which lead to the splitting of GnuTLS — which is something that Nikos is not currently commenting on, simply because he’s now negotiating what’s going to happen with it.
Well, the next step has been Paolo stepping down as GNU maintainer, after releasing a new version of sed. This actually made me think a bit more. What’s going on with sed, grep and the like? Well, most likely they’ll get a new maintainer and they’ll keep going that way. But should we see this as an opportunity? You probably remember that some time ago I suggested we could be less GNU — or at least, less reliant on GNU.
So while I’m definitely not going to fork sed myself – I have enough trouble with unpaper especially considering that while in America I didn’t have a scanner, which is a necessity to develop it – but there definitely is room for improvement with it. First of all, it would be a good choice to start with, to get rid of the damn gnulib and eventually implementing what is an extension of glibc itself as an external library (something like libgsupc). Even if this didn’t work on anything but FreeBSD and Linux, it would still be an improvement, and I’m pretty sure it would be feasible without needing that hairy mess of code that, in the source code for sed takes five times as much as the sed sources themselves — 200KiB are the sources for the program, 1.1MiB is the gnulib copies.
Having a new, much less political project to oversee the development of core system utilities would also most likely consolidate some projects that are currently being developed outside of GNU altogether, or simply don’t fit with their scope because they are Linux-specific, which would probably make for a better final user experience. Plus things like keeping man pages actually up to date instead of relying on the info manuals, would almost certainly help!
So can any of you think of other ways to improve the GNU utilities by breaking out of GNU’s boundaries (which is what Nikos and Paolo seem to be striving for), maybe it is possible to get something that is better for everybody and Free at the same time. Myself I know I need to spend some time to fix the dependency upon readline that is present in GnuTLS just for the utilities..
Not sure I’d be in a rush to fork yet, probably best to see how things pan out.I think there are a few lessons to be learned though, especially with GnuTLS. The problem they had was that they ended up being limited in their ability to accept code by the absolute requirement for copyright assignment. Based on the -nfp feedback from Greg and others I’m becoming more and more convinced that it would be a mistake to try to require assignment. With projects like eudev it would be pointless as it will be a long time before Gentoo-originated code gets anywhere near 50% coverage. I’m thinking something more similar to what is done with Linux might make sense, and perhaps doing what KDE does and letting contributors optionally sign something similar to the FSFe FLA. If we do that we should probably make it clear that all future contributions are GPLv2+ or something so that we have more discretion in the future (I think the intent in the social contract was to always leave the door open to “upgrading” licenses, but without assignment that needs to be done at the time code is accepted).That said, I think people are over-reacting to the FSF’s hold on GnuTLS. Nikos said in his blog that he didn’t have any plans to change licenses or anything like that, which is about the only thing copyright ownership really impacts. He is already moving to non-FSF infrastructure as well. It seems like the only real contention is over the name “GnuTLS” and that actually has nothing to do with copyright – that is a trademark issue. While per the article on LWN there are some other precedents of non-Gnu projects using the name, I think the FSF does have a legitimate beef there. If somebody wants to fork Gentoo and call it Gentoo they’re going to have legal problems as well. Trademark enforcement in FOSS projects is nothing new – just look at the Mozilla branding requirements.Paolo’s issues tend to be more with micromanagement of development decisions, like the use of C++ and such. I don’t really see that as being a big deal for Gentoo, as in general we’re pretty liberal with letting project teams run with the ball. Sure, stuff like bash vs sh has come up, but in the end those doing the work basically get to call the shots within reason. I think the bottom line here is that we need to be practical – those doing the work need to have a lot of latitude or nobody will be doing the work.
Rich, with this comment you seem to have beaten any possible record in missing the point — since you spent two out of three paragraphs discussing other stuff from what I posted, and the one that does get into it is the shortest of the three. Congratulations, you ‘re probably the nearest thing to a troll.I wouldn’t want to discuss Gentoo here since this post *is not tagged for Gentoo* but let’s me just say that I guess you finally “saw the light”:https://blog.flameeyes.eu/2… of what I posted over a month ago. Glad to see that. You still seem to have quite a problem regarding trademarks though.As I “already told you”:https://blog.flameeyes.eu/2… you cannot compare the Gentoo Linux (again, not Gentoo — please verify that on nfp I suppose) trademark with GNU since the latter *has not been registered*. It would be all fine and dandy with trademark enforcement, Mozilla-style, if FSF themselves didn’t complain to Mozilla for _their_ enforcement before.And then where the heck did you find the reason to say that micromanagement is not a big deal for Gentoo? I didn’t write about Gentoo as I said so you’re once again talking out of your ass. If anything, Gentoo has the opposite problem and it shows. The council steps in on sometimes trivial stuff and forgets the general oversight, but that’s the way it is I guess.
Well, I said many times which are my gripes regarding GNU:- horrible coding style- horrible source code management (Changelog, using CVS (or svn))- tendency to be holy-than-everybody-else- misusing their own tools (e.g. gcc autotools usage)I would welcome having something interoperable and *lean* replacing some monsters. The problem I’m seeing is that for many situation once they are pressed to do something they do just rush in a direction with dubious results.We’ll see next year.
You forgot bzr..
gnulib is the last of my worries, in fact I was the one who converted sed and grep to use it.It looks like a pain, but it is really like autotools–it is better than everything else if you are going to support obscure platforms. And things like coreutils (and sed, grep, bison, etc.) are really the kind of software that still gets compiled on Solaris 8, HP-UX, or worse.