Would it be possible to give the FSF the copyright of m3.c (the m3cc backend)?
Marc Fiuczynski
with egcs' new table based exception handling support for my dissertation.
No easy task, I tell you.
As I've run into trouble I've been sending email to gcc at gcc dot gnu dot
org to get feedback/help. One person asked why the m3 frontend wasn't in
the gcc cvs tree. I assume this is a licensing issue, right? Could someone
comment on what it would take to sign the copyright ownership of m3.c over
to the FSF? There is the obvious benefit that m3.c should always be in the
gcc cvs tree, and simply part of each gcc distribution. Who would one have
to contact about this? Presumably the people at DEC/Compaq should know?
Cheers,
Marc
Tim Mann
because Richard Stallman does not want them. The whole purpose of m3.c
is to allow gcc to act as a backend for a frontend that is a separate
program, communicating over a pipe. Because the frontend and backend
are separate programs with this arrangement, the frontend does not have
to be under the GPL. This provides an escape hatch from the GPL's so-called
"viral" nature (all additions or modifications to a GPL'ed program must
also be GPL'ed) and thus conflicts with Stallman's goals. Modula-3 does
use this escape hatch; the compiler frontend is under the SRC Modula-3
license, a quite liberal license that fits the Open Source definition
but is not compatible with the GPL.
Thus, although we could probably have gotten management permission to
transfer m3.c's ownership to the FSF, the FSF would then have refused
to distribute it, so that would not have been too useful. Instead we
put m3.c under the GPL (which is necessary because it's linked into the
same address space as part of gcc), but left the ownership with Compaq.
(By the way, this actually wouldn't prevent the FSF from distributing
the code *if they wanted it*; the last time I looked, there were several
files in the gcc distribution that were under the GPL but copyrighted
to some entity other than the FSF.)
An alternative approach might have been to try to get the whole Modula-3
compiler, or maybe the whole SRC Modula-3 distribution, donated to the
FSF. They could then put the whole thing under the GPL and presumably
be happy. I still don't know if that would have caused Modula-3 support
to become part of the gcc distribution, however, and it would have been
a much harder thing to persuade people here to go for, so we didn't pursue
it.
Tim Mann <ma...@pa.dec.com> Compaq Systems Research Center
http://www.research.compaq.com/SRC/personal/Tim_Mann/
Dragisa Duric
: I've been hacking away at getting M3's exception handling support to work
: with egcs' new table based exception handling support for my dissertation.
: No easy task, I tell you.
: As I've run into trouble I've been sending email to gcc at gcc dot gnu dot
: org to get feedback/help. One person asked why the m3 frontend wasn't in
: the gcc cvs tree. I assume this is a licensing issue, right?
Partly. Licensing issue is automatically resolved once you release some
patched gcc - which is GPLed. That patch is also GPL because of GPL terms.
Problem goes deeper, IMHO. RMS was fighting Bill Kalsow and SRC to GPL
SRCM3. Bill Kalsow won that and I think there is implicit no-no in FSF
policies for Modula-3 recognition and integration of m3gcc patches to main
trees. In my language we would say something that translates to: One who
laughs last, laughs sweetest.
: Could someone
: comment on what it would take to sign the copyright ownership of m3.c over
: to the FSF? There is the obvious benefit that m3.c should always be in the
: gcc cvs tree, and simply part of each gcc distribution. Who would one have
: to contact about this? Presumably the people at DEC/Compaq should know?
I've contacted some people in charge for M3 at SRC, without answer. It was
after one of egcs developers asked me this obvious thing.
: Cheers,
: Marc
dd