Two GCC stories

By Jonathan Corbet
June 30, 2010

The GNU Compiler Collection (GCC) project occupies a unique niche in the free software community. As Richard Stallman is fond of reminding us, much of what we run on our systems comes from the GNU project; much of that code, in turn, is owned by the Free Software Foundation. But most of the GNU code is relatively static; your editor wisely allowed himself to be talked out of the notion of adding an LWN weekly page dedicated to the ongoing development of GNU cat. GCC, though, is FSF-owned, is crucial infrastructure, and is under heavy ongoing development. As a result, it will show pressures that are only seen in a few places. This article will look at a couple of recent episodes, related to licensing and online identity, from the GCC community.

Documentation licensing

Back in May, GCC developer Mark Mitchell started a discussion on the topic of documentation. As the GCC folks look at documenting new infrastructure - plugin hooks, for example - they would like to be able to incorporate material from the GCC source directly into the manuals. It seems like an obvious idea; many projects use tools like Doxygen to just that end. In the GCC world, though, there is a problem: the GCC code carries the GPLv3 license, while the documents are released under the GNU Free Documentation License (GFDL). The GFDL is unpopular in many quarters, but the only thing that matters with regard to this discussion is that the GFDL and the GPL are not compatible with each other. So incorporating GPLv3-licensed code into a GFDL-licensed document and distributing the result would be a violation of the GPL.

After some further discussion, Mark was able to get a concession from Richard Stallman on this topic:

If Texinfo text is included the .h files specifically to be copied into a manual, it is ok to for you copy that text into a manual and release the manual under the GFDL.

This is a severely limited permission in a number of ways. To begin with, it applies only to comments in header files; the use of more advanced tools to generate documentation from the source itself would still be a problem. But there is another issue: this permission only applies to FSF-owned code. As Mark put it:

However, if I changed the code, but did not regenerate the docs, and you then picked up my changes, possibly made more of your own, and then regenerated the docs, *you* would be in breach. (Because my changes are only available to you under the GPL; you do not have the right to relicense my changes under the GFDL.)

I find that consequence undesirable. In particular, what I did is OK in that scenario, but suddenly, now, you, are a possibly unwitting violator.

Dave Korn described this situation as being "laden with unforeseen potential booby-traps" and suggested that it might be better to just give up on generating documentation from the code. The conversation faded away shortly thereafter; it may well be that this idea is truly dead.

One might poke fun at the FSF for turning a laudable goal (better documentation) into a complicated and potentially hazardous venture. But the real problem is that we as a community lack a copyleft license that works well for both code and text. About the only thing that even comes close to working is putting the documentation under the GPL as well, but the GPL is a poor fit for text. Nonetheless, it may be the best we have in cases where GPL-licensed code is to be incorporated into documentation.

Anonymous contributions

Ian Lance Taylor recently described a problem which will be familiar to many developers in growing projects:

The gcc project currently has a problem: when people who are not regular gcc developers send in a patch, those patches often get dropped. They get dropped because they do not get reviewed, and they get dropped because after review they do not get committed. This discourages new developers and it means that the gcc project does not move as fast as it could.

He also noted that a contributor who goes by the name NightStrike had offered to build a system which would track patches and help ensure that they are answered; think of it as a sort of virtual Andrew Morton. This system was never implemented, though, and it doesn't appear that it will be. The reason? The GCC Powers That Be were unwilling to give NightStrike access to the project's infrastructure without knowing something about the person behind the name. As described by Ian, the project's reasoning would seem to make some sense:

Giving somebody a shell account on gcc.gnu.org means giving them a very high level of trust. There are quite a few people who could translate a shell account on gcc.gnu.org into a number of difficult-to-detect attacks on the entire FLOSS infrastructure, including the kernel, the source code control systems, etc. It's hard for us to get to the required level of trust in somebody whom we have never met and who won't provide any real world contact information.

NightStrike, who still refuses to provide that information, was unimpressed:

What you guys need to realize is that if I did just make something up, there wouldn't be an issue. Your policies are vintage computer security circa 1963. That's what's so darn frustrating about this whole entire thing. You don't have any actual security, but yet you think I'm going to try to bring down everything GNU. That's just awesome.

Awesome or not, this episode highlights a real problem that we have in our community. We place a great deal of trust in the people whose code we use and we place an equal amount of trust in the people who work with the infrastructure around that code. The potential economic benefits of abusing that trust could be huge; it's surprising that we have seen so few cases of that happening so far. So it makes sense that a project would want to know who it is taking code from and who it is letting onto its systems. To do anything else looks negligent.

But what do we really know about these people? In many projects, all that is really required is to provide a name which looks moderately plausible. Debian goes a little further by asking prospective maintainers to submit a GPG key which has been signed by at least one established developer. But, in general, it is quite hard to establish that somebody out there on the net is who he or she claims to be. Much of what goes on now - turning away obvious pseudonyms but accepting names that look vaguely real, for example - could well be described as a sort of security theater. The fact that Ian thanked NightStrike for not making up a name says it all: the project is turning away contributors who are honest about their anonymity, but it can do little about those who lie.

Fixes for this problem will not be easy to come by. Attempts to impose identity structures on the net - as the US is currently trying to do - seem likely to create more problems than they solve, even if they can be made to work on a global scale. What we really need is processes which are robust in the presence of uncertain identity. Peer review of code is clearly one such process, as is better peer review of the development and distribution chain in general. Distributed version control systems can make repository tampering nearly impossible. And so on. But no solution is perfect, and these concerns will remain with us for some time. So we will have to continue to rely on feeling that, somehow, we know the people we are trusting our systems to.

to post comments

Two GCC stories

