A turning point for GNU libc
| Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net. |
The kernel may be the core of a Linux system, but neither users nor applications deal with the kernel directly. Instead, almost all interactions with the kernel are moderated through the C library, which is charged with providing a standards-compliant interface to the kernel's functionality. There are a number of C library implementations available, but, outside of the embedded sphere, most Linux systems use the GNU C library, often just called "glibc." The development project behind glibc has a long and interesting history which took a new turn with the dissolution of its steering committee on March 26.
In its early days, the GNU project was forced to focus on a small number of absolutely crucial projects; that is why the first program released under the GNU umbrella was Emacs. Once the core was in place, though, the developers realized they would need a few other components to build their new system; a C library featured prominently on that list. So, back in 1987, Roland McGrath started development on the GNU C library; by 1988, it was seen as being sufficiently far along that systems could be built on top of it.
By the time the Linux kernel came around in 1991, GNU libc was, like many other GNU components, the obvious choice for those working to build the first distributions. But, while GNU libc was a good starting point, it quickly became clear that (1) it still needed a lot of work, and (2) the GNU project's management style was, in typical fashion, making it hard to get that work done and merged. So, early on in the history of Linux, the GNU C library was forked and a Linux-specific version ("Linux libc") was maintained and shipped with Linux distributions.
The GNU project was rather slow to come around to the idea that Linux was the system that they had been trying to build all these years; they continued to develop their C library on their own, despite the fact that Linux was not using it. Early on most of the work came from Roland, but, slowly, other contributors appeared; the first contribution from Ulrich "Uli" Drepper appears to have been made in September, 1995. Early 1997 saw the first glibc 2.0 release; by then, most commits were made by Ulrich (though the code sometimes came from others).
While Linux libc had been adequately maintained, it had not seen vast amounts of new development work. There came a point where it became clear that, in fact, glibc 2 was a better C library in many ways. Distributors of Linux came to the conclusion that the time had come to switch back to the GNU library and, for all practical purposes, simply abandon the Linux libc project. Those of us who lived through the subsequent transition (as seen in the Red Hat 5.0 and Debian 2.0 releases) still tend to shudder; it was a time when programs would not build and bugs abounded. But things eventually settled down and glibc has been the standard C library for most Linux distributions since.
Glibc has continued to evolve up to the present at varying speeds; during most of this time, the bulk of the work has been done by Ulrich Drepper. Of the nearly 19,000 commits found in the project's git repository (which contains changes back to 1995), over 12,000 were made by Ulrich. Never known for a willingness to defer to others, Ulrich quickly became the decision maker for glibc. The project's steering committee was formed by the FSF in 2001 as a way of asserting some control over the project, but, to a great extent, that control remained in Ulrich's hands. In 2008, Roland described the situation this way:
Four other developers (Andreas Jaeger, Jakub Jelinek, Richard Henderson,
and Andreas Schwab) had the ability to commit "after
approval
". But that approval, in the end, had to come from Ulrich.
One need not look far to find complaints about how Ulrich managed the glibc project. He was never one to suffer fools, and, evidently, he saw himself surrounded by a lot of fools. Attempts to get changes into glibc often resulted in serious flaming or simply being ignored. Developers often despaired of getting things done and simply gave up trying. It is easy to criticize Ulrich's attitude at times, but one should also not lose track of all the work he got done. This includes steady improvements to glibc, big jumps in functionality (as with the Native POSIX Thread Library work done with Ingo Molnar) and lots of fixes. Ulrich's work has made all of our systems better.
That work notwithstanding, Ulrich is widely seen as, at best, an unpleasant maintainer who has turned the glibc project into an unwelcoming place. One need not challenge that characterization to point out that glibc actually had a number of problems associated with highly cathedral-style projects: a well-ensconced priesthood, a lack of interest in or awareness of the wider world's needs, etc. At some point, it seemingly became clear to a number of developers associated with glibc that it needed to become a more open project with more than a single point of control. A number of changes have been made to prod it in that direction.
The switch to Git for source code management in May, 2009 was one such change. At that time, the repository was made slightly more open so that non-core maintainers could keep branches there. Ulrich opposed that decision, but Roland responded:
The project started creating separate release branches and putting maintainers other than Ulrich in charge of them. The restricted-access "libc-hackers" mailing list fell into disuse and has been closed down. The use of Fedora as a sort of private testing ground has been halted after things broke one too many times. And a strong effort has been made to encourage more developers and to merge more code. The result is a release history that looks like this:
Release Date Changes 2.3 2002-10-03 3204 2.4 2006-03-06 5276 2.5 2006-09-29 348 2.6 2007-05-15 357 2.7 2007-10-18 446 2.8 2008-04-12 281 2.9 2008-11-13 293 2.10 2009-05-09 344 2.11 2009-10-30 408 2.12 2010-05-03 389 2.13 2011-01-17 261 2.14 2011-05-31 256 2.15 2011-12-23 582
(The 2.15 date is when the release was tagged; the announcement was, for whatever reason, not sent out for a few months). The 2.15 release suggests that development activity is on the increase after a sustained low point. Indeed, it is at its highest point since semi-regular releases began in 2006. Activity since 2.15 (483 commits, as of this writing) continues to be high by recent historical standards; perhaps more tellingly, only about 25% of those commits came from Ulrich. Given that he accounts for over 60% of the changes from 2.10 to 2.14, that suggests that a significant shift has taken place.
Also significant is the fact that Ulrich left Red Hat in September, 2010; according to his LinkedIn page, he is now "VP, Technology Division at Goldman Sachs." One can easily imagine that his new position might just have requirements that are unrelated to glibc maintenance. So a drop in participation is not entirely surprising; what is significant is that a growing community is more than taking up the slack.
The culmination of these trends came on March 26, when Roland announced that there was no longer any need for a glibc steering committee:
Glibc will remain a project under the GNU umbrella; Roland, along with Joseph Myers and Carlos O'Donell, will be the official GNU maintainers. But that role will give them no special decision-making powers; those powers are meant to be exercised by the project's development community as a whole. David Miller (an active glibc contributor) was quick to celebrate this change:
David also hinted that one other possible obstacle to contribution - the requirement to assign copyrights to the Free Software Foundation - is also being worked on, though the form the solution might take is unclear. Other developers are already talking about working to merge at least some of the changes from the EGLIBC fork back into the glibc mainline and reopening old bugs and change requests.
So the GNU C library project has moved into a new phase, one where, for the
first time in its long history, it will not be under the control of a
single developer. It will be interesting to watch where things go from
here. If the project succeeds in building robust community governance and
shedding its hostile-to-contributors image, the pace of development could
pick up considerably. Given the crucial position occupied by glibc on so
many systems, these changes are almost certainly a good thing.
(Log in to post comments)
A turning point for GNU libc
Posted Mar 28, 2012 16:13 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Can we:
1) Convert between title case/lower case in a specific locale (opened by iconv_open)
2) Convert between UTC and arbitrary timezones without changing a global variable.
3) Get the next/previous DST change instant (and the DST changes history in general) for a specific timezone.
Please?
A turning point for GNU libc
Posted Mar 28, 2012 16:19 UTC (Wed) by cmorgan (guest, #71980) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 16:25 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]
If you want to use strlcpy/strlcat, you already can; you just have to link with a different library (libbsd). If your project standards forbid strncat, #define it to DONT_USE_strncat_YOU_IDIOT in some widely-included header.
A turning point for GNU libc
Posted Mar 28, 2012 16:47 UTC (Wed) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Mar 29, 2012 2:05 UTC (Thu) by apoelstra (subscriber, #75205) [Link]
Plus, these sorts of pedantic programmers are certainly capable of using strcat safely (which is possible to do, unlike with gets()).
A turning point for GNU libc
Posted Jan 1, 2013 13:25 UTC (Tue) by shentino (guest, #76459) [Link]
anyone trying to replace them will do nothing more than just rock the boat.
A turning point for GNU libc
Posted Mar 28, 2012 17:17 UTC (Wed) by arjan (subscriber, #36785) [Link]
seriously, everyone who wants to outright ban them does not think it through.
(and btw the glibc version of strcpy and co actually do buffer overflow checks with the help of the gcc compiler for various cases)
A turning point for GNU libc
Posted Mar 28, 2012 17:47 UTC (Wed) by jzbiciak (guest, #5246) [Link]
I guess you passed over the extensive, erm, discussion over here: https://lwn.net/Articles/488032/
A turning point for GNU libc
Posted Mar 28, 2012 19:17 UTC (Wed) by cmorgan (guest, #71980) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 21:00 UTC (Wed) by atai (subscriber, #10977) [Link]
A turning point for GNU libc
Posted Mar 29, 2012 12:38 UTC (Thu) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Mar 29, 2012 12:57 UTC (Thu) by mina86 (guest, #68442) [Link]
A turning point for GNU libc
Posted Mar 29, 2012 20:30 UTC (Thu) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Mar 29, 2012 0:02 UTC (Thu) by Richard_J_Neill (guest, #23093) [Link]
A leading zero practically NEVER means the user intentionally wants to work in base 8, it just means they did something naive with string-splitting or data-entry. Perhaps the user entered the reading from a digital-scale, complete with leading zero. Or they took a string such as $7.09 and parsed it as "trim off the leading '$', split at the decimal point, multiply the first number by 100, and add the two together, to get a result in cents".
I'd consider that leading-zero-means-octal is a nasty case of technical debt that we still be causing bugs in 100 years if we don't fix it.
One way would be to support a new notation, similar to the "0x" notation. Numbers beginning "0o" (that's a letter 'o') would be recognised as octal. Then we spend 5 years transitioning the existing legitimate instances of octal numbers (file permissions) to the new syntax, then for 5 years, make the old format illegal, then in 10 years time, we can start treating leading zeros as they were meant to be treated.
[At the same time, can I plead for a "streq()" function, being defined as "!strcmp()" ]
A turning point for GNU libc
Posted Mar 29, 2012 4:52 UTC (Thu) by slashdot (guest, #22014) [Link]
AFAICT POSIX 2008 forbids that, and requires atoi to support only decimal numbers.
At any rate, changing that is probably highly unwise, as it might break stuff.
A turning point for GNU libc
Posted Mar 29, 2012 10:37 UTC (Thu) by Richard_J_Neill (guest, #23093) [Link]
I agree that we can't change it right away. That's why I suggest adding a new prefix, "0o" to be used in the very rare case where the programmer deliberately intends to use octal. That wouldn't break anything, and over perhaps 5 years, people could migrate.
A turning point for GNU libc
Posted Mar 29, 2012 20:53 UTC (Thu) by cmccabe (guest, #60281) [Link]
> that leading zeros make strings into Octal? This behavior is
> implemented so fundamentally in eg atoi() that many other programming
> languages, even those that do dynamic typing, inherit the bug. If I
> write "064", I generally don't mean "52"!
It's a standard, like the QWERTY keyboard and the English language. Sorry, it's not going anywhere.
> At the same time, can I plead for a "streq()" function, being defined
> as "!strcmp()"
Why don't you define it yourself? It's a one-line function.
A turning point for GNU libc
Posted Mar 29, 2012 21:03 UTC (Thu) by cmccabe (guest, #60281) [Link]
However, strcpy also has its uses. Sometimes you really do know the length of the source string, and you know it fits in the destination.
strcpy() / strlcpy() / asprintf()
Posted Mar 30, 2012 11:07 UTC (Fri) by abacus (guest, #49001) [Link]
But why to add strlcpy() to glibc while the function asprintf() is already present in glibc since considerable time ?
strcpy() / strlcpy() / asprintf()
Posted Mar 30, 2012 12:50 UTC (Fri) by nix (subscriber, #2304) [Link]
strcpy() / strlcpy() / asprintf()
Posted Mar 30, 2012 15:56 UTC (Fri) by nybble41 (subscriber, #55106) [Link]
It seems to me like asprintf() should be easy to implement in terms of two calls to vsnprintf():
int vasprintf(char **strp, const char *fmt, va_list ap)
{
va_list ap_copy;
char *str;
int bytes;
char nul;
/* Determine the amount of memory required to format the string */
/* vsnprintf() returns the space required, but only stores the NUL. */
va_copy(ap_copy, ap);
bytes = vsnprintf(&nul, 1, fmt, ap_copy);
va_end(ap_copy);
if (bytes <= 0)
return bytes;
str = (char*)malloc(bytes);
if (!str)
return -1;
/* Format the string into the destination buffer */
bytes = vsnprintf(str, bytes, fmt, ap);
if (bytes <= 0)
{
free(str);
return bytes;
}
/* No errors; store pointer to destination buffer and return its size. */
*strp = str;
return bytes;
}
int asprintf(char **strp, const char *fmt, ...)
{
int bytes;
va_list ap;
va_start(ap, fmt);
bytes = vasprintf(strp, fmt, ap);
va_end(ap);
return bytes;
}
Is there any reason this implementation wouldn't work? (Ignoring minor issues/typos; I'm making this up as I go.)
strcpy() / strlcpy() / asprintf()
Posted Mar 30, 2012 17:50 UTC (Fri) by nix (subscriber, #2304) [Link]
strcpy() / strlcpy() / asprintf()
Posted Mar 31, 2012 21:10 UTC (Sat) by lacos (guest, #70616) [Link]
(SUSv1 doesn't have snprintf(). Once I needed to compile a glibc-oriented program on OSF/1 4.0E, which one might have consider a reference implementation of SUSv1, even though it wasn't formally certified. The program needed snprintf() and there was none, so I printed the string first to /dev/null (for the size), then fully to a malloc()'d area, then copied the bytes that had room, then free()'d the area. ... Sorry if this sounds trivial and/or retarded :))
strcpy() / strlcpy() / asprintf()
Posted Apr 5, 2012 8:36 UTC (Thu) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 20:06 UTC (Wed) by josh (subscriber, #17465) [Link]
glibc already contains far more than it should. Arguably, it should contain only the bare-minimum interfaces for compatibility with standard C and POSIX; anything else ought to live in another library.
A turning point for GNU libc
Posted Mar 28, 2012 20:11 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Because libc already has to do this! glibc has to read timezone database, so it can translate between UTC and current timezones. glibc has to support all kinds of encodings for iconv to work and so on.
But every single real-world program working with Unicode has to rely on third-party libraries. Ditto for timezone handling.
>glibc already contains far more than it should. Arguably, it should contain only the bare-minimum interfaces for compatibility with standard C and POSIX; anything else ought to live in another library.
Yes, that would be one way. But it should have been done from the start, now it's just not possible because of compatibility issues.
So the next best thing is to create proper and useful interfaces so all the existing complexity is at least not wasted.
A turning point for GNU libc
Posted Mar 29, 2012 12:43 UTC (Thu) by nix (subscriber, #2304) [Link]
I'm not sure about proper unicode handling: doing it right is very difficult. Even doing case conversion right is difficult, and you can already case-convert with iconv() with no new APIs, only a new convention for 'locales' whose only difference from the standard ones is that they transliterate case. (But doing it that way does seem like a kludge.)
A turning point for GNU libc
Posted Mar 30, 2012 21:58 UTC (Fri) by justincormack (subscriber, #70439) [Link]
A turning point for GNU libc
Posted Mar 30, 2012 23:46 UTC (Fri) by nix (subscriber, #2304) [Link]
The tz-manipulation code must stay, because widely-used functions in the exported API use it (notably tzset(), gmtime() and localtime()).
The locale support is very definitely not legacy: the C library is where all the internationalization code is located (found in libintl on many other Unix platforms). It is part of the API and ABI, used by every single internationalized program (which is most of them, these days) and can never ever be removed. (And printf() needs locale support for international printing of the decimal point and thousands grouping characters, and for the I alternative-output-digit flag character.)
A turning point for GNU libc
Posted Mar 31, 2012 10:01 UTC (Sat) by mpr22 (subscriber, #60784) [Link]
setlocale() and strcoll() (among other locale-related things) are both defined as part of the 1990 and 1999 versions of the ISO C standard, and I am not aware of them having been removed from the 2011 version. Therefore, every compliant hosted implementation of the C programming language is obliged to provide setlocale() and strcoll(), and by saying you don't want locales in your low-level libraries you are saying you don't want a compliant hosted implementation of the C programming language.
A turning point for GNU libc
Posted Apr 5, 2012 8:29 UTC (Thu) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Mar 29, 2012 13:02 UTC (Thu) by mina86 (guest, #68442) [Link]
As for past changes, this is doable, but I dunno if tzdata actually stores all the historical data.
A turning point for GNU libc
Posted Mar 29, 2012 19:34 UTC (Thu) by Jonno (subscriber, #49613) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 16:38 UTC (Wed) by nix (subscriber, #2304) [Link]
In its early days, the GNU project was forced to focus on a small number of absolutely crucial projects; that is why the first program released under the GNU umbrella was Emacs.Bwahaha. I suspect more significant here was that Emacs already existed (and was the trigger for the whole thing).
Everything else released early on was pretty crucial infrastructural OS-core stuff.
A turning point for GNU libc
Posted Mar 28, 2012 17:50 UTC (Wed) by jzbiciak (guest, #5246) [Link]
Now only if that system had a decent editor. ;-) ;-)
A turning point for GNU libc
Posted Mar 29, 2012 12:44 UTC (Thu) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Mar 30, 2012 22:32 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
A turning point for GNU libc
Posted Mar 30, 2012 23:48 UTC (Fri) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Mar 31, 2012 0:20 UTC (Sat) by flewellyn (subscriber, #5047) [Link]
A turning point for GNU libc
Posted Apr 5, 2012 8:26 UTC (Thu) by nix (subscriber, #2304) [Link]
... dependency on section names and ordering. Dependency on symbol names (it knows the name of the sole symbol in a special object file linked in last of all). Inverse runtime linking, with a short, ugly, and inadequate hardwired list of relocations. Massive platform-specific ifdeffery. Special-cases throughout the source code for things that will be dumped into the executable and stay read-only ('pure space') versus those that will not. All the signs of code that was neat when it was written (if you believe the (C), in 1985) but has evolved since then in the ugliest imaginable fashion.
Quite like a lot of the rest of the insides of Emacs, really. (Parts of it are neater. None is uglier.)
Ew, I shouldn't have looked at that so early in the morning. I feel quite queasy now.
A turning point for GNU libc
Posted May 16, 2013 15:12 UTC (Thu) by karya (guest, #71446) [Link]
A turning point for GNU libc
Posted May 21, 2013 14:24 UTC (Tue) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Mar 30, 2012 13:04 UTC (Fri) by civodul (guest, #58311) [Link]
>
> Bwahaha. I suspect more significant here was that Emacs already existed (and was the trigger for the whole thing).
>
> Everything else released early on was pretty crucial infrastructural OS-core stuff.
Indeed.
It should be mentioned that FSF-paid developers, including Roland, were initially developing libc for the GNU operating system, aka. GNU/Hurd. The Linux "port" came later with the work of Ulrich Drepper and others.
A turning point for GNU libc
Posted Mar 30, 2012 13:17 UTC (Fri) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 17:24 UTC (Wed) by arjan (subscriber, #36785) [Link]
Combine that with an absolute requirement of binary compatibility, and frankly, I appreciate greatly a set of glibc maintainers who are on the conservative side. Any new API is going to be there forever, unchangable.
That doesn't mean that progress should not be possible, and it doesn't mean that the atmosphere shouldn't be open and pleasant, but in many ways, the glibc guys and the kernel filesystem guys need to share a mindset of being extremely careful and conservative.... not one of doing wild things just because you can.
the debate about strcpy/strncpy/strlcpy is one of those messy ones. on first sight, strlcpy is an obvious right answer. however, when you look deeper at it, it's not true.... strlcpy can in fact be more dangerous. strcpy_c and co are actually better ideas, and glibc's strcpy() has a built in "abort if we know we're overflowing" logic that works together with gcc to detect many of the more simple buffer overflow case. (and it *aborts*, it does not silently continue with what is effectively corrupted data).
If Ulrich and co had added strlcpy early on, we'd now be wondering how such a stupid decision could have been made because it now has to be deprecated ;-(
A turning point for GNU libc
Posted Mar 28, 2012 17:35 UTC (Wed) by cmorgan (guest, #71980) [Link]
How is strlcpy more dangerous? It behaves more like snprintf and friends in that it always adds null termination.
In any case, string handling imo is a weak and error prone area of c and anything is better than functions that sometimes null terminate, sometimes don't, don't perform bounds checking etc.
I'm not suggesting the original ones be removed, clearly that would break a lot of existing software, but lets provide some better and less error prone alternatives without getting caught in the whole "well the other functions work" or "everyone uses them" trap that seems to hold up progress.
Chris
A turning point for GNU libc
Posted Mar 28, 2012 17:39 UTC (Wed) by arjan (subscriber, #36785) [Link]
you really want a strcpy variant that, on overflow, zeroes out the WHOLE THING, and ideally reports a proper, easy to check error return code for it.
if you hit an overflow, you outright DO NOT want to trust what you copied; not in any way.
A turning point for GNU libc
Posted Mar 28, 2012 17:40 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 17:45 UTC (Wed) by slashdot (guest, #22014) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 17:48 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 21:45 UTC (Wed) by dashesy (guest, #74652) [Link]
Accepting the useful strcpy_s however can open the can of worms (strncpy_s and the rest of that family)
A turning point for GNU libc
Posted Mar 28, 2012 18:25 UTC (Wed) by arjan (subscriber, #36785) [Link]
but yes, that's one of the options, and as default behavior it's not all that bad (it means you can have a crash dump collector detect it and send it to the developer team).
Just it's also a death-sentence kind of API, you also want a variant which is "try to see if it fits, but if it doesn't let me know and I'll handle it gracefully"....
A turning point for GNU libc
Posted Mar 28, 2012 17:44 UTC (Wed) by cmorgan (guest, #71980) [Link]
It would be handy if the libc people would see about innovating in that area a little bit. Maybe 3rd party libraries work but why get so stuck on posix as someone else mentioned?
Chris
A turning point for GNU libc
Posted Mar 28, 2012 17:50 UTC (Wed) by arjan (subscriber, #36785) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 19:20 UTC (Wed) by wahern (subscriber, #37304) [Link]
The difference between strlcpy is that the behavior is well-defined as far as the language is concerned. The bad behavior (if truncation is undesired) is between chair and keyboard, and that's a huge step forward from the mess that traditional string routines have _actually_ made.
And truncation isn't silent: if (sizeof buf <= strlcpy(buf, str, sizeof buf)) oops("truncated!");
There, happy?
Most unix systems have strlcpy except Linux and compatriots like HP/UX. Nobody would have even questioned the utility of it if Drepper hadn't been so stubborn. And now somehow strlcpy() is faulted for supposed flaws that exist in almost all C routines, and are _especially_ egregious in the ones that Drepper proposed as alternatives. Just the other week on stackoverflow I saw someone post a memccpy() "alternative" which contained an off-by-one buffer overflow. (They apparently thought memccpy returned a pointer to the terminal character, not a pointer after the terminal character.)
Ridiculous.
And alternatives like strcpy_s from Microsoft are even more idiotic. Have you ever even tried to use them? The entire Annex K is stupid, and not even Microsoft supports the entire Annex even though they sponsored it.
People are entitled to their opinions, but this particular opinion just causes way too much headaches for too many people. You don't see systemd haters trying to keep systemd from shipping, do you? They just don't want to be _forced_ to use systemd. Nobody is forcing you to use strlcpy.
A turning point for GNU libc
Posted Mar 28, 2012 20:03 UTC (Wed) by arjan (subscriber, #36785) [Link]
(having been on the receiving end of such 'security scanner fixes' introducing more bugs than the original code had... I'm no big fan of either strncpy or strlcpy as replacement for strcpy.... especially since the linux strcpy is checking by itself in most of the critical cases already)
"does well to be conservative about adopting a solution"?
Posted Apr 6, 2012 12:58 UTC (Fri) by cjcoats (guest, #9833) [Link]
But see this discussion about GLIBC memcpy() changes at Version 2.11 breaking many existing executableshttps://bugzilla.redhat.com/show_bug.cgi?id=638477with Linus' performance-evaluation (proved it did not create the claimed speedup, and provided alternatives) and remarks about breaking those existing executables (turns out Flash was the most prominent culprit but there were lots of others). [Warning: there's a lot of stuff here...]
And Drepper not only did not care: he said he did the right thing!
FWIW
"does well to be conservative about adopting a solution"?
Posted Apr 6, 2012 15:05 UTC (Fri) by khim (subscriber, #9252) [Link]
Generally compatibility is guaranteed only if programmer follows guidelines. And in this sense Drepper has a point: the memory areas should not overlap. Use memmove(3) if the memory areas do overlap. is listed as requirement for memcpy for at least half-century (perhaps more, but I'm not sure).
Sometimes, if there are a lot of broken programs, bug-to-bug compatibility is important enough to go further - and this is example what happened here in the end as you can see here.
"does well to be conservative about adopting a solution"?
Posted Apr 6, 2012 17:37 UTC (Fri) by dlang (guest, #313) [Link]
"does well to be conservative about adopting a solution"?
Posted Apr 6, 2012 20:15 UTC (Fri) by khim (subscriber, #9252) [Link]
that's a valid argument if the change improves something, but if (as in this case) the change doesn't give any performance improvement, the only 'advantage' of the change is that it breaks existing programs.
Wow. Just… wow. I guess it's time to ask the usual question: are you an idiot or just play one on TV? You were given link - now, please go and read it.
People tend to see message from Linus (which says I bothered to _measure_ the speed, and according to my measurements, glibc wasn't any faster than my trivial version and was likely slower) and immediately switch to Linus is god, GLibC developers are stupid mindset. Which is not justified at all.
Because of course the very next sentence (but I only tested two cases) in the same paragraph flies right over their head and detailed explanation (At last on Core2 we gain 1.83x speedup compared with original instruction sequence and Based on our micro-benchmark small bytes from 1 to 127 bytes, we got up to 2X improvement, and up to 1.5X improvement for 1024 bytes on Corei7) is totally ignored or, at best, hand-waved with hopefully Linus has answered this one appeal to authority.
This is the same never-ending fight between pragmatists and standard hairsplitters. Linus, ever the pragmatist, never rebuffed speedup claim when it was pointed out that he was incorrect (good for him: speedup is very much hardware-dependent and was just unobservable on the hardware he used, it's quite real and measurable on different hardware) but he said quite sensible thing from pragmatist's POV: new version of memcpy may be more efficient, but it's more complex as well thus the usual excuse (we have trivial and fast memcpy and slower, but more robust memmove) no longer applies. But GLibC and GCC developers, ever then nitpickers, say that this makes no sense: spec most definitely says that if copying takes place between objects that overlap, the behaviour is undefined (and even that other OS agrees) so why should they add any such checks to the code which works fine in standard-mandated case?
Note: GLibC guys rolled back change for old binaries pretty quickly when it was found that their improvement broke real programs. After that point it's no longer about “stable ABI” and “backward compatibility”, but about “doing the right thing”.
I think the end result (old programs get the old behavior and new ones should finally fix the bugs in according to the documentation) makes sense in this context. You can say that this is what should have happened from the beginning, but it was not all that obvious that so many programs actually depend on the broken behavior of the old memcpy.
"does well to be conservative about adopting a solution"?
Posted Apr 6, 2012 20:17 UTC (Fri) by corbet (editor, #1) [Link]
...and that's my cue for the usual request: can we please be just a bit more respectful of each other? If you disagree then by all means say so and why. But we don't need to be playing elementary-school name-calling games here.
"does well to be conservative about adopting a solution"?
Posted Apr 6, 2012 20:27 UTC (Fri) by paulj (subscriber, #341) [Link]
A turning point for GNU libc
Posted Mar 31, 2012 21:35 UTC (Sat) by lacos (guest, #70616) [Link]
truncation isn't silent: if (sizeof buf <= strlcpy(buf, str, sizeof buf)) oops("truncated!");
I don't like this. strlcpy() continues to find the end / length of the source string even if the target buffer has ended way earlier. And it does it every single time.
Instead of this, know the length of your source string (which takes a single strlen() in the beginning), and allocate the target buffer accordingly. Or, if the target is a given, and too small, bail out before copying any characters.
A turning point for GNU libc
Posted Apr 3, 2012 0:20 UTC (Tue) by gdt (subscriber, #6284) [Link]
char dst[DST_SIZE];
strlcpy(dst, src, DST_SIZE);
dst[DST_SIZE-1] = '\0';
A turning point for GNU libc
Posted Apr 3, 2012 6:58 UTC (Tue) by smurf (subscriber, #17840) [Link]
What he wants is essentially a string copy which, when the buffer is too small, zeroes the buffer's FIRST byte, not its last.
A turning point for GNU libc
Posted Apr 9, 2012 11:04 UTC (Mon) by gdt (subscriber, #6284) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 20:43 UTC (Wed) by HelloWorld (guest, #56129) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 22:47 UTC (Wed) by wahern (subscriber, #37304) [Link]
Saying "just use glib" is cargo cult programming, IMNSHO. Why would I use a 300k SLoC library just for a saner way to copy a string? Some people like coding in plain, vanilla C, especially when our code has to be ported to many different environments. Getting strlcpy into glibc would be just one less extra burden to carry when trying to write sane, simple, secure code.
And also, why do I need a dynamic string object? Is Linux generally ever going to support file names longer than NAME_MAX characters, or paths longer than PATH_MAX characters? Are DNS labels magically going to become longer than 63 characters, or domains longer than 255 characters? Do my enum-to-human-readable-string mappings need an indefinite buffer?
Most people who code in C aren't doing unbounded string operations. Not every C application or library is an editor or a text processor. In fact, very few are. Don't confuse "C-strings" with "strings". People don't use strcpy or strlcpy to manipulate "strings" (the abstract computer science concept); they use them to manipulate C-strings, a very narrow and well-defined data type which in practice is almost always bounded by a rather small limit.
A turning point for GNU libc
Posted Mar 29, 2012 0:48 UTC (Thu) by geofft (subscriber, #59789) [Link]
Saying "just use glib" is cargo cult programming, IMNSHO. Why would I use a 300k SLoC library just for a saner way to copy a string?Because it's a saner way to do _everything_. If you just want strings, you can go use the Better String Library (bstring), but then you need to go find a better everything else library, too.
Besides, you're cargo-culting a one million SLoC library called glibc, and arguing for the inclusion of more functions in it... if you like "plain, vanilla C", you're welcome to copy strings without glibc. :) (Or with another standard library like dietlibc.)
A turning point for GNU libc
Posted Mar 29, 2012 11:47 UTC (Thu) by jnareb (subscriber, #46500) [Link]
Nb. Git went the way of creating own 'strbuf' micro-library for string manipulation.
A turning point for GNU libc
Posted Mar 29, 2012 7:13 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
Is Linux generally ever going to support file names longer than NAME_MAX characters, or paths longer than PATH_MAX characters?
Absolutely - PATH_MAX is a totally meaningless value.
A turning point for GNU libc
Posted Mar 30, 2012 3:55 UTC (Fri) by wahern (subscriber, #37304) [Link]
But let people continue to use strcpy, and let the exploits continue to roll in. Fortunately they've slowed down over the years, thanks to alternatives like snprintf and people copy+pasting strlcpy, and not so much because people are passing glib string objects to library routines.
A turning point for GNU libc
Posted Mar 29, 2012 16:12 UTC (Thu) by HelloWorld (guest, #56129) [Link]
Glib provides a hell of a lot more than just a sane (well, sane by C standards) string implementation.
> Some people like coding in plain, vanilla C, especially when our code has to be ported to many different environments.
Well, you don't seem to be one of them, as strlcpy is clearly *not* standard C. Besides, how is providing strlcpy going to help with portability? Microsofts C implementation doesn't include it either, so you can't rely on it either way.
> Do my enum-to-human-readable-string mappings need an indefinite buffer?
Of course not, but for that use case, strcpy is perfectly sufficient as the required buffer length is known at compile time.
A turning point for GNU libc
Posted Mar 30, 2012 22:24 UTC (Fri) by jengelh (subscriber, #33263) [Link]
I agree - it has utterly pointless typedefs like gchar (char is standardized by C, you know). Hiding an indirection (behind gpointer) is not nice either.
A turning point for GNU libc
Posted Apr 5, 2012 15:32 UTC (Thu) by welinder (guest, #4699) [Link]
Really?
What, exactly, is standardized about char in C?
* it's a numeric type.
* it is distinct from signed char and unsigned char, but has the same
range of values as one of the two
* it's a magic type for aliasing
* it's the element type of "foo"
* sizeof(char)==1
char c = 0; /* valid */
char c = -1; /* valid, but might not read as -1 */
char c = 128; /* implementation dependent: either valid or undefined */
A turning point for GNU libc
Posted Apr 5, 2012 16:33 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
If you want guaranteed ranges, uint8_t and int8_t are standardized in C99 as integer types with exactly eight bits and (in the signed case) two's-complement representation. Both definitions are required unless the implementation has no compatible integer type.
A turning point for GNU libc
Posted Mar 28, 2012 21:51 UTC (Wed) by jcm (subscriber, #18262) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 17:40 UTC (Wed) by slashdot (guest, #22014) [Link]
Linus Torvalds on Google+:
"one of my (really old) experiences was that even if the patch were to have been acceptable in other ways, glibc required the insane FSF copyright assignment paperwork. Is that also gone?"
David Miller replies:
"This is a known issue and people at various levels are trying to get this sorted out in one way or another. I'm never on top of this since I've had paperwork with the FSF my entire career, and therefore it's never been an issue for me."
"Without going into specifics, the FSF is looking into ways to accommodate this kind of situation, for all projects."
Planning for decades
Posted Mar 28, 2012 18:43 UTC (Wed) by mcoleman (guest, #70990) [Link]
Planning for decades
Posted Mar 28, 2012 20:14 UTC (Wed) by jzbiciak (guest, #5246) [Link]
My understanding is that the FSF wants copyright assignment so that it can unilaterally determine its destiny. It can, for example, decide to begin releasing it under an entirely new license at some point. While it won't eradicate older versions under older licenses, it does make it easy to relicense the whole thing even if the original author didn't submit code with a "version X or later" clause.
I seem to recall that the FSF also argues that it makes it easier to litigate on behalf of the code, although I would counterargue that the critical mass of code that's already there is likely sufficient for litigation purposes. I guess the only sticky points would come down to litigation around a specific contribution that hasn't been assigned to the FSF. I suppose with all the lawsuits out there, that's not outside the realm of possibility. And, to further poke holes in my reasoning, more recent code is more likely to trigger lawsuits than code that's been there for many years, especially if it's based on newer techniques. Older code is more likely to have been vetted against legal issues.
Planning for decades
Posted Mar 28, 2012 20:23 UTC (Wed) by mcoleman (guest, #70990) [Link]
The FSF designed the GPL explicitly to disallow anyone from unilaterally determining the destiny of the code it is applied to. This seems clear from their words and actions.Once you apply the GPL to code you write, you give up almost all possibility of unilateral control of the code. In return, you get that same grant from all future contributors.
Planning for decades
Posted Mar 29, 2012 1:53 UTC (Thu) by smurf (subscriber, #17840) [Link]
True, the copyright holder can do nothing whatsoever about the code that's already out there.
But as the FSF has the copyright on the whole code, the only thing that'd prevent it from releasing proprietarylibc tomorrow is their promise not to do that, which they gave by way of their past policies and activities.
Other organizations which required copyright assignment either never did so (Canonical) or even explicitly state that there's a commercial version (mysql).
Planning for decades
Posted Mar 31, 2012 19:28 UTC (Sat) by giraffedata (guest, #1954) [Link]
You need to distinguish past and future releases.
The distinction is not between past and future releases, but between the code and the project. GPL's provision for forking means the distributor can't control future releases, because anyone can make one. And that's central to GPL's purpose.
But GPL isn't meant to give the public control of a project such as the GNU libc project, and that control is what the copyright assignment is designed to prevent.
Planning for decades
Posted Apr 5, 2012 20:02 UTC (Thu) by Wol (subscriber, #4433) [Link]
It's called a contract.
aiui, the standard contract assigning copyright to the FSF places some restrictions on what they can do, and that's one of them.
Cheers,
Wol
Planning for decades
Posted Mar 29, 2012 1:55 UTC (Thu) by jzbiciak (guest, #5246) [Link]
Disallow anyone except the FSF, you mean. The FSF has very carefully set things up such that they trust themselves with unilateral action, but no one else.
Anyone who has released code under a "GPL version X or later" has left themselves open to whatever the FSF decides the next version of the GPL would say. If the FSF decided tomorrow that GPL v4 will read exactly as the 3-clause BSD license (minus references to UCB, of course), suddenly vast mountains of GPL software would be available under a BSD license (effectively) with no feedback or input from the software's authors.
If that's not unilateral, what is it? We only trust that the FSF wouldn't do that. They've earned it, but let's face it: They wield a fair bit of unilateral power here. The power above derives from their special status as the only source of future versions of the GPL.
But that isn't the issue at hand. Copyright assignment was. I'm getting there... So, assume the GPL is a fixed thing, and let's move on to copyright assignment.
When the FSF talks of "unilateral action" in a negative light, they mean by anyone but themselves. That doesn't mean that the FSF doesn't want to engage in unilateral actions. Their own reasons for copyright assignment page makes it plain that they want to be able to litigate unilaterally with respect to the software, and they can do that only if they own all the copyrights.
If there are multiple authors of a copyrighted work, successful enforcement depends on having the cooperation of all authors. In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer. That way we can be sure that all the code in FSF projects is free code, whose freedom we can most effectively protect . . . .
I read the highlighted "we" as meaning "the FSF and its legal team," not "the community at large." That sounds pretty unilateral to me.
So there you have it, two axes of unilaterality:
- Anyone who uses a "GPL version X or later" is automatically subject to whatever GPL license the FSF publishes in the future. They've opened themselves to that unilateral action.
- The FSF wants to be able to bring legal action with status and standing as "sole copyright holder" on behalf of software contributed to the FSF.
What the GPL effectively prevents is proprietary forks and unilateral action against a project by anyone else. Nobody else can release a new GPL license. And if folks assign their copyrights to FSF for FSF-maintained code, that grants no rights to anyone who isn't FSF.
How is it not clear that the FSF is in the cat bird seat here?
FWIW, I release all my software either under a GPL v2 (or GPL v2 and later) license, or I release it to the public domain if it's small enough to be inconsequential. I'm not against the GPL or the FSF. But, please understand that the FSF does have some special unilateral powers with respect to certain GPL uses, and for code submitted to an FSF-maintained project they ask for a few more unilateral powers.
Planning for decades
Posted Mar 29, 2012 2:04 UTC (Thu) by jzbiciak (guest, #5246) [Link]
Planning for decades
Posted Mar 29, 2012 2:09 UTC (Thu) by mcoleman (guest, #70990) [Link]
The real problem would be if the FSF could unilaterally restrict access to my code when I did not intend it. They cannot.
Planning for decades
Posted Mar 29, 2012 3:12 UTC (Thu) by dlang (guest, #313) [Link]
the FSF has the ability to allow that (make GPLv4 equivalent to BSD, proprietary company takes code and moves it to it's own license)
and before you protest and say that they have promised to never do anything like that, remember that they made a special clause in the license to allow GPL documents that were in wikipedia before a specific date to be moved to a GPL incompatible license.
They have the ability, the only question is will they.
I am not saying that they will, only that they have the ability to do so.
Planning for decades
Posted Mar 29, 2012 3:39 UTC (Thu) by jzbiciak (guest, #5246) [Link]
The FSF is in a unique position of power with respect to the GPL (at least the "ver X or later" variant). And because they ask you assign copyrights for anything you contribute to the FSF, they're in a unique position of power over that. Both give the FSF various (and differing) unilateral powers over your code, should you elect to extend those powers to the FSF. Those powers can be used in ways you do or do not agree with.
We trust that FSF won't disappoint us. They've earned a lot of trust from the community over the years, but that vague yet pervasive sense of trust is not a legal construct. As you say, "They have the ability; the only question is 'Will they?'"
The most likely answer is "They will not." But, it _is_ a potential single point of failure if I ever saw one...
Planning for decades
Posted Mar 29, 2012 4:08 UTC (Thu) by xtifr (guest, #143) [Link]
Planning for decades
Posted Mar 29, 2012 4:17 UTC (Thu) by jzbiciak (guest, #5246) [Link]
Planning for decades
Posted Mar 29, 2012 11:06 UTC (Thu) by smurf (subscriber, #17840) [Link]
Legally, "any later version" might well be interpreted as "… which intends to convey essentially the same rights".
If I had intended to publish my code under a 3-BSD license, ten years ago, I would have done so; therefore the FSF has no right to publish a 3-BSD-equivalent and label it "GPLv4".
Again, this is about the stated intent of both the FSF (what does it stand for? what are their goals?) and me (did I agree with these, when I chose that license?). It's not about the text "or any later version" with an implied "… whatever that says, decided unilaterally by the FSF".
Whatever your opinion about legal beagles in general, give them some credit.
Planning for decades
Posted Mar 29, 2012 11:16 UTC (Thu) by dlang (guest, #313) [Link]
in the opinion of the FSF it doesn't, in the opinion of many others, it does.
Planning for decades
Posted Mar 29, 2012 12:25 UTC (Thu) by wookey (guest, #5501) [Link]
Would be a more even statement of the situation. (Your original suggests that it is FSF's opinion versus 'many people'. Opinion is more evenly divided than that.)
Planning for decades
Posted Mar 29, 2012 12:50 UTC (Thu) by jzbiciak (guest, #5246) [Link]
3-BSD conveys fewer restrictions on the recipient of the code than GPL v2. So are you saying future GPL licenses can only be more restrictive?
Let's consider the spectrum of freedom from the perspective of the recipient of the code, not the author. Public domain code is the most free of all. 3-BSD is a step back from public domain, but not by much. GPL v2 is more restrictive than 3-BSD, with all its wording about derivative works and the like, source redistribution requirements, and so on. GPL v3 is more restrictive yet. And then there's the default state of "copyrighted work," where the recipient has very few default rights.
Are you suggesting that the only arc future GPL licenses can take is toward less freedom for the recipient?
Ok, so perhaps I was leading you down a rhetorical garden path with those questions. And, since you're well steeped in Free Software, you're not persuaded to follow. But, imagine arguments constructed along those lines in court. Such arguments could be much more persuasive to a less deeply invested judge and/or jury. If someone used your code with an imagined GPL v5 that let them make a proprietary package that you didn't approve of, good luck winning over the court if you try to sue.
I realize that the FSF is trying to maximize the freedom of the ecosystem as a whole. But realize that it does so by limiting the freedom of individuals to appropriate the code and take it private. It lays that all out in the preamble, saying that to protect your rights, it puts limits on what you (or anyone using the software) can do, and places on you certain responsibilities in order for you to use the licensed software. That subtle, tricky and almost counter-intuitive balance of "protecting your rights by limiting your actions" can be a lot for folks to wrap their heads around.
What if the FSF decides that it's in the greater interest of the ecosystem to place fewer restrictions on the recipients of the software, thinking that yes, there will be some that abuse the additional privilege, but it's entirely likely be more new contributors that will not. There are those who find the GPL legally risky and don't contribute, and maybe someday the FSF will try to meet them in the middle to bring them into the fold. (Probably not as long as St. Ignucious is still kicking, but hey, there's an awful lot of future ahead of us. And don't think that I'm advocating that the FSF should do this. I'm only arguing about the potential range of outcomes here.)
The GPL v2 states:
The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
"Similar in spirit" is rather wide open to interpretation. The overriding theme is "freedom", and as we've all seen, there are many, many differing interpretations of what constitutes freedom. A license that shifts the balance of freedoms toward the recipient (ie. a move toward something more like 3-BSD, if not moving entirely to 3-BSD) would not necessarily be incompatible in spirit with the GPL in many peoples' eyes.
In any case, the only truly legally binding phrase in that clause is this one:
If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
Sure, the preceding paragraph said "similar in spirit," but the FSF alone gets to define what their spirit is. After all, they wrote the license.
Planning for decades
Posted Mar 29, 2012 13:03 UTC (Thu) by jzbiciak (guest, #5246) [Link]
Now the FSF releases the GPL v4 that reverts the changes in GPL v3, and reads identical to GPL v2.
Theoretically, the GPL v3 was similar in spirit to the GPL v2. So, this imagined GPL v4 should also be similar in spirit to GPL v3. Now what?
Really, the "or later" clause cedes an awful lot of control to the FSF. That's been my point all along. The punch line is that if you care that much about the specific semantics of the license that covers your code, you really shouldn't put a wildcard in the license that you don't control.
Planning for decades
Posted Mar 29, 2012 16:45 UTC (Thu) by khim (subscriber, #9252) [Link]
The punch line is that if you care that much about the specific semantics of the license that covers your code, you really shouldn't put a wildcard in the license that you don't control.
Yup. The irony here is that it looks like FSF is the only organization which understands that.
GPL is the only popular copyleft license which gives program author the right to refuse delegation of “autoupgrade” rights to license “stewards”. Note that such liberty was given to authors by all versions of GPL, including the first one. All these other licenses were created after GPL was created - yet they cede “an awful lot of control” unconditionally.
It's funny that the very people who are bashing FSF for the “or later” clause are often advocating MPL or CC-BY-SA as an alternative despite the fact that they are obviously more problematic in this regard.
Planning for decades
Posted Mar 29, 2012 4:45 UTC (Thu) by slashdot (guest, #22014) [Link]
The more worrisome thing is what happens after him.
Planning for decades
Posted Mar 29, 2012 12:45 UTC (Thu) by mcoleman (guest, #70990) [Link]
Right now, it looks like the FSF is more stable over time than the legal and social systems that it is embedded in, so it seems kind of pointless to worry about them. Could they go Komen? Sure, it could happen. Nothing is forever.If you're really worried about them making your code less restricted under a "or later" clause, just leave it out.
Planning for decades
Posted Mar 29, 2012 23:50 UTC (Thu) by xtifr (guest, #143) [Link]
That's why I suggested above: if you don't trust the FSF to do the right thing, then, instead of simply removing the "or later" clause, replace it with something that says "or any later version that meets [list of criteria I consider indispensable]". For example, if you're a big fan of Tivoization, you could say, "GPLv2 or any later version that allows [tivoization]". Then, if the FSF had a change of heart and decided to allow tivozation (perhaps as an option) in the GPLv4, your code would automatically be compatible with v4 (or at least with v4 projects that exercised the tivoization option).
Bottom line: "the FSF might do things I don't like in the future" is a mostly-hypothetical bad thing, while removing the "or later" clause is license proliferation, which is a right-now bad thing.
Planning for decades
Posted Mar 30, 2012 0:14 UTC (Fri) by dlang (guest, #313) [Link]
you've obviously missed all the people (including a large number of linux kernel developers) who consider GPLv3 a perfect example of the FSF doing something that they didn't like with a future license change.
for them this is not a hypothetical thing, it's the reality, and they especially don't like being bullied into changing the license on their code because not doing so leads to license proliferation, especially as they made their concerns (including the problem of license proliferation) very clear before the GPLv3 was published.
I'm not saying that you are doing the bullying, but there are others who are doing so.
Planning for decades
Posted Mar 30, 2012 6:12 UTC (Fri) by xtifr (guest, #143) [Link]
No, I had them in mind when I said mostly. And, while I've heard a lot of people bitch about the GPLv3, in my experience, the majority of the bitching boils down to "wah, it's so long and complicated--v2 was so much simpler and more elegant!" The people I've heard complain about actual terms of the GPLv3 are...well, greater than zero, but not a whole lot greater. The main thing among the actual terms I've heard people complain about is the anti-tivoization stuff, which is why I explicitly covered that in my earlier post. (In fact, if enough people followed my earlier advice, it might actually make my improbable hypothetical come true, and persuade the FSF to conditionally allow tivoization in a future version.)
(Also, a lot of people don't seem to grasp the difference between "GPLv2 or later" can always be used under the GPLv2, no matter how many later versions may have been published. The GPLv3 wouldn't prevent the Linux kernel from being Tivoized even if the kernel were "v2 or later", because anyone can still continue to use the code under the terms of v2. But I'm trying to ignore idiotic arguments, even though it's hard when this topic has generated so much heat and so little light.)
In any case, you seem to be ignoring the fact that my solution works for both sides! It minimizes the license proliferation problem, while preventing the FSF from adding conditions you don't like to your code. It's not necessarily perfect (you have to have guess which terms might turn out to be important), but I think it's good enough that I'll probably try using it myself.
Planning for decades
Posted Mar 30, 2012 6:27 UTC (Fri) by sfeam (subscriber, #2841) [Link]
"a lot of people don't seem to grasp the difference between "GPLv2 or later" can always be used under the GPLv2, no matter how many later versions may have been published." Only if you are talking about a standalone bit of code. If someone takes my GPLv2orlater code and incorporates it in a larger GPL3 program, then the result cannot be used under GPL2, only under GPL3. If I don't want that to happen then GPL2orlater is not an option.
Planning for decades
Posted Mar 30, 2012 6:59 UTC (Fri) by xtifr (guest, #143) [Link]
Once again, you're completely ignoring what I actually said in order to argue with some straw man. If there's some change in the GPLv3 you don't like, then say "GPLv2 or any later version which has [the GPLv2 version of that feature]". That doesn't make you more any more compatible with v3, but allows you compatibility if the FSF rethink their position and add the feature as an option in v4. (And even puts some pressure on them to do so, if your program is widespread and popular enough.)
Planning for decades
Posted Mar 30, 2012 9:03 UTC (Fri) by paulj (subscriber, #341) [Link]
A simpler solution perhaps, if you don't fully trust the FSF, would be to add additional authorities as to which later versions are blessed? E.g.: "GPLv2 or any later version approved by [authority]", where authority could be, say, Linus Torvalds, or some cabal. ??
Planning for decades
Posted Mar 31, 2012 3:05 UTC (Sat) by xtifr (guest, #143) [Link]
Planning for decades
Posted Mar 30, 2012 15:21 UTC (Fri) by mcoleman (guest, #70990) [Link]
...then the result cannot be used under GPL2, only under GPL3Of course. Why would you expect to be able to use someone else's code in a manner that they forbid? Microsoft won't let you do that either...
Planning for decades
Posted Mar 31, 2012 10:13 UTC (Sat) by mpr22 (subscriber, #60784) [Link]
Part of the point of the GPL is "share and share alike" (or so it seems to me). GPLv3+'ing a derivative of a GPLv2+ project is, at best, shockingly rude, since it amounts to saying "I don't want to share with you" to the upstream maintainer.
Planning for decades
Posted Mar 31, 2012 11:41 UTC (Sat) by jzbiciak (guest, #5246) [Link]
Ah, but what if a GPL v3+ project decides to integrate a non-trivial part of your GPL v2+ code base into the larger GPL v3+ project, as sfeam suggested a few comments up?
For example, I'm making a GPL v3/v3+ paint program, and you wrote a nice chunk of GPL v2+ code for handling the whizzy new Frobnitz N-dimensional drawing tablet. Now I integrate your Frobnitz handling code into my paint program. The resulting application is GPL v3+. What's the point of GPL v2+ if not to allow such forward compatibility?
Sure, if I were to release a GPL v3/v3+ only application that was created by taking someone else's GPL v2+ app and adding only a little bit of GPL v3 code, that would be somewhat rude (unless I had the author's blessing), but entirely legit by the license. But sfeam's example had the sizes the other way around -- smaller GPL v2+ code subsumed into a larger GPL v3 / v3+ project. I don't think anyone should find that rude. (I almost said "I don't think anyone would find that rude," but I thought better of it. The Internet is a big place.) I imagine it happens with large GPL v3 projects somewhat regularly.
Speaking of which, aside from GCC, what are some somewhat large GPL v3 projects out there? Or did most everyone hang back with GPL v2/2+?
Planning for decades
Posted Mar 31, 2012 15:47 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
- audacious
- swig
- claws-mail
- codeblocks
- gimp
- grub2
- mc
- mplayer
- rdesktop
- tryton
Planning for decades
Posted Mar 31, 2012 15:57 UTC (Sat) by jzbiciak (guest, #5246) [Link]
Planning for decades
Posted Apr 5, 2012 11:03 UTC (Thu) by njs (subscriber, #40338) [Link]
Planning for decades
Posted Apr 5, 2012 20:10 UTC (Thu) by Wol (subscriber, #4433) [Link]
If you make major changes you can then decide whether to move it into the main GPL3 tree or not.
Cheers,
Wol
Planning for decades
Posted May 29, 2012 12:31 UTC (Tue) by mirabilos (subscriber, #84359) [Link]
The combined work can be shared under GPLv3 only. (The act of running the program, coll. using, is not restricted by the GNU GPL.)
But if your original source code is still intact (and copyright law apparently – IANAL, TINLA – forbids removing copyright notices) within the combined work and a visibly separate entity, you can still take that (possibly patched) file under GPLv2+ as it originally was, because the GNU GPL in no version has the power of actually changing *other* peoples’ copyright licences.
Planning for decades
Posted Mar 30, 2012 1:11 UTC (Fri) by jzbiciak (guest, #5246) [Link]
Perhaps a safer course would just to replace "or any later version" with "or later versions approved by <name of authority here>." That approval could even extend to another version of the license with a different named authority, should you care to pass the torch.
Note that the named authority need not be an individual. It could be a committee, such as the Frobnitz Steering Team or what-have-you.
Planning for decades
Posted Mar 29, 2012 13:13 UTC (Thu) by mina86 (guest, #68442) [Link]
Sorry, but this is BS.
The theory behind copyright assignment is that it's easier with litigations as you pointed later.
FSF could change GPL if they really wanted to, and the easy solution for authors that do not submit with a “or later” clause is to not accept such patches.
Planning for decades
Posted Mar 29, 2012 18:02 UTC (Thu) by dlang (guest, #313) [Link]
Planning for decades
Posted Mar 29, 2012 19:19 UTC (Thu) by mina86 (guest, #68442) [Link]
Planning for decades
Posted Mar 29, 2012 18:06 UTC (Thu) by smurf (subscriber, #17840) [Link]
This does not make sense. You can do the same thing with an agreement authorizing the FSF (or, more specifically, their lawyer) to act on your behalf, should a license violation involving your code come to their attention.
Planning for decades
Posted Mar 29, 2012 18:14 UTC (Thu) by mcoleman (guest, #70990) [Link]
(Compare: "I authorize the FSF to use my bat as they see fit." versus "I give the FSF my bat.")
A turning point for GNU libc
Posted Mar 28, 2012 19:54 UTC (Wed) by marcH (subscriber, #57642) [Link]
A turning point for GNU libc
Posted Mar 30, 2012 0:26 UTC (Fri) by man_ls (guest, #15091) [Link]
Apparently. One can only wonder what a high-profile hacker can do as VP in such an organization (apart from getting filthy rich). But, if Alan Cox got his MBA, I suppose anything can happen. Torvalds for Governor?
A turning point for GNU libc
Posted Mar 30, 2012 2:36 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
trading
Posted Mar 30, 2012 6:40 UTC (Fri) by marcH (subscriber, #57642) [Link]
Short-term trading is not performed by humans nowadays; it's done by algorithms implemented by mathematicians and *software engineers*.
That's why it's called the "virtual/unreal economy": it's performed on a time scale far away from any human time scale and no one has any clue about what they're actually trading.
trading
Posted Mar 30, 2012 7:09 UTC (Fri) by man_ls (guest, #15091) [Link]
I suppose that Drepper might fit in as a senior master super duper engineer or something, but being a VP entails a lot of political responsibilities, at least in the organizations I have seen. I cannot imagine someone with a long history of conflicts (on the negative side) and who is able to write documents in such an excruciating detail (on the positive) being a good politician.Perhaps Goldman Sachs maintains a large internal library for short-term trading and they don't want it to grow any larger...
trading
Posted Mar 30, 2012 11:28 UTC (Fri) by jwakely (subscriber, #60262) [Link]
being a VP entails a lot of political responsibilities, at least in the organizations I have seenIn US investment banks everyone's a VP. Goldman Sachs have nearly 12000 of them, out of 33000 staff. [source]
trading
Posted Mar 30, 2012 12:33 UTC (Fri) by man_ls (guest, #15091) [Link]
Weird! And even weirder that I haven't read anything about this in my favorite source of corporate knowledge.
A turning point for GNU libc
Posted Mar 30, 2012 19:00 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]
A turning point for Drepper
Posted Mar 30, 2012 20:00 UTC (Fri) by man_ls (guest, #15091) [Link]
I understand that customers prefer to be contacted by a VP than by an underling, and thus the inflation. But 40% of VPs is a bit too much... Nowadays unless GC employees present themselves as "Ultimate Grand Chamberlain and Patron Saint", I guess customers spit at them.
A turning point for GNU libc
Posted Mar 28, 2012 21:44 UTC (Wed) by jcm (subscriber, #18262) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 22:54 UTC (Wed) by xtifr (guest, #143) [Link]
A turning point for GNU libc
Posted Mar 28, 2012 23:22 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
A turning point for GNU libc
Posted Mar 29, 2012 6:31 UTC (Thu) by mjthayer (guest, #39183) [Link]
A turning point for GNU libc
Posted Mar 30, 2012 19:10 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]
Would it not be more useful for the libc headers to support a macro specifying the intended minimum required run-time version? (I seem to recall that the Win32 SDK supports something like this.) Various definitions would then be disabled or modified to match the old version, and symbol version selection would be modified too. Of course ithis would further complicate the nest of #ifdefs in the headers.
A turning point for GNU libc
Posted Mar 30, 2012 21:30 UTC (Fri) by mjthayer (guest, #39183) [Link]
> Given that most of the demand for static linking comes from companies wanting to distribute proprietary binaries, doesn't 'more friendly' imply relicencing?
If that is what you (generic you!) want to do the LGPL lets you link statically with proprietary applications as long as you provide object files and what-not so that you can relink the application against a rebuilt version of the LGPLed code.
A turning point for GNU libc
Posted Mar 31, 2012 12:32 UTC (Sat) by kleptog (subscriber, #1183) [Link]
http://www.trevorpounds.com/blog/?p=103
http://sourceware.org/binutils/docs-2.19/ld/VERSION.html#...
If other libraries paid as much attention to library backward compatibility the world you be a lots nicer place (you could copy binaries around between distributions and they would work).
A turning point for GNU libc
Posted Apr 1, 2012 1:54 UTC (Sun) by BenHutchings (subscriber, #37955) [Link]
If you want a program to run on older versions of glibc, you need to use the old interface definitions and the old symbol versions. Just overriding the symbol versions will generally result in your program corrupting data or crashing.
A turning point for GNU libc
Posted Apr 5, 2012 8:34 UTC (Thu) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Apr 5, 2012 15:06 UTC (Thu) by khim (subscriber, #9252) [Link]
Actually this is what LSB is doing and it works fine AFAICS.
A turning point for GNU libc
Posted Apr 8, 2012 11:21 UTC (Sun) by nix (subscriber, #2304) [Link]
A turning point for GNU libc
Posted Apr 2, 2012 13:20 UTC (Mon) by jwakely (subscriber, #60262) [Link]
Not every company distributes software. I can't remember the last time I wrote anything in my day job which wasn't for purely in-house use. The arguments in the "static linking considered harmful" piece simply don't apply in some cases.
A turning point for GNU libc
Posted Apr 2, 2012 13:28 UTC (Mon) by mjthayer (guest, #39183) [Link]
I suppose that assuming that the new team is less unfriendly to static linking it will also be a question of whether there are enough people actively interested in it to get the necessary changes in.
A turning point for GNU libc
Posted Mar 29, 2012 8:48 UTC (Thu) by cyperpunks (subscriber, #39406) [Link]
I have seen several projects where the whole projects seems to be dependent of one single person. However when this person was gone, the opposite was true. He was more a obstacle than a driving force.
Benevolent loners
Posted Mar 30, 2012 0:30 UTC (Fri) by man_ls (guest, #15091) [Link]
Stating the obvious: I have seen many projects where the whole project was indeed driven by a single person, and the project languished after this person was gone.Your statement is probably true mostly for high profile projects such as glibc.
A turning point for GNU libc
Posted Mar 29, 2012 10:24 UTC (Thu) by dgm (subscriber, #49227) [Link]
It's too early to say that. If you have a look at the patches/day ratio you get the following numbers:
release: patches per day
2.4: 4.2208
2.5: 1.6811594203
2.6: 1.5657894737
2.7: 2.858974359
2.8: 1.5875706215
2.9: 1.3627906977
2.10: 1.9435028249
2.11: 2.3448275862
2.12: 2.1027027027
2.13: 1.0077220077
2.14: 1.9104477612
2.15: 2.8252427184
The 2.7 release was busier than 2.15, and 2.11 amd 2.12 were not that far behind. But by far the most active period was that leading to 2.4.
If you plot that data, you can convince your self that the project had moved ahead at an almost steady rate of about 2 patches per day.
PS: Is there a sane way to enter tabular data in a comment?
A turning point for GNU libc
Posted Mar 29, 2012 16:53 UTC (Thu) by cortana (subscriber, #24596) [Link]
You can use <pre> in an HTML comment.
2 2.4: 4.2208 2.5: 1.6811594203 2.6: 1.5657894737 2.7: 2.858974359 2.8: 1.5875706215 2.9: 1.3627906977 2.10: 1.9435028249 2.11: 2.3448275862 2.12: 2.1027027027 2.13: 1.0077220077 2.14: 1.9104477612 2.15: 2.8252427184
My favourite glibc annoyance
Posted Mar 29, 2012 13:08 UTC (Thu) by saffroy (guest, #43999) [Link]
A few years ago, my biggest gripe was that glibc and RedHat-based systems would not allow an admin to tune the behaviour of bindresvport in the glibc, thus forcing users to use ugly (and IIRC insufficient) hacks such as portreserve. Some sane distributors patched their glibc properly (implementing a configurable blacklist for bindresvport), but they were never allowed to upstream their changes, and users of RH and its derivatives distros are still punished.
I'm sure many others have their own war stories...
My favourite glibc annoyance
Posted Mar 31, 2012 21:55 UTC (Sat) by lacos (guest, #70616) [Link]
and users of RH and its derivatives distros are still punished
I don't think so, see ip_local_reserved_ports; it's in RHEL-6 and upstream keeps polishing it.