Re: Meta-Level Compilation project / Introspector/ AST access / Licensing question

[James Michael DuPont <mdupont777 at yahoo dot com>]

Joe, 

It seems that we have some misunderstandings of my
project and intentions here. 

I am not trying to open up the gcc to usage by
non-free tools at all, I am trying to protect it and
point out the contradictions here.

That is a problem with the GPL and copyright, not with
my tool at all. I have the best intentions for the GCC
and have proved it repeatedly. 

I have done research into all the different parties
and issues involved, I have told the FSF of possible
and real violations of the GPL. I have researched into
the issues and looked at what the universities are
doing.

I am not part of the problem here, I am part of the 
solution!

There is nothing legally stopping anyone from creating
a non-free back and front end on the gcc, if you dont
use linkage, but file format.

There is really no difference between my tool and
other tools that you think are not a problem. They all
exposed and use the same hole in the GPL. Any dump of
the ASTS can be used for code generation, and linkage
of scripting language, and any dynamic linkage of the
gcc as a Shared Object. That is copyright law, that is
the GPL. That is not my problem, but a general
problem.

The difference is that I am open about it, and I am
trying to protect the GCC from being abused, not to
abuse it.

See my comments below,
mike
--- Joe Buck <Joe.Buck@synopsys.com> wrote:
> 
> > At the risk of beating a dead horse,
> > Once again I have some more licensing questions.
> 
> There really isn't expertise on the gcc list for
> tricky licensing
> questions.  I suggest that you write to the FSF
> directly if you want such
> answers.  

I have been in contact many times with stallman about
this issue. I would like to create a new set of tools
that need to have access to the parse tree of the gcc.

Visualisation tools, Smart Editors that know the full
semantics of the edited program, Huge Database of
program meta data. 

All of these are not possible without using the GCC or
reimplementing the functions. 

It is not possible to protect the AST do under the
current GPL, that is why such a big discussion takes
place. 

I have removed my GCC patches as well as possible from
the sourceforge and have promised stallman that I will
not do anything to jepordise the GCC.

There is nothing legal stopping me from contining on
my project, only my shared concern for protecting the
GCC.

We need to work together on this one, not against each
other, also we need to have a firm set of rule, not
favortism.

I have also had a couple of big dicussions on
NNTP/GNU.MISC.DISCUSS under the 'A Modest Proposal for
a
GNU infrastructure license' title if you are
interested.

>Nevertheless I'll reply to a couple of
> points you make.
> 
> > Here is a project that I have found that is
> similar to
> > what I have been working on. The stanford
> "Meta-level
> > Compilation" project.
> 
> I disagree that there is any connection between that
> work and yours,
> other than that both of you are extending gcc.  With
> your work, it
> may be possible to write proprietary compiler
> passes.  
NO, with the tree-dumper, the tree-serializer and some
of the ast-optimizer it is possible!

The gcc team is doing the door opening, not me. I just
converted the tree-dumper to XML, a very simple patch.


You know that other people are using the tree dumper
in some form or the other for making non-free
software?

I am not part of the problem, I am part of the
solution,
as much as that may suprise you.

Even if I dont want to allow it. If you see my new
proposed RGPL license on GNU.MISC.DISCUSS for it, the
ability to create non-free extensions is completly 
>With the Stanford
> work, this is *not* possible.
That is a BIASED statment.

So checking and transforming the code is not a
compiler pass, what is it then? 
If you can read and transform the tree, 
and have access to the asts, then you are accessing
the  data that is normally available only to the GPLed
code.

You can then implement a compiler pass with any
language that is turing complete.

> 
> The Stanford work is very interesting, but they have
> not released their
> work at all, keeping it entirely in-house.  
They have just distributed the results, similar to
what I proposed to do with the GCC as a protected web
service.

>Since
> they haven't distributed
> it appears that they completely own the work and are
> under no obligation
> to GPL it until they do.  
Exactly, I am not questioning that at all.

>I have no idea what they
> have in mind; the fact
> that they haven't published the code may mean that
> they are applying for
> patents, looking for a business deal, trying to
> replace their use of GCC
> with some other compiler, or maybe neither of these.
> 
> However, should they decide to release under the GPL
> I see no reason not
> to accept their checking language as a contribution;
> it would strengthen
> the position and usefulness of GCC.  

So will my project.

>It has nothing
> to do with your
> concerns over additional interfaces to GCC allowing
> for ways around the
> GPL as far as I can tell.
It does.

> 
> There are two versions of the Stanford work; in the
> first version, the
> user must explicitly write the rules to be checked. 
That allows for inclusion of non-free passes inside
the compiler.

> In the second
> version, the tool attempts to deduce additional
> consistency checks
> based on statistics (for example, notice that in 99
> out of 100
> cases the result of some function that returns a
> pointer is checked
> to see if it is null, so flag the cases that are not
> checked as inconsistent).
> 
> > http://hands.stanford.edu/osdi2000/node3.html
> > "More generally, since the metal language has been
> > designed to be shielded from both the underlying
> > language and compiler" 
> 
> That's just good software engineering.

Well I have and XML file format and a postgress
database of the ASTS. That is also good software
engineering, what makes mine more dangerous that that?
What about the tree-serialization branch, there you
are dumping the asts into a form that has no copyright
at all. Anyone can use those files for creating
non-free backends. 

If I were to embed perl inside the compiler you can
also do all the checking you want. Would that be an
issue?

I think that this is more of a favoritism here than
anything else.

How come you support the usage of GraphVis for
example? That is not free software? 

The data that you give it is not much different than
what I get, and my software is GPLED!

> 
> > Does that mean the checking code does have to be
> > Gpled? Can a user via some interpreted language
> > embedded in the compiler avoid the GPL?
> 
> The Stanford checker approach is analogous to
> yacc/bison input.
> The checking code is written by the user and is the
> user's work,
> just like the bison code.  Effectively there are two
> languages,
> a skeleton language (e.g. yacc/bison or checker
> rules) and the
> programming language (C/C++).  There's no reason to
> expect that
> the checking code that the user writes would need to
> be GPLed.

Except that is has intimiate access to the memory of
the the compiler and via a scripting language you are
linking to the gcc. See the GPL FAQ for this, if you
link to a GPL program via a scripting language, you
are then GPLeing you program.

> The *implementation* of the checker would need to be
> released
> under a GPL-compatible license if linked into the
> same executable
> as the compiler.
That is not an question.

> 
> > If this is not a problem then there should be no
> > problem embedding GCC as a dynamic perl module!
> 
> The two things have nothing to do with each other.
That is not correct at all. 
The types of tools that you can write with the MLC are
the same as the introspector, just a different
transport layer.

Please think this over again.

Best Regards,
Mike


=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com