Linkage of GPLed GCC to Closed Source via XML or Perl

Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

Dear GCC Developers,

For the past three years, I have been working on a
project to create a object oriented interface to the
GCC compiler, the GCC Node Introspector
(http://introspector.sourceforge.net/). 

This turned from a c++ into a Perl project after
realising the power of Perl for handling strings and
complex data structures. 
Currently I am using a modified version of c-dump.c
like done in CPPX
(http://swag.uwaterloo.ca/~cppx/doc/cppx/arch.html). I
output the tree nodes into a XML form that is very
similar to the tree dump, just with xml syntax.  This
is streamed into a Perl program via popen and written
to a Postgres database.

Also the number of tools that link into perl are
amazing.
The linkage of Perl is permissive, but I think that
the linking of programs can to GPL code can be very
tricky, and full of problems as a detailed review of
the GPL and LGPL can point out.

In this article :
http://lwn.net/2001/features/LarryWall/Perl 
>> CL: Would you give us an example of cultural
problems? 
>>Larry Wall: Ten years ago or so, we had Richard
Stallman's GPL, and Perl was licensed under that. And
I discovered 
>> that that worked fine for the hacker community, for
the geeks, but it prevented Perl from being used in a 
>> commercial environment. So I wrote my own license.
But I didn't want to offend the free software, the GPL

>> people. 
>>So, rather than switching licenses, I said "Well,
let's have both licenses and you may distribute Perl
under >>either of them at the same time." And that
way, the computer crowd, they had their insurance that
their rights >>would not be taken away, and the
companies had some insurances that their rights would
not be taken away, and >>everyone was happy. That's
sort of cultural hack that I'm talking about. 

Does that mean that via perl a company can create a
close-source gcc backend?
Without external representation via XML?

Let us review the the GPL and its implications for
linking to Perl : 

Lets look at the GPL : 
>This General Public License does not permit
incorporating your program into proprietary programs. 
>If your program is a subroutine library, you may
consider it more useful to permit linking proprietary
>applications with the library. 
>If this is what you want to do, use the GNU Library
General Public License instead of this License.

My GPL Comment: 
incorporating is a term that implies to me
containment,
If I write a proprietary program that uses the output
of the GPL Code is that containment?

If I open the a pipe to another program, and call
functions in it using data from a GPL program, is that
not what a linker does, but via a different method?

Lets look at the LGPL 2.1 
>	We use this license for certain libraries in order
to permit linking those libraries into non-free
programs. 
>	When a program is linked with a library, whether
statically or using a shared library, the combination
of the two is legally speaking a combined work, a
derivative of the original library. 
>The ordinary General Public License therefore permits
such linking only if the entire combination fits its
criteria of freedom. 
> The Lesser General Public License permits more lax
criteria for linking other code with the library.

LGPL Comment :
Now this does not cover linking via RPC/IPC or Shared
Memory or File. 
Let alone CORBA or XML-RPC/SOAP.
This comes done to the definition of linking, is
linking only with the linker, or is linking a method
of passing data between function calls? 
Can I call a GPLed Function in GIMP via a perl script
webpage, but I cannot link to it?


LGPL part 2 :
>14. If you wish to incorporate parts of the Library
into other free programs whose distribution conditions
are >incompatible with these, write to the author to
ask for permission. For software which is copyrighted
by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for
this. 
>Our decision will be guided by the two goals of
preserving the free status of all derivatives of our
free software and of promoting the sharing and reuse
of software generally. 


LGPL Comment part 2 :

"distribution conditions are incompatible with these" 
Does that cover PAL which gives you more freedom?
Can I link via Perl and all of a sudden, there is no
more GPL?

By these terms, would every Perl script which links in
with GPLed GIMP via script would require such
permission to be asked?

The perl script is called from an apache server, goes
across all types of close-source maybe even patented
software sitting on routers and switches, and then
gets displayed in a microsoft browser, only to call a
javascript function that uses the microsoft api to
draw on some graphic card.

As you can see, the network has changed the meaning of
linking. Perl has changed it as well.

Also see the discussion of this subject on perl monks 
http://www.perlmonks.org/index.pl?node_id=148162


James Michael DuPont 

mdupont777@yahoo.com
 


=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Joe Buck]

James Michael DuPont asks lots of questions indicating that he is
attempting to find a legal way around the GPL, so that he can attach
proprietary backends to GCC.

I would urge people not to give him any assistance, even if he is
only asking the questions out of intellectual curiousity.

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

It is very simple now. I am not trying to get around
the GPL, Joe, so you can see that your statement
should be retracted.

The output of the introspector is source code in xml
format. That is covered by the GPL. Later queried from
the database, it is also source code, just in a
different form.

FROM THE GNU FAQ : 
"In what cases is the output of a GPL program covered
by the GPL too?
Only when the program copies part of itself into the
output."

Well the xml output of the modifications to the GCC
contain  : 
1. the structure of the tree_node from the tree.h
2. the source code of the program that is compiled.

That is basically source code, just in a different
form. Therefore the introspector is not only a derived
work, but its output is also a form a source code that
is gpled.

Mike

=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Joe Buck]

