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

[Joe Buck <Joe dot Buck at synopsys dot com>]

> 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.  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.  With the Stanford
work, this is *not* possible.

The Stanford work is very interesting, but they have not released their
work at all, keeping it entirely in-house.  Since they haven't distributed
it appears that they completely own the work and are under no obligation
to GPL it until they do.  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.  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.

There are two versions of the Stanford work; in the first version, the
user must explicitly write the rules to be checked.  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.

> 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.
The *implementation* of the checker would need to be released
under a GPL-compatible license if linked into the same executable
as the compiler.

> 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.