This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Converting the gcc backend to a library?
- To: owinebar at free-expression dot org
- Subject: Re: Converting the gcc backend to a library?
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Mon, 10 Jan 00 06:26:39 EST
- Cc: gcc at gcc dot gnu dot org, rms at gnu dot org
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.
Free Software is becoming very big business these days and companies such as
VA Linux are getting market capitalizations into the billions of dollars
based on their usage of free software. Suppose one could claim that such a
company was able to obtain such a valuation because they violated the GPL in
some way. That could result in a multi *billion* dollar judgement against
that company and in favor of the FSF. We're talking *real money* here!
Suppose some company wanted to do as you say: write a set of changes to GCC
to split it into pieces that read and wrote an IR, put a proprietary back or
front end into a separate executable and claimed the resulting application
did not violate the GPL.
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.
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.
Instead, they'd ask the copyright holder, in this case the FSF, for a formal
statement that what they are proposing to do will not violate the copyright.
However they will find that the FSF will simply not comment. Basically the
stance will be "we're not going to give you permission to do that. If you
believe it doesn't violate the GPL and, once you've done it, we do, we'll see
you in court".
Consider a company doing an IPO based on such a product. The "risk factor"
in the prospectus would have to say something like:
"A key part of the technology for the company's product is copyrighted by a
non-profit foundation under a license whose main purpose is to prevent the
inclusion of such technology in a proprietary product. However, the
company's technical staff believe they have a method which will work around
that aspect of the license. We have obtained legal opinions that such
methods will indeed result in a non-infringing product, but the foundation
has declined to comment on whether it agrees that such would be noninfringing
and reserves the right to file suit if it believes infringement has occurred.
Although the license agreement, which was designed by the foundation, has
never been litigated, the company believes that were such litigation to
occur, the company's interpretation of the agreement, rather than that of the
foundation's, would be upheld by the court. However, there is no assurance
that the court would rule in our favor."
I trust you see the point.
Note that I do not expect RMS or any other official FSF person to make any
comment whatsoever on this issue. There would be absolutely no advantage,
and some significant disadvantages, to making any such comments.
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?
(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.
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'd just as soon know that the FSF and steering committee still prosecute
anyone making non-GPL'ed derivative works
The Steering Committee is not a legal entity and neither it nor any of its
members have any copyright interest in GCC. As I said, the FSF would be
ill-advised to make any comments whatsoever about what conditions would cause
it to take action against a perceived infringer other than to say, in general
terms, that it intends to enforce its copyright when it feels necessary.