James Michael DuPont writes:

> It is very simple now. I am not trying to get around
> the GPL, Joe, so you can see that your statement
> should be retracted.

Yes, the tone of my statement was completely inappropriate.  You are not a
bad guy, and I apologize for my original statement.  Furthermore this is
an extremely complex issue and I think that at some point the FSF is going
to have to modify the policy somehow.

> The output of the introspector is source code in xml
> format. That is covered by the GPL. Later queried from
> the database, it is also source code, just in a
> different form.

I'm not sure that that will fly.  I retract my accusations against you,
but I don't retract my statements that XML output will provide new ways
of attaching proprietary code to GCC (despite your claims that the GPL
can prevent this).  On the other hand, it appears that various compiler
vendors are talking about common XML formats to represent parsed C++
code.  If this comes about, any resistance on the part of GCC will be
useless.

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

Joe, 

> Yes, the tone of my statement was completely 
> inappropriate.  You are not a bad guy, and I 
> apologize for my original statement.

Thank you and I accept your apology. 
I understand your wanting to prevent abuse of the GCC
and respect you for that as well. 
\rWe just have to work together on this, it is not that
clear cut.

> Furthermore this is
> an extremely complex issue and I think that at
some
> point the FSF is going
> to have to modify the policy somehow.
That is why I am bringing this up before someone makes
an misinformed judgment, because no-one will talk to
them about the issue.
For example, take a look at a mail from the GCC_XML
mailling list :
http://public.kitware.com/pipermail/gccxml/2002-February/000033.html


> I'm not sure that that will fly.  I retract my
> accusations against you,
> but I don't retract my statements that XML 
> output will provide new ways
> of attaching proprietary code to GCC (despite 
> your claims that the GPL
> can prevent this).

First I will change the license text on all the
programs that deal with the introspector, even to perl
ones to strict gpl. \r\rI think some of the perl scripts
were artistic licence.

Secondly, I am going to officially limit the usage of
the introspector for improving the GCC compiler itself
(This can always be taken back when we get more
information about how to move forward).

Can be done via a simple statement like :
BEGIN LEGALEZE
The program is intended to be used internally by the
gcc project. It is not to compile any other source
code other than the GCC compiler and their GPLed code.
All output from it is under the gpl and cannot be used
in any other project without written permission?
END LEGALEZE
And now, I cannot afford a lawyer, I am not making any
money off of this.

Besides, Noone else is really using it as far as I
know, and the only project that I have compiled are
the c,c++ and java compilers. 

I have a postgres database of 2gb with all the asts
from the stage2 bootstrap on my computer and am
writing cool queries to figure out how the tree nodes
are used.

Please feel free to check out this one little example
that I wrote :
http://introspector.sourceforge.net/tree_code_name.html

> On the other hand, it appears
> that various compiler
> vendors are talking about common XML formats to
> represent parsed C++
> code.  If this comes about, any resistance on the
> part of GCC will be
> useless.
Really, can you please tell me where I can read about
this? That I have not encounter yet!
There is the DAGSTUHL Middle model project :

http://scgwiki.iam.unibe.ch:8080/Exchange/2

BEGIN QUOTE 
Model for program entity level information
This page contains information about models and
schemas for modelling source code at the program
entity (or design) level. The effort to come up with a
standard schema is currently dubbed the Dagstuhl
Middle Model (DMM).
Model for program entity level information
END QUOTE 

The cppx project from waterloo is another GCC
modification that outputs a binary dump of all the AST
information and then uses some interesting tree
walking to output into a DMM compatible format 

The cppx homepage is here : 
http://www.swag.uwaterloo.ca/~cppx/
Here is another page describing it :
http://swag.uwaterloo.ca/~dean/cppx/

Here is an interesting overview of the cppx project
:
http://www.csr.uvic.ca/chisel/collab/reports/cppx.html