Posted Jun 30, 2010 16:40 UTC (Wed) by fsateler (subscriber, #65497) [Link] (28 responses)

What I find really strange is the obsession with finding out if someone is who she says she is, while it doesn't really matter. The really important part is to uniquely identify someone. That's why GPG keys without a trust path to you are still useful: I can see that all the work we've been doing in the past is with the same person, and I don't care if his name is the same as appearing in the gpg key.
And that's what is annoying about GPG, I can't say "I trust this person" without saying "I know this person is who she says she is".

Two GCC stories

Posted Jun 30, 2010 16:51 UTC (Wed) by gmaxwell (guest, #30048) [Link] (17 responses)

Of course it matters: A large part of the incentive structure that improves our confidence that someone isn't planning on doing "bad things" is the fact that if you do bad things people with uniforms can come and lock you up and you know it. The existence of consequences allows us to make some additional reasonable assumptions about the future behaviour of apparently sane people.

Reputation is informative by itself, and the loss of reputation is a consequence, but it really isn't much of one as people can maintain several reputation building personalities at once... and especially not compared to some of the consequences which are available when we can reliably track someone to their one and only meat-space identity.

Two GCC stories

Posted Jun 30, 2010 17:08 UTC (Wed) by nix (subscriber, #2304) [Link] (4 responses)

Of course it matters: A large part of the incentive structure that improves our confidence that someone isn't planning on doing "bad things" is the fact that if you do bad things people with uniforms can come and lock you up and you know it.

That would make sense if the FSF refused contributions from nations that had no extradition treaty with the United States. But it doesn't (because that would mean locking most of the world out of development of FSF-owned projects, and because it's obviously ridiculously intrusive, and, well, if you're planning to do bad things you can lie about your country of origin just as easily as you can lie about your name).

Two GCC stories

Posted Jun 30, 2010 20:08 UTC (Wed) by nteon (subscriber, #53899) [Link] (1 responses)

yes, but it seems to me to be a lot less risky to accept a fixed, isolated changeset into a version control repository than giving someone a shell on a (seemingly) multi-purpose box.

Two GCC stories

Posted Jun 30, 2010 22:19 UTC (Wed) by nix (subscriber, #2304) [Link]

Certainly true enough.

Two GCC stories

Posted Jul 2, 2010 0:57 UTC (Fri) by gdt (subscriber, #6284) [Link]

That would make sense if the FSF refused contributions from nations that had no extradition treaty with the United States.

Extraditing people to the country of the affected server is both unusual and contentious, ref Gary McKinnon.

Most counties have laws against computer misuse. An overseas complainant can contact the police and provide evidence to prosecutors.

The US isn't the world policeman

Posted Jul 2, 2010 9:25 UTC (Fri) by copsewood (subscriber, #199) [Link]

Online reputation and software development are global, computer misuse laws are local and national. The idea that software development integrity requires extradition to the US depletes the external reputation of the US, especially amongst those aware of extradition misuse, as with the Gary McKinnon case.

Two GCC stories

Posted Jun 30, 2010 17:12 UTC (Wed) by madscientist (subscriber, #16861) [Link]

I don't know how it works now but when I got my account on the GNU machines (as best as I recall--it was almost 15 years ago) I had to send a photocopy of my driver's license to the FSF. I also had a phone conversation with someone at the FSF (to verify my phone #--although I don't have that number anymore) and during that phone call they verified my SSH key fingerprint. Also when you do any copyright assignment to the FSF, it's all done via snail-mail (and IIRC you cannot use P.O.Boxes for legal reasons) so they have a valid address for you... and of course if you're getting a login account on an FSF machine it's a very fair bet that you'll need to be doing some sort of copyright assignment.

The FSF is different than some other environments where "getting access" just gives you the ability to promote git code over SSH or HTTPS or similar: for the FSF you get an actual login account, with shell access and everything, on their servers and this gives you a LOT of capability for mischief.

The FSF systems HAVE been hacked before and it's very unpleasant. I definitely do not begrudge them this requirement. It's not like NightStrike has to publish his information to everyone; it just needs to be available to the FSF folks. I see absolutely nothing unreasonable about this.

I do agree that if the only requirement is that he email them a "real sounding" name, the whole thing is ridiculous... in that case I support his refusal on the grounds of civil disobedience :-)

Two GCC stories

Posted Jul 1, 2010 12:28 UTC (Thu) by epa (subscriber, #39769) [Link] (4 responses)

Quite. The key point is that you can make as many pseudonyms as you want, but you have only one real name. If there were some way of checking that this 'Nightstrike' is also called by the same name in other contexts, such as his or her day job, and of guaranteeing that the same person cannot invent new ones, then it wouldn't matter what the name is.

From a computer-security point of view, as Nightstrike points out, it makes no sense to ask for a real name without doing any verification on it. But from a social point of view, encouraging the use of real names rather than anonymous or psedonymous handles can create a better atmosphere for collaboration. The online encylopaedia Citizendium, for example, has a policy that everyone contribute under their real name. It is held that this will tend to get better contributions and more mature discussions.

Two GCC stories

Posted Jul 1, 2010 15:16 UTC (Thu) by k8to (guest, #15413) [Link] (2 responses)

A little point. People can make up new real names.

Screen names vs real names

Posted Jul 3, 2010 3:12 UTC (Sat) by giraffedata (guest, #1954) [Link] (1 responses)

A little point. People can make up new real names.

It's actually a pretty big point. There is little distinction between what we're calling a "real name" and "NightStrike." There are countries where a person has a single well-defined legal name (not to mention number), but plenty where a person doesn't. The U.S. is one of the latter. Also, some countries have a dictionary from which you must choose a name, but most, including the U.S., don't.

A person can not only make up a new name, but go by multiple ones at the same time and use a name as silly as he pleases. Legal procedures come into play if you want to force someone else to call you that, and you're not allowed to use a name with intent to defraud, but the essential point is that a name is not an identity and vice versa.

It makes sense for FSF to want to have the name or names that a person uses with his bank account, residence, and criminal convictions, in addition to enough additional identifying information to disambiguate that name. But it doesn't make sense just to ask for a "real name."

Screen names vs real names

Posted Jul 3, 2010 4:00 UTC (Sat) by gmaxwell (guest, #30048) [Link]

I don't really mean to single out you, but a number of the comments here reflect what I perceive to be a kind of "computer engineer's autism" ... a notion that things are binary, that a preventative measure either works in an absolute, quasi-mathematical sense, or its worthless.

But the world doesn't fit into nice little binary boxes like that. It's quite possible for someone to join a project with fully honest intentions and only to later decide to do something dishonourable, perhaps inspired by some dispute or the like. Of course, they're less likely to do so if they'd given their real name at the start, taking the risk of real repercussions. So even if you do _nothing_ more than to ask for a real name and perform no validation that does provide a value. It's not an absolute proof: nothing is... Just an additional piece of confidence that costs most people very little.

... and does the FSF really want important contributors who need to hide their connection? For their sake and the FSF's it would probably better if someone who needs to hide their affiliation didn't contribute in that way. Anonymity is a powerful and important tool, but it is often a danger: Under the believed guise of anonymity we'll engage in activities we would otherwise deem to risky. Should that anonymity be shattered we regret our decisions to depend on it.

Of course, people do manufacture multiple online identities. I've seen quite a few instances of people building up multiple admin accounts on the English Wikipedia each representing at least a hundred hours of work, if not several hundred, building social connections, community trust, and making useful contributions to the encyclopaedia. Are they more likely to just make up another 'real name' than build a virtual reputation? I don't know asking for a real name doesn't do much against someone who came in with an intent to defraud. Like the locks on most doors and containers, asking for a name helps keep honest people honest. I think it's obvious that if you ask for both a real name and a virtual reputation you get a superior protection compared to doing either alone.

It might be the case that the FSF should be doing more detailed identity-validation... I don't know what they do today, as I know too many FSF people fairly personally, and I don't have a good feel for what level would be sufficient for their needs. But I do think we need to reject these binary notions of security. The world's problems have infinite shades of grey, and our tools needs to be as numerous and varied if we are to address these issues. Regardless of how lossy the existing process is that lossyness is an argument for strengthening it, not for abandoning the protection it currently provides, however small.

Two GCC stories

Posted Jul 1, 2010 15:43 UTC (Thu) by nix (subscriber, #2304) [Link]

I'm not really sure the nearly-moribund Citizendium is the best possible example to bring up in this context :)

Two GCC stories

Posted Jul 1, 2010 17:30 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (3 responses)

I've yet to see anybody being able to "build several reputations" at once... besides that it is a lot of work to build a solid reputation, the reward from squandering it would have to be very large indeed.

Two GCC stories

Posted Jul 1, 2010 23:42 UTC (Thu) by Kissaki (guest, #61848) [Link] (2 responses)

This sounds to me like what I have heard described as an "alt" or a "sock puppet". I've seen multiple people do / use this to build two (or more? How do you know?) reputations at once.

Admittedly the tendency seems to be to build at least one troll reputation in my experience, but the point is that multiple reputations seems pretty common to me.

Two GCC stories

Posted Jul 2, 2010 12:08 UTC (Fri) by sorpigal (subscriber, #36106) [Link] (1 responses)

The important thing, I think, is that when someone goes through the trouble of building multiple reputations he doesn't trash them casually. If I have a troll identity and a respectable identity you can probably trust the respectable identity to remain respectable even if I were committing major crimes with another identity.

Two GCC stories

Posted Jul 4, 2010 3:18 UTC (Sun) by Kissaki (guest, #61848) [Link]

It sounds to me like the possibility exists that the reputation would not be trashed casually.

That reputation could be used as a tool to accomplish something worth more than the time spent to develop it. This is social engineering. Access to the development of GCC could (paranoia talking) be a stepping stone to compromising a wide variety of software.

In addition, you are assuming that the resulting identity would be 'trashed'. A clever intruder would not expose him (or her) self as a wrongdoer (where is the gain in that), but would act in secret. You might never discover their actions.

Online identity and reputation is worth something; no question. But you place too high a value on it in my opinion.

Two GCC stories

Posted Jul 8, 2010 21:08 UTC (Thu) by landley (guest, #6789) [Link] (1 responses)

> Of course it matters: A large part of the incentive structure that
> improves our confidence that someone isn't planning on doing "bad things"
> is the fact that if you do bad things people with uniforms can come and
> lock you up and you know it.

So we shouldn't allow any developers from outside our current legal jurisdiction? No developers from bangladesh, the ukraine, brazil, malaysia, africa... Because even if you have their GPS coordinates, filing a complaint against them here in the US won't have Large Blue Men pounding on their doors any time soon.

Also, the lead developer on Gentoo Embedded is solar@gentoo.org, who put Ned Ludd in the real name field. That's not his real name:

http://en.wikipedia.org/wiki/Ned_Ludd

In that particular case, I have met him in person (after knowing him online for a few years, we got together at an embedded Linux conference), and it turned out he's actually male, which means he's not using the single most common reason for online handles. (Which is the same reason Val Henson went by "Val" for so long, and Pat Mochel went by "Pat".) There are parts of the net on which being obviously female attracts unwanted attention.

And no, linux-kernel isn't the only place that comes up:

http://www.tgdaily.com/games-and-entertainment-brief/5055...

As for the FSF, in the 1980's their high-bandwidth FTP site (provided by MIT) was their killer app, a unique resource that drew developers to them. Back then just about the only way for an individual to get online distribution for their code was to sign it over it to the FSF so they would put it up on their FTP site. (Which is why Larry Wall handed patch over to the FSF, back before he wrote Perl.) People were willing to jump through the copyright assignment hoops and put up with the extremist political rhetoric in order to get internet distribution for their code.

All that changed in 1993 when NSF changed its (AUP) Acceptable Use Policy to allow for-profit firms to connect directly to the internet, which allowed everything from home ISPs to companies like Yahoo:

http://landley.net/history/mirror/nsfnetaup.txt

And suddenly you didn't _need_ the FSF to distribute your code anymore, you could put it anywhere. And that's about when the FSF started a long slow downhill slide.

Linux didn't render the FSF irrelevant: Geocities did.

Rob

Two GCC stories

Posted Jul 9, 2010 17:13 UTC (Fri) by nix (subscriber, #2304) [Link]

You do realise that you devalue your own words as soon as you start describing the carefully reasoned arguments in the FSF's many articles as 'extremist political rhetoric', right?

(Your point about the FSF's FTP site stands, but not that well: there were many other high-bandwidth sites around even in the 80s with very large repositories of code on them. Much of that code was dramatically less free than the GPL or BSD licenses: oddly, nobody remembers most of that stuff anymore, while the GPL-licensed code soldiers on.)

Two GCC stories

Posted Jun 30, 2010 17:06 UTC (Wed) by ptman (subscriber, #57271) [Link] (2 responses)

In GPG you cannot say "I trust this person". What you can say is "I trust this key belongs to who it says it belongs to". It's trust in the key, not in the user. GPG only cares about authenticating the messages, that is verifying that the message is from whoever it claims to be. You would need to have another level of trust on top of GPG to say that you trust some person.

Some version control systems have a list of GPG key fingerprints written down somewhere. If a patch comes in that is signed by one of those keys, it gets merged (or committed, or whatever). That file with the fingerprints and the script that makes the decision to merge is that additional layer on top of GPG.

Two GCC stories

Posted Jun 30, 2010 17:14 UTC (Wed) by ptman (subscriber, #57271) [Link] (1 responses)

I shouldn't post stuff when tired. I just realized that I forgot to take the next step in GPG's web-of-trust. Of course if your trust in a key that isn't signed by yourself is affected by the trust of someone else in that key, they enjoy your trust in more ways than that which I claimed was the only way GPG considers trust.

TL;DR Nevermind. Ignore what I said.

PGP trust

Posted Jun 30, 2010 18:18 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

PGP even makes this explicit, and documents the difference, explaining that you may want to sign the identity of your naive best friend Bill on his key, knowing that it's really his key, but not trust him to authenticate other people's keys. Bill's naivety doesn't make his key any less authentic, but it makes his claims about the identities associated with other keys untrustworthy because he is easily fooled.

Further, PGP lets you "score" this property and set rules like "if the scores of the people who've signed this identity add up to 14 or more then assume it is real". This is in practice too advanced for most users, but it's there if you have a real use case for the web of trust.

Two GCC stories

Posted Jul 1, 2010 0:21 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (5 responses)

What you sign in PGP or GPG is the association between an identity and a key. Here are some example identities, and what it means if you sign them:

Barry Trotter - You believe the key owner is named Barry Trotter, e.g. you have seen government photo ID proving that this is their name, or you know them well personally and they have always gone by this name.

<barr@example.com> - You believe the key owner is contactable by the barr@example.com email address

http://barry.example.com/ - You believe the key owner has control over the barry.example.com machine or the web site found there

[a photo] - You believe this is a reasonably current image of the key owner.

NB signing an identity is distinct from trusting the key owner to authenticate other people in the web of trust. BUT it makes no sense to give this trust to an unsigned key. How can you trust "their" opinions if you don't know anything at all about them? That makes no sense. "They" may be a facsimile providing a composite of opinions from other people you trust... until you grant them enough trust to be exploited, and then it's game over.

Two GCC stories

Posted Jul 1, 2010 0:44 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (4 responses)

Also, you might think you don't care about the identities. But it turns out you do. Suppose you get used to having a lot of PGP keys that you "trust" without caring about their identity, and use to communicate about relatively mundane things like security holes in Internet Explorer - and also you have a PGP key for Boris, with whom you are conspiring to blow up the Eiffel Tower.

One day you get a PGP message, with Bob's email address in the From line, and a valid PGP signature. It asks if you can provide the exact co-ordinates of "the target". This is a bit silly, the Eiffel Tower is on public maps, but you humour Bob by providing WGS84 co-ordinates. A few minutes later, with the last piece of their investigate puzzle now in place, the anti-terror police kick your door in. Whoops, it wasn't Bob after all - one of the IE hackers who you "trust" turns out to be a policeman and your lax approach to identity made him indistinguishable from Bob.

A decent PGP-backed communication system (e.g. email client) will figure out which key signed the data you're looking at, then find which identities associated with that key are signed by you or someone you trust, and show those. So you'll know whether the mail is from "Bob". But only if you bother to use the key signing features properly.

Two GCC stories

Posted Jul 1, 2010 14:20 UTC (Thu) by fsateler (subscriber, #65497) [Link] (3 responses)

But is the signature on the e-mail made with the same key that has been in use all along to communicate? If yes, the problem was not of identity, but misplaced trust, and if not, the problem is between the chair and computer.

Two GCC stories

Posted Jul 2, 2010 8:17 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

It's dismissive to say "the problem is between the chair and computer" when a human fails to do an exact bit-for-bit comparison between two public keys, meaningless strings of thousands of bits.

PGP humanises public key cryptography by associating keys with identities. Someone who refuses to take advantage of that (like yourself) is asking for trouble precisely because humans aren't very good at such bit-for-bit comparisons.

What did you want this "trusted but unidentified" behaviour for anyway?

Two GCC stories

Posted Jul 2, 2010 16:23 UTC (Fri) by fsateler (subscriber, #65497) [Link] (1 responses)

That was precisely my point, that GPG does not help in this situation.

And I want that behaviour for online collaboration. It is not always possible to build a GPG trust path to someone, but you can work enough with people to decide you trust them.

trust and identity

Posted Jul 3, 2010 20:32 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

You trust them? How do you trust them? You apparently don't believe you know any way of identifying them, not even by a pseudonym or a drop box email address. And you have no realistic way to distinguish one of these people you supposedly trust from any of the others.

Let me suggest that, in fact, you do associate these trusted keys with identities. You can sign this association, and that creates a cryptographically trustworthy mechanism for PGP to tell you "Abraham sent this" or "Bethany sent this" when it processes a future message signed with those keys - and that at last sounds like something you might be able to make use of in "online collaboration".

PGP is not a cloud application. The fact that you, on your PC, decided that this particular key belongs to "Abraham" is not automatically a fact shared with the whole world or even with "Abraham". You are not obliged, technically or ethically, to publish it, or tell anybody else. Similarly you are not required or expected to trust that whatever "Abraham" tells people (including by publishing signed keys) is true. You need never tell "Abraham" that you've assigned it this name, and if you prefer you can use outlandish or ridiculous names, "Mr Run-on-sentence" or "Flopdeedoodle"

Identity and trust are separate issues BUT for humans it isn't practical to hang trust on raw thousand-bit key values, so you must do SOMETHING about the identity issue first. That's all PGP/ GPG asks you to do.

Two GCC stories

Posted Jul 2, 2010 8:51 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link]

You can do that with GPG. For people I know from the net but never met in real life I use "lsign" in the edit menu. Most frontends have a checkbox for this. Local signing means that you trust the key but you don't want to vouch for it in the public.

In any case it is entirely up to you how you do the suggested identity verification when you sign a key. It is your and only your personal policy.

GPL works just great for documentation

Posted Jun 30, 2010 16:53 UTC (Wed) by SLi (subscriber, #53131) [Link] (14 responses)

There's no reason why GPL is a bad license for documentation. That's just GNU propaganda trying to justify their non-free license for documentation (yes, having to include a lengthy RMS manifesto verbatim with documentation snippets is clearly non-free to me).

There was really no problem until FSF decided GPL isn't good for documentation and made GFDL. I'm not aware of a single legal issue with using GPL with documentation. The core concepts are really quite clear, like "preferred form of modification".

GPL works just great for documentation

Posted Jun 30, 2010 20:18 UTC (Wed) by josh (subscriber, #17465) [Link] (1 responses)

Agreed entirely. The best possible license for a project's documentation is exactly the same license that project's source code uses.

GPL works just great for documentation

Posted Jun 30, 2010 22:47 UTC (Wed) by ballombe (subscriber, #9523) [Link]

Furthermore: one must not advertise that software foo is licensed under the GNU GPL when the documentation is licensed under the GFDL, because the documentation s a part of the software. One have to mention both licenses, else it is misleading.

GPL works just great for documentation

Posted Jul 1, 2010 7:29 UTC (Thu) by mjthayer (guest, #39183) [Link] (5 responses)

>There was really no problem until FSF decided GPL isn't good for documentation and made GFDL.

Simple solution though - just dual licence any bits that may end up in the documentation.

GPL works just great for documentation

Posted Jul 1, 2010 8:31 UTC (Thu) by liljencrantz (guest, #28458) [Link] (4 responses)

The problem is that documentation comments are embedded within the source code, potentially in _any_ file. You either have to dual license the entire project under the GFDL, or make a silly clause like «any comment anywhere in the source code is also licensed under the GFDL», something that I doubt you're allowed to do.

GPL works just great for documentation

Posted Jul 1, 2010 8:39 UTC (Thu) by mjthayer (guest, #39183) [Link] (3 responses)

> The problem is that documentation comments are embedded within the source code, potentially in _any_ file. You either have to dual license the entire project under the GFDL, or make a silly clause like «any comment anywhere in the source code is also licensed under the GFDL», something that I doubt you're allowed to do.

It works if you apply the policy before you start creating documentation comments, which would make some sense. Then you just reject patches that don't comply.

Or if you mark "approved" documentation comments in some way.

GPL works just great for documentation

Posted Jul 1, 2010 10:17 UTC (Thu) by liljencrantz (guest, #28458) [Link] (2 responses)

Sounds like a maintenance nightmare, pure and simple.

GPL works just great for documentation

Posted Jul 1, 2010 11:20 UTC (Thu) by sflintham (guest, #47422) [Link] (1 responses)

Dual-licensing all the code under GPLv3 and GFDL wouldn't be a maintenance burden though. And since the FSF requires copyright assignments, this should be easy. What would be wrong with this solution? Would having the code available under a GFDL licence grant any undesirable options to anyone?

GPL works just great for documentation

Posted Jul 2, 2010 15:50 UTC (Fri) by cortana (subscriber, #24596) [Link]

If the documentation was available under the GPL then others would be able to distribute it without including the propaganda that the GFDL forces you to leave in.

GPL works just great for documentation

Posted Jul 1, 2010 8:29 UTC (Thu) by liljencrantz (guest, #28458) [Link] (5 responses)

Exactly.

Code is text, just like documentation. They are both usually stored in human readable form and compiled into machine readable form before use. Many documentation languages, like TeX and PS, are simply programing languages optimized for generating documentation. Others, like html, come with a full featured programming language embedded. Most modern computer languages support writing documentation and source code as a single entity, that can be used by different compilers to generate either a documentation document or a running program.

GPL concepts like preferred format and prohibiting further restrictions are equally applicable to code and documentation. The clause about selling GPLed works is more relevant for documentation than for software; it allows you to charge money for high quality printed versions of a text, while forcing you to include the source version of the text. The company I work for releases all documentation under GPL3. The Debian project recommends the GPL for documentation (http://www.debian.org/vote/2006/vote_001.en.html#amendmen...).

Corbet, it seems to me that the only argument against using the GPL for documentation is that FSF says so, please elaborate on why you consider the GPL «a poor fit for text».

GPL works just great for documentation

Posted Jul 2, 2010 8:43 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link] (2 responses)

Right. The GPL is just fine for documentation. If you want to print a book it is easy to glue a CDROM into it or put in the required written promise to deliver the source code/text. The FDL has been forced on the GNU maintainers without a ny valid reasons; only a few of them silently refused to do that and keep on using the GPL for docs.

GPL works just great for documentation

Posted Jul 9, 2010 0:11 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

The problem with "gluing a CD rom in a book" is REAL in the EU, or in the UK at least.

Books, in the UK, are zero-rated for VAT. A typical computer reference book costs £40. On the other hand, a "book plus CD" combo is liable for VAT - at £40 this will be £8.

So any poor sod buying that book is going to get stung for $15 dollars tax for a "freebie" CD :-(

Cheers,
Wol

VAT

Posted Jul 14, 2010 14:24 UTC (Wed) by edmundo (guest, #616) [Link]

You don't have to pay VAT on the whole price of a "book plus CD". You are allowed to apportion the price and pay VAT on just the CD component. However, it's a complication that you may prefer to avoid.

GPL works just great for documentation

Posted Jul 2, 2010 12:07 UTC (Fri) by njwhite (guest, #51848) [Link] (1 responses)

This seems like a good point, I hadn't really considered GPL for documentation, but I agree, it seems concepts like preferred format of modification are pretty clear in the case of documentation too, and are just as useful. Am I right in thinking that the Linux docs are GPL (I don't see anything to the contrary, though I didn't look hard)?

I'd be interested to hear someone weigh in on why it may not be appropriate.

GPL works just great for documentation

Posted Jul 2, 2010 20:41 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

Depends on what "Linux docs" you are talking about.

The stuff under Documentation/ in your local kernel source is GPLv2
The manpages here state "GPLv2+ and GPL+ and BSD and MIT and Copyright only and IEEE"
The stuff on TLDP is GFDL 1.2 by default, but others apply to various parts
The book by our esteemed editor and others is Creative Commons Attribuution-ShareAlike 2.0

I'm sure there are countless others, going all the way from public domain to completely closed.

Two GCC stories

Posted Jun 30, 2010 17:05 UTC (Wed) by nix (subscriber, #2304) [Link] (17 responses)

NightStrike, who still refuses to provide that information

The post you link to has NightStrike pointing out that he was never asked to provide any real-world contact information. Just a 'real-sounding' name. As a security policy, this is... weak.

Two GCC stories

Posted Jun 30, 2010 21:53 UTC (Wed) by fuhchee (guest, #40059) [Link] (16 responses)

"... As a security policy, this is... weak. "

Or would be, if it was true, which it isn't.

Two GCC stories

Posted Jun 30, 2010 22:20 UTC (Wed) by nix (subscriber, #2304) [Link] (15 responses)

Hang on, are you accusing NightStrike of lying, or what?

Two GCC stories

Posted Jun 30, 2010 22:43 UTC (Wed) by ewan (guest, #5533) [Link]

Sounds more like a horrible misunderstanding. Clearly, if NightStrike hasn't tried supplying a false name they can't actually know that that would have worked.

Two GCC stories

Posted Jun 30, 2010 22:56 UTC (Wed) by fuhchee (guest, #40059) [Link] (13 responses)

Since you asked for elaboration:

"The post you link to has NightStrike pointing out that he was never asked to provide any real-world contact information. Just a 'real-sounding' name. As a security policy, this is... weak. "

It is not correct that "he was never asked to provide any real-world contact information". It is not correct that he was asked "just for a real-sounding name". It is not correct that this is our security policy.

Other than that, the story was accurate.

Two GCC stories

Posted Jun 30, 2010 23:43 UTC (Wed) by nix (subscriber, #2304) [Link]

Ah, right, he was asked in some later post that Jon never got to (I'd say 'that postdated Jon writing the article', only we all know that Jon writes these articles in the future and emails them back to himself in the past, so that's impossible).

It makes more sense now.

Two GCC stories

Posted Jul 1, 2010 15:24 UTC (Thu) by k8to (guest, #15413) [Link] (11 responses)

The best method of correction incorporates clarification in the form of positive information.

Two GCC stories

Posted Jul 4, 2010 19:19 UTC (Sun) by nix (subscriber, #2304) [Link] (10 responses)

I've now read the entire set of list threads in question. If NightStrike was asked for this sort of thing, he never mentioned it, and nobody *else* ever mentioned it, even on the overseers list. But there's a lot of evidence of substantial backchannel/non-publically-archived stuff going on here, so this is not conclusive by any means.

Two GCC stories

Posted Jul 4, 2010 21:23 UTC (Sun) by fuhchee (guest, #40059) [Link] (9 responses)

"If NightStrike was asked for this sort of thing, he never mentioned it"

I assume you are solely referring to "real-world contact information" issue.

As far as I know, no one asked this person his/her phone number, address, bank account numbers, date of birth, schooling & employment history, if that's what you mean. Since he was unwilling to disclose even his real name, do you believe that such a questionnaire would have been anything but a waste of time?

Two GCC stories

Posted Jul 4, 2010 21:39 UTC (Sun) by sfeam (subscriber, #2841) [Link] (6 responses)

I am appalled that a project would require any of those as a prerequisite for accepting a contibution of patches or new code.

Two GCC stories

Posted Jul 4, 2010 23:10 UTC (Sun) by fuhchee (guest, #40059) [Link] (5 responses)

"I am appalled that a project would require any of those as a prerequisite for accepting a contibution of patches or new code."

Lucky thing then that GCC does not.

My purpose in listing those things is to figure out what nix thinks what if anything we might have asked "NightStrike" as a substitute for his real name to ascertain his identity. Recall too that this whole kerfuffle was not about contributing some random gcc patch, but about getting some semi-administrative access to the project hosting server.

Two GCC stories

Posted Jul 7, 2010 16:05 UTC (Wed) by nix (subscriber, #2304) [Link] (4 responses)

I agree that you need more info than that. I'm just reasonably certain that rejecting a name on the basis that it doesn't sound real enough and then not asking for a more extensive authenticator is not an effective security policy: it'll only keep out those who are honourable enough to not use a real-sounding pseudonym, i.e. those who are not bad guys. I'm not saying 'oooh, you should have let NightStrike in with no authentication at all', I'm saying 'hang on, who the hell else have you let in if a real-sounding name is all you need'? If that's all you need, you have survived without major attacks by virtue of chance and obscurity, nothing more.

(As an aside, I know NightStrike was unwilling to disclose his real name to the entire publically-archived GCC list, but I know the GNU Project has non-public backchannels over which this sort of info can pass. If NightStrike was unwilling to provide better authenticators that way as well, then I don't see how you can possibly let him onto gcc.gnu.org; but if he was never asked, then it looks to me like you threw away a contributor unnecessarily.)

Two GCC stories

Posted Jul 7, 2010 16:14 UTC (Wed) by fuhchee (guest, #40059) [Link] (3 responses)

"I'm just reasonably certain that rejecting a name on the basis that it doesn't sound real enough"

This person admitted the obvious that "NightStrike" is not real. AFAIK only he and his sympathisers suggested in later editorial comments that a "real-enough" but fake name might have been acceptable.

"and then not asking for a more extensive authenticator"

Please advise what forms this "more extensive authenticator" might have taken.

"is not an effective security policy"

Rejecting questionable requests for pseudo-admin access is a fine security policy.

Two GCC stories

Posted Jul 7, 2010 18:24 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

This person admitted the obvious that "NightStrike" is not real. AFAIK only he and his sympathisers suggested in later editorial comments that a "real-enough" but fake name might have been acceptable.

But how would you have known if it wasn't? Ignoring someone who points out a huge gaping flaw in your security policy because you don't like their name is not clever.

As for better authenticators, well, you've already mentioned things like home addresses, phone numbers, et seq. Of course all of these are fakeable: one must estimate the determination of possible attackers when figuring out which to rely on. But NightStrike is quite right that relying on 'a real-sounding name' gives you nothing: it drives away those who wish to or must use pseudonyms while failing to keep out any bad guys at all.

Two GCC stories

Posted Jul 7, 2010 18:47 UTC (Wed) by fuhchee (guest, #40059) [Link] (1 responses)

"But how would you have known if it wasn't?"

So let me get this straight. *Because* we refuse to give someone
logon privileges (for reasons that even you are sympathetic to), you
complain about a hypothetical opposite situation where we might
someday give access to someone else? So actual evidence of our
prudence is twisted to insult to our hypothetical straw-man
security policy?

Dude. Really.

I am not prepared to disclose a full investigative plan to be applied
to an arbitrary person seeking such access. "It depends." But I am
prepared to promise this: being "merely real-sounding" has not and
will not be sufficient.

Two GCC stories

Posted Jul 7, 2010 21:20 UTC (Wed) by nix (subscriber, #2304) [Link]

Right, good. That was all I was concerned about.

Two GCC stories

Posted Jul 7, 2010 16:00 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

So, let's see. You said

It is not correct that "he was never asked to provide any real-world contact information".

And now you're saying

I assume you are solely referring to "real-world contact information" issue.
As far as I know, no one asked this person his/her phone number, address, bank account numbers, date of birth, schooling & employment history, if that's what you mean. Since he was unwilling to disclose even his real name, do you believe that such a questionnaire would have been anything but a waste of time?

I think that's one contradiction there, so I am forced to conclude that the root of your security policy is in fact "does this person's name sound real". As I said above, this is... weak.

Two GCC stories

Posted Jul 7, 2010 16:04 UTC (Wed) by fuhchee (guest, #40059) [Link]

"I think that's one contradiction there"

Not at all. He (?) was asked for his real name. That is a part -- really, the very first & most basic part -- of one's "real-world contact information".

Two GCC stories

Posted Jun 30, 2010 19:55 UTC (Wed) by jimparis (guest, #38647) [Link] (2 responses)

Two GCC stories

Posted Jun 30, 2010 20:46 UTC (Wed) by cry_regarder (subscriber, #50545) [Link] (1 responses)

Whatever happened with that?

Two GCC stories

Posted Jul 1, 2010 13:38 UTC (Thu) by wagner17 (subscriber, #5580) [Link]

See here.

Two GCC stories

Posted Jun 30, 2010 23:56 UTC (Wed) by dirtyepic (guest, #30178) [Link] (10 responses)

What I find to be more interesting is that NightStrike first offered to merely ping patches that hadn't received attention or had been approved but never committed, and asked if people would please reply to a patch thread when committing the code. This was met with some responses such as

> By the way, I wonder how many contributors can even think taking
> seriously a message coming from "NightStrike". Not me, for sure...

and

> Like Paolo, I'm a lot more likely to read a message from someone with
> a real name, or at least a name that sounds real.

So for me at least, there is an issue here that has nothing to do with security, and everything to do with the perception of identity. This individual isn't writing or reviewing or checking in code, they're offering to perform a service to the community - a menial one at that - and are being refused on the basis of their name. Is this justifiable? Is it appropriate to turn down contributers, not based on their actions or work, but on some aspect of their persona? If you replace "real" in that second quote with "Chinese" or "female" it becomes ludicrous. After all, that would be discriminatory. But how is this any different? Maybe because it's an affectation? Maybe it's on the shoulders of the contributor to be responsible for conforming to the social norms of the community. But should a person really be judged on anything but their actions, and can communities afford to alienate those want to contribute useful work but retain their anonymity? It's an interesting line to walk.

R. Hill (if that's important to you)

Two GCC stories

Posted Jul 1, 2010 9:28 UTC (Thu) by NAR (subscriber, #1313) [Link] (6 responses)

and are being refused on the basis of their name.

You're wrong. He's not refused based on his name - he's refused based on his lack of real (sounding) name. The last time I was in the company of people I hadn't knew before, we introduced ourselves. Of course I have no way to verify that her name is really the one she said, but still, it's general politeness (and not security measure!) to state one's name.

Of course, this depends on that particular community. In some mailing lists I've subscribed it's recommended to use a real name. In web forums generally it's not recommended to state a real name. Policies vary.

names

Posted Jul 1, 2010 11:01 UTC (Thu) by jpnp (guest, #63341) [Link] (5 responses)

The whole concept of "real-sounding name" is incredibly subjective.

Your name is what is commonly used to identify yourself. If you use different identifiers in different contexts then you can have multiple versions of your name (e.g. many people called Jon actually have Jonathan on the birth certificate or passport).

I have a number of friends and acquaintances who were first introduced to me in real life by what started out as nick-names or online idents. Some of these people use a nick-name in personal life and their original birth name in their professional life, some use their nick-name with everyone but their passport and bank account, some have gone through the process of legally registering their new name and have no other legal name! In many cases I went years before knowing which category my friends were and what their official name was.

Requiring real-world identifiable contact details before allowing someone to sysAd important project infrastructure seems sensible enough. Ignoring people's contributions to mail-lists because it fails your subjective realness test just seems pathetic.

names

Posted Jul 3, 2010 2:52 UTC (Sat) by giraffedata (guest, #1954) [Link] (4 responses)

I think it's more sane than that. First of all, I dispute that NightStrike isn't a real name. What it is is a name that appears likely not to be the name he uses in parts of his life he cares about. And that makes one believe he's hiding. He wants to be able to do and say things that he can't be made to pay for in those other areas of his life.

Maybe that's an unreasonable suspicion, but I think that's at the base of people's reaction to dealing with people who go by cute screen names.

names

Posted Jul 7, 2010 14:59 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

There are other interpretations, though. I've used the name I use here as an on-net pseudonym for almost twenty years now, but not as an attempt to evade real-life consequences; more as an indication of a shift in personality. Me-in-real-life *does not act* like me-on-the-net, and the name change makes that more obvious than it might otherwise be.

Now perhaps this is uncommon, but it's not unheard of.

names

Posted Jul 12, 2010 21:55 UTC (Mon) by Tet (guest, #5433) [Link] (2 responses)

Then, of course, there are people like me. Some 20 years ago now, I legally changed my name to be my online pseudonym. It might not sound real, but it is now my real name...

names

Posted Jul 12, 2010 22:44 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

There are several people who've done the same thing. The man now known as MegaZone is one.

(btw, presumably you kept a surname, for convenience's sake if nothing else? So very many things fall over, from ecommerce to random form-filling and bank applications, if you don't have a surname...)

names

Posted Jul 13, 2010 8:05 UTC (Tue) by Tet (guest, #5433) [Link]

No, I didn't keep a surname. And yes, only having a single name does cause all manner of things to fall over. I've got used to it by now...

Two GCC stories

Posted Jul 1, 2010 10:54 UTC (Thu) by jwakely (guest, #60262) [Link]

> This individual isn't writing or reviewing or checking in code, they're offering to perform a service to the community - a menial one at that - and are being refused on the basis of their name.

That was only one part of (some people's) objections, not all contributors were happy with his process.

Currently someone submits a patch for review, maintainers review and maybe approve it for checkin. NightStrike was then replying to every thread asking "has this been checked in?", requiring the submitter or reviewer to confirm something that's already available publicly in the ChangeLog files, svn history, gcc-cvs mail archive etc. -- that was seen as unnecessary noise.

Two GCC stories

Posted Jul 1, 2010 20:08 UTC (Thu) by pebolle (guest, #35204) [Link]

> If you replace "real" in that second quote with "Chinese" or "female" it becomes ludicrous.

Maybe that is because when you do that you change the reasoning behind that argument beyond recognition.

Two GCC stories

Posted Jul 9, 2010 0:17 UTC (Fri) by Wol (subscriber, #4433) [Link]

My logon id here is a nym. It's pretty obviously not real (and most people will know the children's story it comes from).

But it's BASED ON a real name of mine - note I carefully did not say "my real name".

Why shouldn't people want to use a nym? After all, on the net no-one know you're an owl :-)

Cheers,
Wol

petty squabling

Posted Jul 1, 2010 1:57 UTC (Thu) by tlw (guest, #31237) [Link] (5 responses)

"So incorporating GPLv3-licensed code into a GFDL-licensed document and distributing the result would be a violation of the GPL."

I'm having a hard time deciding what's more pathetic:

The fact that the same body which: i) wrote the code, ii) developed the license for that code, and iii) developed the license for the documentation for that same code somehow created a situation where text from one couldn't be placed into the other. Despite the fact the #1 goal of said body is freedom.
The fact that someone actually examined these licenses in sufficient detail to discover this "problem".
The fact that this is a "problem" to anyone.

Sometimes I'm embarrassed to be part of this community; this is one of those times. Honestly, if someone goes ahead and puts that GPLv3 code into the GFDL document... who's going to sue? Is someone from the gcc community really going to take legal action against a gcc developer for this horrific breach of licensing? In the grand scheme of things it seems to me there are better things to do with my time; apparently I'm in the minority.

:-)

petty squabling

Posted Jul 1, 2010 8:56 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (4 responses)

Trivially, the first. (It would be pathetic even if GFDL wasn't broken. As far as I can tell, if a software package's manual is GFDL'd and uses the Cover Text provisions, then you have to write your own manual from scratch if you fork the package and want to provide a not-misleadingly-labelled manual for it.)

Examining licences for conflicts is like searching the interactions between two parts of your security-relevant software system for pathological edge cases. Tedious and pernickety, but if you don't do it, you can be sure the bad people will.

Oh, and I have a vague feeling that there's a jurisdiction somewhere where a third party (i.e. not the rights-holder or violator) can cause a copyright action to be initiated.

petty squabling

Posted Jul 1, 2010 18:05 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (3 responses)

OK, say I want to create a fork of GCC (let's call it EGCS just for kicks). If the FSF's GCC-powers-that-be aren't happy with my fork (presumably they aren't, why fork if we are in full agreement?) they could cause the EGCS project no end of grief. That sounds like a rather powerful incentive for not forking -- and as Linus explained somewhen in a rationale for git (sorry, can't find it now) one of its objectives is precisely to make forks easy, as that keeps the project alive. The egcs fork was instrumental in getting GCC development going again, much of what is GNU emacs today was first in xemacs. Without being able to fork (and survive) the current X.org wouldn't be either.

petty squabling

Posted Jul 2, 2010 13:12 UTC (Fri) by coriordan (guest, #7544) [Link] (2 responses)

> much of what is GNU emacs today was first in xemacs

Bit of an exaggeration there.

For one, xemacs' period of technological advancement, while it did last few years, ended long ago. The project's lists are nothing but spam nowadays and GNU Emacs is now much more advanced. In a project which dates back to 1976, the xemacs period isn't as large as one could think.

Another thing is that while the xemacs folk could borrow all progress from GNU Emacs, the GNU team got almost no code from the xemacs folk because the latter didn't document the copyright ownership of their code.

So the system was stacked against GNU Emacs, and it still won. They can't be doing too badly.

slander [was: petty squabling]

Posted Jul 2, 2010 17:38 UTC (Fri) by vladimir (guest, #14172) [Link] (1 responses)

> The project's [XEmacs] lists are nothing but spam nowadays

Entirely untrue. A quick look at the current archives of xemacs-beta, xemacs-patches and xemacs-review will show that you have no idea of what you're talking about.

> Another thing is that while the xemacs folk could borrow all progress from GNU Emacs, the GNU team got almost no code from the xemacs folk because the latter didn't document the copyright ownership of their code.

Again, untrue, and I speak from personal experience, having been involved in the discussions between RMS and the XEmacs developers. There were real technical issues in contention. The copyright stuff is a red herring used by RMS to trump any technical arguments. BTW, XEmacs either has or will shortly switch to a GPL3 license.

And, for "Striiiiike three! You're out!" XEmacs' use of anti-aliased fonts long preceded GNU Emacs' use. (The look and feel of the user interface was one of the technical issues in contention.)

For masochistic folks interested in revisiting a boring and long dead issue, you can start by reading "The XEmacs Split" section in the XEmacs Internals manual. In there are pointers to more discussion.

slander [was: petty squabling]

Posted Jul 4, 2010 5:13 UTC (Sun) by foom (subscriber, #14868) [Link]

> The copyright stuff is a red herring used by RMS to trump any technical arguments.

Ehhhh... GNU emacs requires copyright on code contributions to be assigned to the FSF. XEmacs does not. Therefore, GNU emacs cannot simply take code from xemacs, but xemacs can take code from GNU emacs.

You might claim that GNU emacs shouldn't have the copyright assignment policy, but that doesn't change the fact that they DO have it, and that it would be difficult at this point to figure out how to get assignments for the code in xemacs.

Two GCC stories

Posted Jul 1, 2010 17:16 UTC (Thu) by cracauer (guest, #15239) [Link] (5 responses)

Where's the third story, which is that the GPLv3 on the newest GCCs create quite a bit of a mess for the BSDs and for Apple, and they might do something about it?

If it leads to a second high-quality compiler that's fine with me but the method chosen is quite appalling.

Right now the BSDs and Apple use a GPLv2ed compiler. They have to and voluntarily do feed changes back. If they switch to a compiler that isn't GPLed at all as a reaction to the GPLv3 you would remove that.

I am not a friend of the GPL in the first place but my understanding of the thought behind the GPL is that they want changes fed back. They achieve quite the opposite.

Two GCC stories

Posted Jul 1, 2010 19:55 UTC (Thu) by pebolle (guest, #35204) [Link] (3 responses)

> [...] my understanding of the thought behind the GPL is that they want changes fed back.

I'm not going to be pedantic and add a link to documents describing the four freedoms the GPL is designed to protect. But encouraging to have "changes fed back" is not included in those freedoms, not even implicitly.

Two GCC stories

Posted Jul 1, 2010 22:04 UTC (Thu) by cracauer (guest, #15239) [Link] (2 responses)

OK, let me rephrase it.

The point about the GPL is that changes to a certain package stay free.

Making changes to the GPL that drives existing users (and contributors) of GPLed software into switching to software that is not GPLed at all doesn't seem to serve that goal. That applies to both the amount of free software out there in general, and it also applies to fixes and improvements to the GPLed package in particular, in this case gcc.

It gets worse when the new license is more complicated and creates legal issues even within GNU software, as shown here.

Two GCC stories

Posted Jul 3, 2010 22:26 UTC (Sat) by foom (subscriber, #14868) [Link]

Sorry, the issues aren't new with GCC's switch to the GPLv3. It's really got nothing to do at all with the GPL. It is the entirely predictable result of using a broken license (GFDL) for the documentation, instead of the GPLv3.

Amount of free software

Posted Jul 4, 2010 11:19 UTC (Sun) by man_ls (guest, #15091) [Link]

Speaking as a card-carrying FSFE supporter: the goal of the FSF is not so much to increase the amount of free software, as it is to make all developers and users aware of the role of freedom in software development and usage. Even a larger number of users is not as important as having conscious users. The amount of free software follows from the awareness, and not the other way around.

Let's see a prominent example: Apple's OS and certain core components based in free software. If people using these free components are completely unaware of the benefits of the freedoms they have (because the free parts are embedded in a thick layer of proprietary software) then said freedoms are not doing any good, except for Apple developers. As Apple users outnumber Apple developers by a large factor, making a small number of those users aware of why freedom is important would be much more important than having Apple developers switch to proprietary software. You can easily see why, in this regard, a marginal but freedom-aware OS like Debian is much more important to the free software movement than a popular but oblivious platform such as Apple iOS, or even Android.

On the other hand it would appear that the Open Source movement does indeed worry mostly about the amount (and number of users) of free software, even if in the process the freedom part is toned down. Many Linux developers are firmly in this camp, and that is why they would like to maximize use of Linux everywhere, even if certain components have to stay proprietary to achieve it.

There is a middle ground here (maximize the number of users while educating them in freedom), but as is so often the case it is not easy to achieve.

Contributions from Apple and *BSD?

Posted Jul 8, 2010 13:07 UTC (Thu) by froydnj (guest, #68565) [Link]

> Right now the BSDs and Apple use a GPLv2ed compiler. They have to and voluntarily do feed changes back.

Minor nit: nobody has to feed their patches back.

Please point to significant patches provided by the BSDs and Apple recently. I think I've seen a few +/-10 lines patches for *BSD configury and the like over the last several years, but epsilon-close-to-zero contributions from Apple. I do realize Apple has contributed significant bodies of work in the past, but those days are long gone. My impression of the BSDs is that while they may make changes locally, those changes tend to not make it back to the FSF source tree.

Two GCC stories

Posted Jul 1, 2010 18:56 UTC (Thu) by wingo (guest, #26929) [Link]

One might think from the article that pseudonymous contributions were not allowed in GNU; this is not the case. From http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html#Copyright-Papers:

If a contributor wants the FSF to publish only a pseudonym, that is ok. The contributor should say this, and state the desired pseudonym, when answering the request- form. The actual legal papers will use the real name, but the FSF will publish only the pseudonym. When using one of the other forms, fill in the real name but ask the contributor to discuss the use of a pseudonym with assign@gnu.org before sending back the signed form.

For me as a GNU maintainer, NightStrike's perspective makes me think s/he does not trust the FSF -- not the other way around.

Two GCC stories

Posted Jul 1, 2010 19:24 UTC (Thu) by utoddl (guest, #1232) [Link] (3 responses)

You've got me curious. So what has been going on in the ongoing development of GNU cat?

Two GCC stories

Posted Jul 1, 2010 22:58 UTC (Thu) by xnox (subscriber, #63320) [Link] (2 responses)

There is a secret much faster fork of GNU cat, called GNU mouse. Unfortunately FSF is not accepting patches because it is written by a collaborative team of dogs, cats and mice.

Two GCC stories

Posted Jul 2, 2010 0:06 UTC (Fri) by SiliconSlick (guest, #39955) [Link]

...and in GNU cat development, on June 18, Eric Blake of Redhat committed a barely perceptible and widely ignored change to improve its documentation. No gibbons, parrots or wombats were harmed by, or in any way involved with, the event.

SS (who assumes that was left out because it was from last week)

Two GCC stories

Posted Jul 2, 2010 4:46 UTC (Fri) by aigarius (subscriber, #7329) [Link]

http://packages.debian.org/lenny/dog

GPL and text

Posted Jul 2, 2010 4:26 UTC (Fri) by TRS-80 (guest, #1804) [Link] (6 responses)

Speaking of GPL and text, what happens when you include GPL JavaScript code in a webpage? Must the rest of the page also be licensed under the GPL?

GPL and text

Posted Jul 2, 2010 11:36 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

IANAL but my guess is it would depend. Suppose the Javascript just causes a snowflake to appear and drift down any arbitrary web page in which it is included. In this case the page with Javascript seems to be "mere aggregation"

OTOH suppose the Javascript is thoroughly wound into the structure of the page, constantly mentioning specific HTML elements by their ID from deep inside functions, making assumptions about the exact text inside a node and so on. In this case it seems as though the Javascript + HTML are a single work, and arguing that the JS is licensed as a separate work would be laughable.

But then in the latter case the author of the Javascript is probably the owner of the whole work, and nothing prevents creators from asserting license terms that are impossible to fulfil or even totally incoherent. In this case you should treat it as though you weren't offered a license at all.

GPL and text

Posted Jul 2, 2010 18:07 UTC (Fri) by southey (guest, #9466) [Link] (1 responses)

Speaking of GPL and text, what happens when you include GPL JavaScript code in a webpage?
Hopefully it works as intended.

Must the rest of the page also be licensed under the GPL?
If you are not distributing that code then the GPL terms do not apply so an answer is no. But the sore point is that some people consider serving/accessing a web page as redistribution (very gray area since both sides have valid arguments). So it may be a different story with the GNU Affero General Public License!

If you are distributing the web page including GPL code as say downloadable file or in some package then you must follow the GPL regarding bundling software packages together.

GPL and text

Posted Jul 3, 2010 0:57 UTC (Sat) by dvdeug (subscriber, #10998) [Link]

I'm not familiar with any controversy; if you send someone a webpage, whether by HTTP or email or printed out and mailed, you have to follow the licenses for the material that you're sending them. It's distribution. The Affero license is all about code that runs on the server and creates the webpage, not code that you send to the end user.

GPL and text

Posted Jul 9, 2010 0:30 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

One thing to bear in mind - iirc javascript is interpreted, no?

I'd need to re-read the GPL to be sure, but if you distribute AS SOURCE, which a java-script scriptlet is, most of the nasty stuff in the GPL doesn't apply.

So you MIGHT find that you can include large chunks of javascript in your web-page and it falls under "mere aggregation", not contaminating anything else.

But IANAL, YMMV etc etc.

TTFN
Wol

GPL and text

Posted Jul 9, 2010 5:22 UTC (Fri) by bronson (subscriber, #4806) [Link]

True, as long as you don't minimize the javascript. :-/

GPL and text

Posted Jul 9, 2010 6:53 UTC (Fri) by paulj (subscriber, #341) [Link]

The GPL requires that source be distributed in its preferred form (i.e. the original source). So if you took some GPLed Javascript work, then ran it through an obfuscator before redistributing it in web-pages, then you'd be in breach of the licence.

Two GCC stories

Posted Jul 5, 2010 13:11 UTC (Mon) by shlomif (guest, #11299) [Link] (5 responses)

One thing I don't understand is: why do the GCC developers have a need to implement a patch review system, when many such FOSS solutions exist. Bugzilla and other bug-trackers can be effectively used to track patches and make sure they are not lost and the KDE people have a similar system for patch tracking in place over at http://reviewboard.kde.org/ (in addition to bugzilla). Why do they find these systems inadequate?

Two GCC stories

Posted Jul 5, 2010 14:23 UTC (Mon) by foom (subscriber, #14868) [Link] (1 responses)

Well, GNU encourages all sorts of strange and harmful coding practices. My favorite, which I've written about before: the requirement to omit any sort of useful information from commit messages. http://fuhm.livejournal.com/5850.html

Now, if they had a useful patch review system, that might make it too easy to figure out what a given change did, so, clearly, they can't have that. I mean, you might even be able to easily go backwards from the worthless commit message to an email sent to gcc-patches (which usually *does* include an explanation), and thus divine why the change was made. That would be so clearly a bad idea, I'm not sure why anyone's even thinking about it!

Two GCC stories

Posted Jul 5, 2010 15:23 UTC (Mon) by nye (subscriber, #51576) [Link]

The best/worst part of that is the confusingly incoherent explanations for why some people apparently still think that's a good idea.

It seems to boil down to the following: some people don't want to use a revision control system, so they want the log that it could automatically generate to be manually created by a human. The idea of branching and merging is alien so that fact that this necessitates manual changelog merges is irrelevant. They don't want the actual VCS commit log to have any extra information than could be automatically generated because then the log that they don't want or plan to look at would be different to the manually generated log, which might confuse somebody.

Two GCC stories

Posted Jul 6, 2010 19:29 UTC (Tue) by mlopezibanez (guest, #66088) [Link]

http://gcc.gnu.org/wiki/GCC_Patch_Tracking

Bugzilla is useless to track patches: 1) Submitters would need to manually add patches to bugzilla, this won't accepted by most GCC developers, who submit patches via email, or by infrequent contributors, who do not want to create a bugzilla account 2) Reviewers will not check bugzilla for patches to review, in fact, patches in bugzilla but not sent to gcc-patches are often ignored forever 3) There is not easy/simple way to list unreviewed patches 4) Bugzilla cannot track approved/rejected status by email. Perhaps one could make bugzilla overcome the above limitations, but nobody has done it, so proposals of what GCC devs could do without offering to do it are a bit useless.

GCC developers may be willing to add a keyword to an email to say that a patch is accepted, rejected or committed, but they will not login to a website. Most GCC reviewers will not even look at the website. So reviewboard (and all patch trackers I know about) is out.

The patch tracker developed by Daniel Berlin was the closest thing to this, and even in that case was fairly underused because it was only useful for listing unreviewed patches by non-persistent contributors, and most reviewers won't look to a website for patches to review. They already have a lot of patches to review, so patches from people that don't have enough interest to follow-up their own submissions are not a critical concern.

I think the GCC project could benefit enormously from a patch tracker that could be operated from mail, IRC and web, that allowed grouping patches by maintenance area and status, that kept a history of past patches, that build and tested patches automatically and reported failures to the original submitter, that could generate automatic pings for unreviewed patches (every 15 days or more), that tracked email conversations about a patch (patchwork does this already), that enabled to submit patches via web, that checked the existence of categories markers, correct Changelog, correct GNU style formatting, ...

Of course, this is a dream that no one has made true so far.

Right now, the only solution is to encourage submitters to ping patches from time to time, and ensure that their approved patches have also been committed.

Two GCC stories

Posted Jul 8, 2010 13:00 UTC (Thu) by ariveira (guest, #57833) [Link] (1 responses)

Or https://patchwork.kernel.org/ used by some linux mantainers.

Two GCC stories

Posted Jul 13, 2010 1:58 UTC (Tue) by mlopezibanez (guest, #66088) [Link]

There is

http://patchwork.ozlabs.org/project/gcc/list/

but it is still useless because of the reasons mentioned above, specially, it requires login to work with the patch tracker and it cannot track approved/committed patches (automatically or by email keywords). So no one is using it as far as I know. It will probably grow up indefinitely until the owner of the site decides to just take it down.