This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Converting the gcc backend to a library?


On Mon, 10 Jan 2000, Richard Kenner wrote:

>     Actually, it sounds like RMS has forbidden these changes precisely
>     because of the legalities.  
> 
> No, it's because, as Jeff says, those changes would make it *easier* to
> undermine the intent of the GPL, not because of "legalities".
> 
>     (1) if simply changing the form of the interface to include
>     intermediate text files makes it possible to add proprietary
>     optimizers/back ends/front ends/whatever, 
> 
> Nobody has said	it would, and that's precisely the point.
> 
    Then I've lost the point somewhere, as this was the example Jeff gave
for it.  And it's not clear to me how the spirit of the GPL is going to be
undermined except by legalities (in any case).

> Their *claim* that it doesn't violate the GPL is worthless.  If the FSF chose
> to sue, it would ultimately be for a court to decide whether or not it
> infringed.  Software copyright law is a very esoteric subject nowadays and
> court ruling have often been at significant odds with what we technical
> people might think the law is.
     
    Like I said, it's not based on some hard and fast rule, and the status
of being a "derived work" does not have to depend on the eventuality of
blatant copyright infringement  (the comments I've seen RMS make regarding
shared libraries uses this notion - that it's a technical circumvention of
directly including the binary of the GPL'ed part into a static
executable).  Copyright is concerned precisely with the expressive nature
of the software, not it functional aspects and related technical details.

> Given these uncertainties, would a company really take that risk?  Doing this
> would only make sense in the first place if the value of the proprietary
> piece were significant compared to GCC, which means we're into the hundreds
> of millions of dollars.  Nobody is going to risk that sort of money on the
> way a court might rule.
> 
   Like I said, only in marginal cases.  Which is why I'm having a hard
time seeing why they're too concerned with it.

>     If nothing else, modifying the official distribution in this way does not
>     mean the FSF or GCC steering committee thinks making proprietary add-ons is
>     legal (that is, non-derived). 
> 
> Not completely.  Since the main purpose for such a change would be precisely
> to make such a split of proprietary code, one could argue that by accepting
> such a change, the FSF had implicitly agreed to permit such.  I don't think
> such an argument would prevail, but why allow it to be made?
> 
   The main purpose of such would be to allow simple text file interfacing
with the internals of GCC.  For example, I'm working on a decompiler
written in Scheme that uses a slightly modified RTL for an internal
representation.  The decompiler is available under GPL.  It would be nice
to be able to just dump the RTL (with appropriate modifications) and have
GCC be able to read it from there.    In particular, it would help
testing.   One could use such a feature for prototyping optimizer passes
as well.
   The proprietary nature of things doing the text interfacing is a
secondary matter.  

>     (2) It makes it harder for legitimate free software developers to
>     include gcc as a library, for example, a compiler integrated into
>     GUILE so code could be compiled on the fly.
> 
> Reading and writing IR is *slow* and memory is cheap: linking directly with
> GCC components or calling the entire compiler would almost certainly be the
> better technical solution.
> 
    My fault for confusing the two subjects as Per Bothner noted.  I don't
think they're that far apart legally, but it's true that at least some
(probably most or all) of the relevant steering committee people do.

>     Eventually, I'll need GCC as a library for a project I'm working on, and if
>     it's not in the official sources, I'll have little compunction against
>     forking my own library version because it would still be far easier to
>     maintain that than developing my own multiplatform optimizing compiler, and
>     the project is under GPL anyhow.  
> 
> If you feel you have no choice that to do that, you'll have to do it, but you
> should be aware that such a fork is not in the best interests of the free
> software community has a whole.  As a pragmatic matter, you will find you
> will have to understake significant effort to track changes to GCC as their
> affect the IR yuou will be writing and reading.
> 
   I agree it's not in the best interest of the FS committee as a whole.
That's why I think the GCC steering committee think hard before ruling out
such a modification (making it a shared library, not providing the textual
IR access).  But given the choice between writing a multi-platform
optimizing compiler and making the community unhappy (in particular the
FSF); well, the latter seems like the most reasonable course of action
from any pragmatic viewpoint I hold.  Partly because I don't think I'd be
the only one interested in having GCC as a library.  Not that it's
an idea I relish, I'm just emphasizing the utility having gcc as a library
would provide.  In fact, I'm sure forking would be a complete PITA.

Lynn



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]