BEGIN QUOTE
CPPX is a free, open source, general purpose parser
and fact extractor for 
C++. It relies on the preprocessing, parsing, and
semantic analysis of GNU g++, and produces a graph
according to the Datrix fact model, in 
either GXL, TA, or VCG format, suitable for use in
architecture recovery, data flow analysis, pointer
analysis, 
program slicing, query techniques, source code
visualization, object recovery, 
restructuring, refactoring, remodularization, and the
like. When invoked with a 
source file, CPPX first passes the file to g++, which
compiles it with a 
"compile-only" option. There are hooks within the GCC
archicture for extracting 
debugging information, and upon them we have hung code
to dump GCC's internal 
semantic graph to a (binary) format convenient for
CPPX's purposes. The schema 
(rules and regulations) of GCC's graph are suitable
for normal compilation (viz. 
for execution) but not for design recovery. So after
the dump, CPPX applies a 
collection of tiny "systolic" transformation steps to
make the graph conform to 
a schema more suitable for design analysis. The final
result graph is emitted in 
GXL (or TA, if you like). The target schema is that of
Bell Canada's Datrix 
project.
END QUOTE 


\r\rI hope you find this interesting.

mike

=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Bryce McKinlay]

James Michael DuPont wrote:

>Besides, Noone else is really using it as far as I
>know, and the only project that I have compiled are
>the c,c++ and java compilers. 
>
>I have a postgres database of 2gb with all the asts
>from the stage2 bootstrap on my computer and am
>writing cool queries to figure out how the tree nodes
>are used.
>

Technical question: does your patched compiler dump out any AST info 
that isn't already dumped by -fdump-trees/tree-dump.c? ie is there more 
info there, or is the intent just to generate XML output so that it is 
more parseable by other tools?

I always thought it would be a cool debugging tool to have some sort of 
gui for introspection of the AST. "p debug_tree(t)" in GDB does get 
boring after a while...

regards

Bryce.

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Diego Novillo]

On Mon, 04 Mar 2002, Bryce McKinlay wrote:

> James Michael DuPont wrote:
> 
> >Besides, Noone else is really using it as far as I
> >know, and the only project that I have compiled are
> >the c,c++ and java compilers. 
> >
> >I have a postgres database of 2gb with all the asts
> >from the stage2 bootstrap on my computer and am
> >writing cool queries to figure out how the tree nodes
> >are used.
> >
> 
> Technical question: does your patched compiler dump out any AST info 
> that isn't already dumped by -fdump-trees/tree-dump.c? ie is there more 
> info there, or is the intent just to generate XML output so that it is 
> more parseable by other tools?
> 
> I always thought it would be a cool debugging tool to have some sort of 
> gui for introspection of the AST. "p debug_tree(t)" in GDB does get 
> boring after a while...
> 
If you're looking for more interesting ways of examining the
ASTs, the ast-optimizer-branch is starting to show a few:

- Unparsing capabilities (could potentially be used as a
  source-to-source converter).

- Flowgraphs.

- Call graphs.

- Metrics (control flow complexity and logical complexity).


Diego.

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Alexandre Oliva]

On Mar  2, 2002, James Michael DuPont <mdupont777@yahoo.com> wrote:

> First I will change the license text on all the
> programs that deal with the introspector, even to perl
> ones to strict gpl. I think some of the perl scripts
> were artistic licence.

> Secondly, I am going to officially limit the usage of
> the introspector for improving the GCC compiler itself
> (This can always be taken back when we get more
> information about how to move forward).

> Can be done via a simple statement like :
> BEGIN LEGALEZE
> The program is intended to be used internally by the
> gcc project. It is not to compile any other source
> code other than the GCC compiler and their GPLed code.
> All output from it is under the gpl and cannot be used
> in any other project without written permission?
> END LEGALEZE
> And now, I cannot afford a lawyer, I am not making any
> money off of this.

IANAL, so don't take this as legal advice, but my understanding is
that the issue is not as simple as *claiming* that the output of your
tool is derived work in order to have rights over defining its
license.  Whether something is a derived work of something else or not
is covered by copyright law.  Even if you'd add some boilerplate
license code to any output your program emits, or even intertwine your
own code with it so as to make it more and more dependent on your
program, which would make it easier to show that it's work derived
from yours, if the user managed to extract all parts that were
copyrighted by you from your output, they might have a point in
claiming they can choose the license of the remainder of the output
however they like.

So make sure you get RMS to talk to FSF lawyers about this before you
do something that might harm the GNU project, if you can't afford a
lawyer yourself.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

> -fdump-trees/tree-dump.c? ie is there more 
> info there, or is the intent just to generate XML
> output so that it is 
> more parseable by other tools?


There is no extra info there yet. Just a small patch
to c-dump. The gasta project does not even patch, but
he parses the tree.

All the extra information is derived by queries after
I start putting the trees back togeather.
mike


=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

> If you're looking for more interesting ways of
> examining the
> ASTs, the ast-optimizer-branch is starting to show a
> few:
> 
> - Unparsing capabilities (could potentially be used
> as a
>   source-to-source converter).
> 
> - Flowgraphs.
> 
> - Call graphs.
> 
> - Metrics (control flow complexity and logical
> complexity).

That sounds really exciting!
I have to admit that I have not looked at that branch
yet. 
The next step would of course to start putting  the
flow and call graphs into a file so that you can
examine the program on a whole.

