petty squabling

Posted Jul 1, 2010 1:57 UTC (Thu) by tlw (guest, #31237)
Parent article: Two GCC stories

"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.

:-)

to post comments

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.