bad idea [LWN.net]

Not Enough

Posted Oct 18, 2006 4:43 UTC (Wed) by beoba (guest, #16942) [Link]

The only response I could think of:

D R A M A

Not Enough

Posted Oct 18, 2006 6:23 UTC (Wed) by bronson (subscriber, #4806) [Link]

"Torvalds even refused to use the existing LGPL for one project because it can be converted to the GPL."

What project? Linus likes the GPLv2: http://lkml.org/lkml/2006/9/24/246

sparse

Posted Oct 18, 2006 7:20 UTC (Wed) by xoddam (subscriber, #2322) [Link]

What project?

The sparse C parser & checker. The FAQ begins:

Q.  Why not just use gcc?

A.  Gcc is big, complex, and the gcc maintainers are not interested in
    other uses of the gcc front-end.  In fact, gcc has explicitly
    resisted splitting up the front and back ends and having some common
    intermediate language because or religious license issues - you can
    have multiple front ends and back ends, but they all have to be part
    of gcc and licensed under the GPL. 

    This all (in my opinion) makes gcc development harder than it should
    be, and makes the end result very ungainly.  With "sparse", the
    front-end is very explicitly separated into its own independent
    project, and is totally independent from the users.  I don't want to
    know what you do in the back-end, because I don't think I _should_
    know or care. 


Q.  Why not GPL?

A.  See the previous question: I personally think that the front end
    must be a totally separate project from the back end: any other
    approach just leads to insanity.  However, at the same time clearly
    we cannot write intermediate files etc crud...

There isn't a web page for this software and no-one packages it AFAICT, which is pretty unusual. It's developed more-or-less in sync with the kernel and the 'sparse annotations' of the kernel source. You have to fetch the git repository before you can read the FAQ...

rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/sparse.git/

(or a tarball from here)

sparse

Posted Oct 18, 2006 10:21 UTC (Wed) by nix (subscriber, #2304) [Link]

'Religious', hmm. As in 'if we'd not had this attitude we'd have many fewer front-ends and back-ends than we do now'. That seems more, I don't know, *pragmatic* to me.

"Religious"

Posted Oct 18, 2006 19:50 UTC (Wed) by GreyWizard (guest, #1026) [Link]

When Torvalds says "religious" he appears to mean "having a strong opinion which I don't share." Requiring that users be allowed to modify and reinstall software? Religious. Lengthy paeons in praise of tit-for-tat? Pragmatic! Don't spoil the fun with inconvenient logic.

sparse

Posted Oct 20, 2006 6:24 UTC (Fri) by viro (subscriber, #7872) [Link]

That's an interesting argument, seeing that gcc-based thing in that
area (stronger typechecking, etc.) is simply proprietary. I'm not
saying that Stanford Checker is a bad thing. But it's closed by any
definition. I've worked on sparse. A lot. Rewrite of preprocessor
more or less from scratch, lots and lots in type inferrence stuff
(starting with FP handling, non-lvalue composites, bitwise extensions,
etc.), many parts in phase 2 and phase 3, etc. There had been early
architecture decisions I'm unhappy with, but compared to gcc it's a
pleasure to hack on. In a very large part because nobody has been
playing games along the lines of "what if this change makes it easier
to abuse the thing into a separate frontend for their backend?"

Unlike gcc, implementing new class of checks is not a monumental
project. Including massive modifications of type system, etc.
Being free to tweak any code in a frontend working with gcc backends
might be nice in theory, but having it orders of magnitude harder
to tweak than it would have to be somewhat detracts from that freedom.
Stanford Checker *is* a monumental project. A modified gcc frontend.
Guess what? We _can't_ tweak on it. At all. At most we can try
to convince the nice guys from that group to add something new (and
run it over our code). And no, I'm not being sarcastic - they are
generally nice and reasonable. In compliance with the license, too.

Pragmatic/Religious

Posted Oct 23, 2006 18:46 UTC (Mon) by GreyWizard (guest, #1026) [Link]

I don't doubt the technical merits of sparse and you make a good case for separating licensing goals from technical decisions, but this seems to miss the point. GPL restrictions on derivative works are imposed for pragmatic reasons and have had positive consequences. Refusing to make it easy to separate the front and back ends of GCC may be a mistake but "religion" has nothing to do with it. Brandishing pejorative terms as Torvalds does is not productive.

Pragmatic/Religious

Posted Oct 24, 2006 0:03 UTC (Tue) by viro (subscriber, #7872) [Link]

Both license choice and technical decisions were driven by the same
pre-set political decision. And I wouldn't call it pragmatic - even
if you agree that blocking creation of (independent) proprietary
backends had been worth the trouble, you still have 100% genuine
proprietary derivatives of gcc that might very well not be such
if they would not be artificially made work-intensive. Well done,
RMS... The same thing had served as additional barrier to alternative
free compilers and _that_ contributed to gcc stagnation in late
90s (basically, until egcs fork). That same thing had actually
_reduced_ the number of viable frontends; granted, m3 folks had
their own kind of fucked-in-headness that added problems, but...
Basically, we have all usual results of PHB with a vision forcing
political, er, considerations on a project and not bothering to
think of consequences. BTW, "religion" is not the word I would
use, but then I'm not as polite as Linus. My preference for
description would be "SNAFU by a high-level suit with agenda".

Pragmatic/Religious

Posted Oct 25, 2006 23:01 UTC (Wed) by nix (subscriber, #2304) [Link]

Again, the decision had positive consequences: but maybe you don't care
about the existence of the Objective C and (IIRC) C++ frontends. Some of
us do.

Pragmatic/Religious

Posted Oct 25, 2006 23:36 UTC (Wed) by viro (subscriber, #7872) [Link]

ObjC is definitely in the same realm as m3 (if even that - cvsup is
seriously used and non-trivial, whatever.app tends to be... Applish,
for the lack of printable description). As for the C++... I would
be very surprised if that one hadn't used enough code from C frontend
at any point in its evolution to be a clear derivative, but ICBW.

Note that "your library is a derivative of my library, you get to
play nice wrt license" is entirely different kind of story. But
in that respect GPL is not something special - e.g. LGPL would
have the same effect.

If anything, I would expect any losses to be in weird backends for
embedded CPUs from hell, but considering the usual quality (and
bitrot rate) of those I'm not sure that I'd call it a loss... BTW,
ought to recheck if patches from FRV tree had finally got merged
into -HEAD; the last I've heard was "4.3 might be able to recognize
FRV-specific constraints in the kernel; it's too late for 4.2"...

sparse

Posted Oct 25, 2006 23:00 UTC (Wed) by nix (subscriber, #2304) [Link]

The Stanford Checker is, as I understand it, no longer based on GCC.

And, yes, it *is* easier to hack on a project that contains a frontend for
the parsing part of (most of) one language than it is to hack on a
frontend for a multi-platform optimizing compiler. Of course it is. sparse
doesn't even *have* a middle end to speak of, let alone a back end, so
naturally the constraints are less extreme. (Also, it has many years' less
accumulated cruft.)

But there aren't any `games' being played in the GCC source to make it
harder to separate the front and back ends: on the contrary, the
separation is finally becoming vaguely complete, and the pushback against
RMS's stand against explicit .so-based frontend/backend separation has not
stopped for a long time (and won a recent victory, no less: RMS is
shifting on this). Even then, the age of the ports is a problem: there are
many backends for which nobody is quite sure why particular architectural
decisions were done anymore, nor whether they'd break if changed.

(The largest remaining barrier is all the implicit assumptions inside
reload about how the incoming RTL will be shaped, and the implicit
assumptions in all the ports about how to generate that RTL. It's unclear
which of those assumptions are critical, and which are accidents of
history.)

(Joe, feel free to correct me if I'm talking rubbish: I'm merely an
interested observer of the GCC development scene, really. I mean I've got
plenty of local patches to the tree but I've never dared submit them
because they're awful.)

sparse

Posted Oct 26, 2006 0:08 UTC (Thu) by viro (subscriber, #7872) [Link]

OK, now you've got me curious; I was refering to aforementioned
"RMS's stand", but my impression was that it had been blocking
cleanup efforts (== lead to increased and harder to fix mess)
and that its rationale had been at least related to such scenarios
of abuse...

As for sparse... There is a kinda-sorta-not-really attempt at
backend, but no, I wouldn't expect it to really work unless somebody
puts serious effort into resurrecting it. Jeff Garzik is making
threatening noises of that sort once in a while, but that's about
it. There is linearizer and it does get more attention than
backend, but I hadn't looked at it lately.

Of course the lack of ancient cruft helps; no arguments here.
However, it had been my impression that RMS did at least slow
the cleanup, so IMO the point still stands. And if the Stanford
has moved away from gcc, well... then we have nothing gcc-derived
(and used) in that area at all...