I will start looking into the ast optimiser this week.

mike

=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

Thanks for you ideas,
see below for my comments.
--- Alexandre Oliva <aoliva@redhat.com> wrote:
> On Mar  2, 2002, James Michael DuPont

> IANAL, so don't take this as legal advice, but my
> understanding is
> that the issue is not as simple as *claiming* that
> the output of your
> tool is derived work in order to have rights over
> defining its
> license. 
Yes, that is why this advise to get a lawer keeps on
coming up, my opinion is not that important later when
the issue comes up in court. 
I keep on bringing up my opinon to try and gain on a
consensus on what to do next.

> Whether something is a derived work of
> something else or not
> is covered by copyright law.  Even if you'd add some
> boilerplate
> license code to any output your program emits, or
> even intertwine your
> own code with it so as to make it more and more
> dependent on your
> program, which would make it easier to show that
> it's work derived
> from yours, if the user managed to extract all parts
> that were
> copyrighted by you from your output, they might have
> a point in
> claiming they can choose the license of the
> remainder of the output
> however they like.
This is what I brought up on gnu.discuss.misc.
The issue comes back down to deparsing the asts once
they are  in the external form, then the result of
that would only be the input code, andthe code to
deparse  might be a derived work.

> So make sure you get RMS to talk to FSF lawyers
> about this before you do something that might harm
the GNU project, if you can't afford a lawyer
yourself.

I aggree %100 and I have already started this process.
As I pointed out, there are other usages of the
compiler that might fall under this problemm. 
1.The dumping of graphs to graphvis (which is not GPL)
2.The parsing of the original c-dump output using
Gasta.
3.The usage of GCC_XML in CABLE to create function and
typewrapper code.

These other projects and functions of gcc might be
affected by such a desision and really IMHO will have
to be looked into by the FSF independently of my
issue.

Thanks for your advise, before I do any more licencing
I will be sure to submit the idea to FSF before
publishing it.

mike

=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Robert Dewar]

Yes, there definitely is a working ASIS for GNAT 5. I will check if the
sources have been updloaded as they should have been.

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Florian Weimer]

dewar@gnat.com (Robert Dewar) writes:

> In the case of Ada, this is taken care of in an implementation
> independent manner by the ASIS (Ada Semantic Interface
> Specification) standard, which specifies a portable interface to the
> semantic information for an Ada program.

Is there already a (mostly working) ASIS implementation for GNAT 5, by
the way?

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Diego Novillo]

On Sun, 03 Mar 2002, James Michael DuPont wrote:

> and sage++
> (http://www.extreme.indiana.edu/sage/overview.html)
> projects both have such deparsers tools.
>
Sage++ seems to have been abandonded, but SUIF
(http://suif.stanford.edu/) is very much alive.  In fact, you'll
find that several research compiler projects rely on
source-to-source transformation, so they typically implement some
kind of unparsing pass.

Diego.

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

--- Robert Dewar <dewar@gnat.com> wrote:
> <<The only thing is, for the end user of a
> introspection
> system you will need to present them an interface
> into
> the AST.
> >>
> 
> In the case of Ada, this is taken care of in an
> implementation independent
> manner by the ASIS (Ada Semantic Interface
> Specification) standard, which
> specifies a portable interface to the semantic
> information for an Ada program.
> Too bad there is nothing comparable for C or C++.

The ASIS is what i was looking at months ago,
the sage++ and openc++ presents something very
compariable. 

The modelling of the tree node data structures is one
of the real good things that came out of the work on
the introspector so far (in perl): 
from an abstract description of the nodes that I get
from the first pass dump of the trees, and annotate
using introspective methods and meta programmings, I
generate perl,java,and sql structures to hold the tree
nodes. 
Maybe it is time to start looking at creating a user
level c interface to the tree nodes.

mike


=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Robert Dewar]

<<The only thing is, for the end user of a introspection
system you will need to present them an interface into
the AST.
>>

In the case of Ada, this is taken care of in an implementation independent
manner by the ASIS (Ada Semantic Interface Specification) standard, which
specifies a portable interface to the semantic information for an Ada program.
Too bad there is nothing comparable for C or C++.

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

--- Robert Dewar <dewar@gnat.com> wrote:
> Unparsing capabilities are enormously useful, >both
or debugging the compiler and for the >programmer
understanding enerated code ).

