[GCC-XML]support for definitions as well as declarations?

[Dale E Martin]

> I have been working on the function bodies of C in the introspector,
> the problem is that there are legal and moral issues attached to it. 
 
> One of the problems with the gpl is that it is based on copyright, and
> therefore exerts no control over how a program is used. Therefore the fsf
> is worried that such an interface could be used to write non-free
> backends on the gcc.

My opinion is that there is no moral issue.  (I'm a Debian developer, FWIW,
so I do understand the GPL, the philosophy behind it, etc.)  Richard has to
live by his own rules.  There is no license violation in developing the
tool, and the while such a tool could be used to develop non-free backends
to gcc, it would probably (in my opinion) be used by more free software
projects than non-free.  

In fact, anyone could pick up gcc and develop such a tool and release it
and other than hearing him get upset about it, I really don't think he's
got any legal ground to stand on.  The lack of a good free AST dumping tool
is actually kind of surprising to me, and I had heard that this was an
issue.   Interesting to hear of direct experience about it.

> Last month I met with Stallman about this issue, I understand his
> concerns and am trying to figure out the best way to proceed on this
> issue.

> I have promised that I will remove that ability from my program, at least
> for the XML side of it. On the other side, the ast-serializer and
> ast-optimizer branch of the gcc are doing similar things. If you want to
> help try and resolve some of the legal issues involved, I will be willing
> to donate my function body dumping into gcc_xml and merge the two
> projects.

Well, I'm pretty sure I'm going to have to develop some C++ front-end that
can dump XML for a client of mine.  They own a source license to the EDG
front-end, so I could do it with that but I'd rather be able to develop one
that is free software (and the client is OK withthat.)

Then we would need to develop a backend as well.  I think I'd have more of
a chance of GPLing the backend with a GPL front-end than with EDG.  But
this I will need to discuss with them.  (They're a governmental agency so
there is a decent chance they WOULD gpl the backend too.)

> But note that Stallman has said that he does not have a problem with
> gccxml because of the fact that it does not dump bodies.

> On the other side, there is the cppx[1] project that does support the
> full dumping of all the compiler data, but they also dont really have any
> free tools for using this data, and support non-free backends. That is
> why I dont use it.

They've got no release yet though, right?  They can't prevent you from
developing GPL tools against their front-end, can they?  Of course, having
a "standard" XML definition that comes out of a free tool is very
compelling.
  
> I dont know how tenable it will be not to dump the full function body
> information, because of the fact that any application (such as syntax
> highlighting) depends on a full function definition. The idea from
> stallman is to somehow force the developer to create the module as part
> of the gcc, and therefore you would bound by the copyright/copyleft law
> to re-releasing the program under the GPL.
 
Interesting idea, but I don't see how it would work exactly.

> I am not sure how to continue on this path, except to introduce an EULA
> that stipulates that the software is only usable by free software, and
> that it will not be used to create non-free backends. Would you agree to
> such an license? Do you think it makes sense at all.

I'd have to think about it.  Such a program would be classified as
"non-free" by the Debian DFSG....  You're not allowed (in Debian's view) to
limit how a program can be used.  In general it's for "not for commercial
use" type licenses that they are trying to address with that guideline,
but this falls right into that category too.  How ironic :-)
 
> On the other side there are very interesting programs being written as
> part of the gcc itself, the deparse/ast-optimizer has a tree to c
> generator, you might want to consider writing your module in c or
> directly linked to the compiler as one module.  I would consider
> expanding my perl interface to link directly to the gcc, and have a GCC
> dll/so that has the entire thing as a perl module.  This would allow a
> direct and static linkage of the gcc to perl and avoid any XML.
 
But I'd like to develop my backend in Java using antlr (and/or XTAL), so
XML is what I would like to get out!  :-)

> Of course that would again need an EULA to prevent someone from using
> it for creating a non-free backend as well. As I said, if anyone is
> interesting in persusing this angle, I would be willing to contribute
> that part. In fact it could be added to gcc-xml, as a module........
> 
> This might come back down to a problem again, and I have to say that 
> right now the best possibility to get the function bodies is from
> opencxx [2].

I saw a reference to this on your mailing list, we're checking that out as
well.  Have they written their own C++ front-end?  That was unclear to me
from their docs.

> On the other side, if you are willing to sign a form of a non-disclosure
> aggreement, we can arrange a private distribution via gpg/pgp encrypted
> code, but you will have to aggree not be allowed to redistribute the code
> to third parties.
 
That is possible too, although I think you would be violating the GPL in
doing so :-)

It's kind of a crazy issue, actually!  ;-)

> I hope that you found this informative, and I am looking forward to
> hearing from you.

Very much so, thanks for the info!

Later,
	Dale
-- 
Dale E. Martin, Clifton Labs, Inc.
Senior Computer Engineer
dmartin at cliftonlabs.com
http://www.cliftonlabs.com
pgp key available