Here are some more supporting facts:
The cbreeze
(http://www.cs.utexas.edu/users/lin/cbz/)
and sage++
(http://www.extreme.indiana.edu/sage/overview.html)
projects both have such deparsers tools.
Sage has a class model for the ast that allows  you to
contruct optimised code for parallel computing.The
OpenC++ also allows for construction of code on the
ast level and then uparsing it.

The Sage compiler supports restructuring and
de-parsing. This sounds like the AST optimiser.


This will eliminate the need to extract the code out
into XML/DB before using it.

With that unparsing tool, most of the meta-programming
and introspection code that I am interested in can be
handled.

The only thing is, for the end user of a introspection
system you will need to present them an interface into
the AST.
Would be interesting to look into a set of functions
that allow for user-specified ast transformations
during the compiler phase?

Unparsing the data, or dumping the data in code that
will create the data is a great feature of perl. Java
has tools to allows even serialization in XML using
introspection.

mike


=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Diego Novillo]

On Sun, 03 Mar 2002, Robert Dewar wrote:

> <- Unparsing capabilities (could potentially be used as a
>   source-to-source converter).
> >>
> 
> Unparsing capabilities are enormously useful, both for debugging the
> compiler and for the programmer understanding generated code (cf the
> -gnatG switch in GNAT, we also provide a -gnatD switch that allows
> debugging at the level of the unparsed source code).

Yup.  We're using them mainly to debug the tree simplification
code.  Visualizing the simplification process is a lot simpler
that way.

Diego.

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Robert Dewar]

<- Unparsing capabilities (could potentially be used as a
  source-to-source converter).
>>

Unparsing capabilities are enormously useful, both for debugging the
compiler and for the programmer understanding generated code (cf the
-gnatG switch in GNAT, we also provide a -gnatD switch that allows
debugging at the level of the unparsed source code).

RE: Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

Bernard,

I see that we are thinking along the same lines.

> And in fact the reason I've talked of SOAP
> previously in the thread is that
> I see GCC as a good base to create a "C++ to
> WSDL/server/stub" compiler
> working by parsing C++ source code and generating
> all the structures needed
> to access the corrsponding class instances through
> SOAP. 

Bravo : We there go!
1. We start by wrapping tree.c in soap calls and
toplev.c.
2. You encode the tree_node as an soap parameter
3. All of a sudden, you gcc is running as a web
service and anyone can call a function to get
something compiled without installing the server. The
ast/rtl or asm can be the output.
How would that be covered by the gpl?


> 
> In that case, if the original compiled code is
> GPLed, then the resulting
> code WSDL/server/stub will be (be it compiled by a
> GCC-derivative or even a
> proprietary compiler), but if such a GCC-derived
> compiler is used on
> non-GPLed code, it seems dubious to say the result
> will be GPLed.
But what about the usage of such an interface once
created? Just because the code is gpled as an
interface to a GPLed program, the users could be "M$
vi$ual studio" heaven forbid.

We really need to think about this again.

mike

=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com

RE: Linkage of GPLed GCC to Closed Source via XML or Perl

[Bernard Dautrevaux]

> -----Original Message-----
> From: Joe Buck [mailto:Joe.Buck@synopsys.com]
> Sent: Friday, March 01, 2002 5:55 PM
> To: mdupont777@yahoo.com
> Cc: Joe.Buck@synopsys.COM; gcc@gcc.gnu.org
> Subject: Re: Linkage of GPLed GCC to Closed Source via XML or Perl
> 
> 
> James Michael DuPont writes:
> 
> > It is very simple now. I am not trying to get around
> > the GPL, Joe, so you can see that your statement
> > should be retracted.
> 
> Yes, the tone of my statement was completely inappropriate.  
> You are not a
> bad guy, and I apologize for my original statement.  
> Furthermore this is
> an extremely complex issue and I think that at some point the 
> FSF is going
> to have to modify the policy somehow.
> 
> > The output of the introspector is source code in xml
> > format. That is covered by the GPL. Later queried from
> > the database, it is also source code, just in a
> > different form.
> 
> I'm not sure that that will fly.  I retract my accusations 
> against you,
> but I don't retract my statements that XML output will 
> provide new ways
> of attaching proprietary code to GCC (despite your claims that the GPL
> can prevent this).  On the other hand, it appears that 
> various compiler
> vendors are talking about common XML formats to represent parsed C++
> code.  If this comes about, any resistance on the part of GCC will be
> useless.

And in fact the reason I've talked of SOAP previously in the thread is that
I see GCC as a good base to create a "C++ to WSDL/server/stub" compiler
working by parsing C++ source code and generating all the structures needed
to access the corrsponding class instances through SOAP. 

In that case, if the original compiled code is GPLed, then the resulting
code WSDL/server/stub will be (be it compiled by a GCC-derivative or even a
proprietary compiler), but if such a GCC-derived compiler is used on
non-GPLed code, it seems dubious to say the result will be GPLed.

Regards,

	Bernard


--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 
> 

RE: Linkage of GPLed GCC to Closed Source via XML or Perl

[Daniel Berlin]

On Thu, 28 Feb 2002, Robert Dewar wrote:

> <<More seriously if someone creates a new GCC back-end to output something
> that TODAY is not assembly language, then fine: the back-end is GPLed and
> the resulting output can be used freely. In fact nothing proves that someday
> one will not see a processor that you will directly program in XML, so that
> XML would then be assembly language :-)
> >>
> 
> Please do not state dubious opinions as though they are legal fact. Remember
> that what the GPL means can only ultimately be ascertained by litigation, and
> many of the areas that people seem to think are black and white are quite
> gray in practice.

It's worse than that, as you know. You generally, in practice, end up with 
it black 
and white in some circuits, but grey in another, and just to be 
different, purple in a third.
Then 15 years later, the supreme court decides they were all wrong, and 
it's really brown, and the cycle begins anew.
--Dan

RE: Linkage of GPLed GCC to Closed Source via XML or Perl

[Robert Dewar]

<<More seriously if someone creates a new GCC back-end to output something
that TODAY is not assembly language, then fine: the back-end is GPLed and
the resulting output can be used freely. In fact nothing proves that someday
one will not see a processor that you will directly program in XML, so that
XML would then be assembly language :-)
>>

Please do not state dubious opinions as though they are legal fact. Remember
that what the GPL means can only ultimately be ascertained by litigation, and
many of the areas that people seem to think are black and white are quite
gray in practice.

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Robert Dewar]

<<You may well be right (though Eben Moglen has some good arguments that he
can persuade a court that artificial splitting of one program into two by
technical tricks can still be considered to be one program, I'm not a
lawyer so I don't know, and his argument clearly wouldn't work if standard
GCC interfaces work).  But why are you working so hard to do just that?
>>

There are indeed good arguments here. An interesting note here is that my
testimony in Intergraph vs Bentley (Philadelphia Federal Court a couple of
years ago) argued exactly the criteria for considering such splitting to
be artificial. It would have been an interesting ruling, unfortunately
the case settled and aborted the judge issuing the opinion (it aborted
the day before the opinion was due :-(

The issue in that case was when one program could be considered to be "using"
another program, but in my opinion the issues were very close to the
linking and aggregation issues that arise with the GPL. People know I
assume that the GPL is being litigated in the court room for the first
time right now in Boston ...

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Robert Dewar]

<<Also with Perl, you can just link to perl and you have
gone around the GPL.
>>

You are making some (legally) naive assumptions here. I urge you not
to play amateur lawyer here. The GPL is a legal document. If you want
to know what it means, do not assume you can find out here. If you have
questions that go beyond the FAQ, consult an attorney!

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

One last word on this for the record,
I will put this in the licence agreement for my
software and bring it to the right forum about
licences. 

0. My intent is to create a free software and support
the GNU cause. The users of my software must also be
free software and support the cause as well. The work
that I have done is a derived work based on tree.h. It
is not linked normally, but linked via the filesystem
and network. The data exchanged between my modules and
free software is so complex and dependent on the GCC
code that it must fall under the GPL.

I am also bringing this into the public so that we can
create a set of fair rules that will cover this form
of interaction and bind for others who are also
creating derived works from the GPLed code including
mine.

1. The work that I have done with the compiler is
meant to implement an introspection into a running
program. Like reflection in java. It is not for
creating backends that are closed source.It is for
understanding and documenting the tree nodes. It is
for creating an object-oriented interface to the
compiler. It is for support meta-programming. All of
this is prototyped in the perl-modules that I have
published. They are all strongly derived from the
original (art) work done by richard stallman and the
great gcc team. 

2. I wrote to this topic to Richard Stallman.
Richard Stallman said to me in the question if the
data exchange over the network is not linking and
therefore not covered by the GPL 
"We have a different interpretation of the situation.
Connecting modules through sockets or pipes does not
necessarily mean they are separate programs. In simple
cases they are separate, but not when they exchange
complex data structures."

That would support the idea that all these are derived
works and fall under the GPL.

3. Linus Torvalds said :
>Feel free to consider this email (in its >entirety,
not snipped into pieces) as being >public, so if you
think you want to post it, go >ahead. 
>The GPL notion of "linking" is really nothing but >a
specific technical way of trying to define >"derived
work". 
From a legal standpoint, technical issues have >some
validity, but in the end the _only_ thing >that
matters is whether it is derived or not. >Linking is
only one (strong) indicator that it is >indeed
derived. There are others. There are
>counter-indicators as well, of course, one of >them
being "previous work" (thus my willingness, >for
example, to have binary modules that were >basically
derived from SCO device drivers that >existed prior to
Linux - one of the original >impetuses for the module
interface). 
>And intent matters. 
>Linus

So from Linus's standpoint, 
All of these tools the use the tree nodes are derived
works like mine. 
All we need to do now is to get this in a licence
agreement that makes sure that the users of the module
who create derived works are all GPLed.

James Michael DuPont

=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Joe Buck]

> I'm a bit afraid the whole discussion here is quite irrelevant; such an
> interface allowing to use gcc with a proprietary back-end already exist (and
> ALWAYS existed): You just use GCC to generate assembly language, then
> assemble this through a proprietary assembler!... For a long time it was the
> ONLY way to use GCC on a lot of machines!

That's always been allowed.  People are also free to, in effect, add
proprietary front ends for other languages by producing programs that
generate C.  Adding new interfaces to GCC to make it easier to add
proprietary backends is another matter.  While there may be legal ways
to accomplish this, the official GCC policy is not to cooperate with
such efforts.

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[mike stump]

> Date: Thu, 28 Feb 2002 02:21:14 -0800 (PST)
> From: James Michael DuPont <mdupont777@yahoo.com>
> To: gcc@gcc.gnu.org

> For the past three years, I have been working on a project to create
> a object oriented interface to the GCC compiler, the GCC Node
> Introspector (http://introspector.sourceforge.net/).

Almost all licensing issues are off topic here.  Please don't go
there.  Instead, we've created a group just for that purpose,
gnu.misc.discuss.  Please use it instead.

All followups to that group instead.

RE: Linkage of GPLed GCC to Closed Source via XML or Perl

[Bernard Dautrevaux]

> -----Original Message-----
> From: Joe Buck [mailto:Joe.Buck@synopsys.com]
> Sent: Thursday, February 28, 2002 6:49 PM
> To: mdupont777@yahoo.com
> Cc: Joe.Buck@synopsys.COM; gcc@gcc.gnu.org
> Subject: Re: Linkage of GPLed GCC to Closed Source via XML or Perl
> 
> 
> I wrote:
> > >James Michael DuPont asks lots of questions
> > >indicating that he is attempting to find a legal way
> > >around the GPL, so that he can attach
> > >proprietary back-ends to GCC.
> > >I would urge people not to give him any assistance,
> > >even if he is only asking the questions out of
> > >intellectual curiousity.
> 
> By your own words, you've been working for three years on 
> trying to get
> information out of GCC for use in other tools.  Even if you 
> have no intent
> of trying to attach proprietary back ends to GCC, you are working very
> hard to enable others to do so.

I'm a bit afraid the whole discussion here is quite irrelevant; such an
interface allowing to use gcc with a proprietary back-end already exist (and
ALWAYS existed): You just use GCC to generate assembly language, then
assemble this through a proprietary assembler!... For a long time it was the
ONLY way to use GCC on a lot of machines!

So I don't see ANY interest in limiting the way people can use the result of
running gcc on some input file. In fact IIRC this was explicitely written in
the GCC license. Changing that will change GCC in an unusable tool. 

It seems someone is here advocating a rule like: the output of a GPL program
can only be fed to another GPL program.... 

Be careful: I think YOU had read at least once some assembly code generated
by GCC, so YOU may well be infected by the GPL virus and be now GPLed :-) :)
:) :) LOL

More seriously if someone creates a new GCC back-end to output something
that TODAY is not assembly language, then fine: the back-end is GPLed and
the resulting output can be used freely. In fact nothing proves that someday
one will not see a processor that you will directly program in XML, so that
XML would then be assembly language :-)

As for the extension of the meaning of linking (as used by the GPL) to
communication, even if with CORBA or SOAP this "looks like" effective
linking this is pure non-sense: you often don't even know how the service
you are invoking is implemented (C++, perl, Ada, Java or some exotic
language), and you have NO IDEA of the licensing to be applied to the
program you invoke; or are you sure the stock-quote service you are reading
every day is GPLed code or not? 

Extending the GPL to the whole net would be the dead of either the net or
the GPL; bets are open :-)

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[Joe Buck]

I wrote:
> >James Michael DuPont asks lots of questions
> >indicating that he is attempting to find a legal way
> >around the GPL, so that he can attach
> >proprietary back-ends to GCC.
> >I would urge people not to give him any assistance,
> >even if he is only asking the questions out of
> >intellectual curiousity.

By your own words, you've been working for three years on trying to get
information out of GCC for use in other tools.  Even if you have no intent
of trying to attach proprietary back ends to GCC, you are working very
hard to enable others to do so.

> In that light, every GPLed Program can be compromised via alternative
> interfaces to function invocation other than linking, and GPL code can
> be translated into an external representation that is no longer code,
> but data.  All within the confines of the GPL.

You may well be right (though Eben Moglen has some good arguments that he
can persuade a court that artificial splitting of one program into two by
technical tricks can still be considered to be one program, I'm not a
lawyer so I don't know, and his argument clearly wouldn't work if standard
GCC interfaces work).  But why are you working so hard to do just that?
Even if your intentions are good, you are helping to bring about what you
object to.

> Also with Perl, you can just link to perl and you have
> gone around the GPL.

In this case I think you're wrong.  Perl is dual-licensed, but if you
link Perl to GPL (only) code, the program as a whole can only be
distributed under GPL terms.

> The GCC list has had many people who are interested in
> getting access to the compiler data, and many of them
> are turned away in a similar fashion.

I know.  It is a problem, and eventually people will do it, and the
result will be that people will subvert RMS's intent.  If they'd
figured out how to do this years ago, we'd now have no GNU C++ and
no GNU Objective-C.  In the long run, it's a losing battle, I agree.

> I think the GCC list has to ask itself,
> how long are we going to wait before addressing the
> issues at hand, and not just ignoring the problem to
> death. 

As long as possible, because as long as there isn't a really clean way
to attach proprietary front ends and back ends, people who are on the
fence about going proprietary or submitting their code back will choose
the latter.

> It is time to get our heads out of the sand and face
> reality.

There is value in postponing "facing reality".

Re: Linkage of GPLed GCC to Closed Source via XML or Perl

[James Michael DuPont]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4218 bytes --]

Joe, 

I am really shocked : 
>James Michael DuPont asks lots of questions
>indicating that he is attempting to find a legal way
>around the GPL, so that he can attach
>proprietary back-ends to GCC.
>I would urge people not to give him any assistance,
>even if he is only asking the questions out of
>intellectual curiousity.

I think you should not shoot first without asking
questions. Everyone allways talks about how nice
everyone in "Open Source" is to each other. This is
setting a bad example.

I am sorry to tell you that you are misjudging me.
You might not know me, but I am a supporter of the GNU
cause.

The reason why I am pointing out the flaws in the GPL
is because the GPL has an outdated idea of linkage,
it is that simple.

I think back to the story of gödel and how he proved
that every system can be self referential, and every
function can be encoded into data, and that data can
be fed back into itself to create a contradiction.
In that light, every GPLed Program can be compromised
via alternative interfaces to function invocation
other
than linking, and GPL code can be translated into an
external representation that is no longer code, but
data. 
All within the confines of the GPL.

Also with Perl, you can just link to perl and you have
gone around the GPL.

Invocation of functions, evocation of effects, that is
the key issue here.  The freedom to invoke, and the
freedom to see how it is done. The protection of this
freedom will have to be rethought in the light of the
changes in the world.

I think that it is time to consider the concepts of
invocation versus linkage in the GPL and allow for
external representation, network based linkage and
invocation. We will see all these splinter projects
come together and a brand new interest in GNU from
many different areas.

Let me tell you about myself and my interests : 

I always was asking myself how to create an C++ class
that has a list of members that are available. Like
reflection. Originally I wanted to create this
interface directly into the compiler and allows an
object to get a rtti-like interface into its
definition.

I am a believer in the GCC and GNU. I use emacs and
gcc at home and at work. I run only linux at home and
and running debian gnu/linux.  

For my living i write not compilers, but billing
systems. We deal with complex data structures and they
have to be fast. C++ is an ideal language and that is
why I use it.

Perl supports introspection to some degree, as java.
Noone is crying about that.

When I first came to this list in 1999
I was asking about creating an object oriented C++
interface into the complier : 
http://gcc.gnu.org/ml/gcc/1999-04n/msg00851.html
Back then the Trees were not documented as well
either.

I remember when denis percin dyp@perchine.com
kicked off a discussion about external representation.

you said  :
http://gcc.gnu.org/ml/gcc/1999-01n/msg00706.html
"I'm afraid that's exactly what RMS is extremely
worried about:
specifically, that proposed changes make it easier for
*proprietary*
tools to use the gcc front ends or back ends."

He has gone on to abandon talking to gcc, and wrote
his own parser with the project
DCT: The Document Comprehension Tool
http://dct.sourceforge.net

The GCC list has had many people who are interested in
getting access to the compiler data, and many of them
are turned away in a similar fashion.

Let me tell you that there are 4 projects out there
that are interfacing to the gcc compiler :

cpp2xml http://www.scl.csd.uwo.ca/Projects/cpp2xml

CppX	http://www.swag.uwaterloo.ca/~cppx/
This is a project that is very similar to mine,
without the introspection idea.

Gasta from Guillaume Thouvenin   Gasta - Gcc Abstract
Syntax Tree Analysis http://gasta.sf.net

GCC_XML from http://public.kitware.com/GCC_XML/
Also a GCC patch.

I think the GCC list has to ask itself,
how long are we going to wait before addressing the
issues at hand, and not just ignoring the problem to
death. 

It is time to get our heads out of the sand and face
reality.

Mike




=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com