Re: My Favorite soapbox : XML linkage (was Re: [DotGNU]Jabber-thon)

[James Michael DuPont]

Norbert,

Achtung!/Warning!: this is a *really* long mail, and I
do repeat myself a couple of times. Let me try and
summ it all up here at the top so you dont have to
read the whole thing if you dont want to.

First of all Norbert, Thank you very much for taking
you valuable time to explain this all to me (again and
again as it might see). I am very impressed with your
arguments. I think that we do agree in the end. 
I have a lot of respect for you and the whole DotGNU
team, this has been one of the most interesting and
enriching times in my life corresponding with all of
you. 

I have learned alot about the history of the DotGNU
from your post, please don't get frustrated with me
for bringing up the the same issues over and over
again.

I am not someone who gives up easily, and I have been
pursuing this idea for over 9 years and counting.
Back in 1993-1995 I was working for a company that was
creating a C++ reverse engineering tool (innovative
software GmbH). They had a C++ parser, code browser,
graph layout, UML diagrams and code and documentation
generators. Even a persistent code repository.

I started on the GCC interface about 3 years ago, in
1999 I had started patching the GCC. 

Just for the record, the commercial project is no
longer being sold and I have no intention of creating
any non-free software to attach the the GCC.

The problem was that the parser from this product was
not good and did not give you all the type information
for function bodies. They could not even use the tool
on itself to bootstrap properly. It could not parse C,
it could not parse GNU c.

I asked myself, "Why don't we use the GCC parser?"
of course, that cannot be done without 
creating an GPLed version of the software. But further
still, the GCC development team have very good reasons

for not wanting people interfacing like that into the
GCC.

One of the reasons that I have gotten into this
mindset of trying to protect the programs is my
discussions with RMS about the licensing of the
introspector and interfacing to the GCC. He has shown
me the pitfalls of being too open with your data and
the problems involved.

I have been arguing the case of protecting the GPLed
code from abuse, 
and it seems that we will need to go to great lengths
to do so in the DotGnu environment.
It seems that there is no way to implement the
introspector without breaking something in the GPL or
opening the GCC up to abuse. 

This is exactly the issue that I have found to be in
the .NET framework with the compiler interfaces. I
brought this issue up on the mono list when someone
was asking if they can embed the compiler into a
non-free, or at least non-GPL program. 
See the threads
http://lists.ximian.com/archives/public/mono-list/2002-May/005737.html
http://lists.ximian.com/archives/public/mono-list/2002-May/005815.html
http://lists.ximian.com/archives/public/mono-list/2002-May/005808.html
http://lists.ximian.com/archives/public/mono-list/2002-May/005811.html
http://lists.ximian.com/archives/public/mono-list/2002-May/005850.html

You are basically telling me that we won't have any of
the same licensing issues with the DotGNU project and
Pnet compiler as with the gcc. 
That is very interesting because it gives me a whole
new perspective on the introspector project.

Best Regards,
James Michael DuPont

See my comments to your comments in the following
lines :
> That is true BUT let's not overlook that in this
> situation
> where the user doesn't get "package A" even in
> binary form,
> and just has access to its functionality via RPC
> over the
> internet, there is such a significant loss of
> performance
> and reliability that I think that even though this
> scenario is
> bad, it is certainly not a serious threat against
> Free Software.

That is just one scenario. But Package A was a GPLEd
package. They can access the source.The can run it
over local loop. People can (and some do i have heard)
this to get around the GPL.

Also for the issue of the compiler ASTs : 
It does not matter how long it takes to get that
information, you only need it once for an entire
project to extract all types of interesting
information. The ASTs can be used to regenerate a big
chunk of the source code, translate it into other
languages and make machine code.

I have heard that RUBY provides this information to
the users and allows for all types of customization to
be done to the language by user specified AST
transforms. That is one of the things I would like to
support with the introspector project.

> > The user loses the freedom to modify the non-free
> > add-on. The will then have to re-implement the
> add-on
> > to make any changes to it. 
> 
> This is true.  In the world of webservices, copyleft
> is somewhat
> less effective than in the pre-webservices world. 
> This is a
> direct consequence of copyleft being based on
> copyright law.
> Webservice protocols give more freedoms for
> combining parts, that
> are (from a legal perspective) different "works",
> into a
> functional whole.  This means that the overall
> effects of
> copyright law are getting weaker.  
> We're concerned
> about this
> because it makes copyleft weaker, but we should look
> at this in
> the broader context of this really weakening all
> kinds of
> software monopolies.  Copyleft is a kind of monopoly
> to some
> code, but a monopoly which is not held by an
> individual or
> company, but by the whole community of free software
> users.
> That's why it's a good monopoly, not an evil monoply
> like those
> of Microsoft Corp.  However Microsoft's monopolies
> are weakened
> also.  
But we are in a different situation from microsoft,
if people use the Microsoft code in such a way, they
still have to accept the EULA and pay through the
nose. 
We are giving the code away and the only return on
investment is when another user contributes back to
us. That happens less if there is no reason for them
to do so. Even if a programmer wants to, the company
probably wont let them.

>The vision of the DotGNU project is that
> instead of
> trying to fight against the wind of this weakening
> of copyright law, we sail with this wind and use it
to destroy the effective
> desktop OS monopoly which is currently held by
> Microsoft Corp.

But that does not address the motivation for creating
GPLed tools. Many GPLed tool are also created because
people do not have this option. 
That takes the wind out of our sails if anyone can
just use and abuse any of our tools with no remorse.
Many of these issues have been learned by the hard
fights that GCC has had with chip vendors trying to
get backends for various new chips. If they could get
away from freeing up the implementation, they would.

That is not only applicable to compilers, but also to
parts of the framework.

> > > > We still need to be rethink the entire
> licensing
> > > > issue
> > > 
> > > These things have been thought through pretty
> > > carefully right at
> > > the beginning of the DotGNU project.
> > 
> > We have had this discussion before. The problem is
> > that we still dont have a resolution. 
> 
> The resolution is that Enzo, Barry and I decided to
> go ahead
> with a GPL'd webservices and virtual identities
> framework
> project which we would seek to make as protective of
> software
> freedoms as we can with the GNU GPL.  In the
> beginning we had
> serious doubts whether we would get the FSF's
> endorsement for
> this project... we were very aware that the
> webservices paradigm
> tends to weaken the good effects of copyleft, and in
> fact I was
> personally pretty surprised when we got the backing
> of the FSF
> for this project, which made it possible to use the
> name
> "DotGNU" which Enzo had proposed.
> 

> I would say that this decision to go with GNU GPL
> but endorse
> all useful aspects of the webservices wave is not
> negotiable,
> it's part of the core of what DotGNU is all about. 
Fine then I can I safely host the introspector on top
of DotGNU?

> Since you
> feel strongly about the need for strong copyleft
> even across
> RPC, you can encourage the FSF to try making a new
> version of
> the GPL that tries to establish a stronger form of
> copyleft that
> would work across webservice protocols (there are
> such ideas
> under consideration), but I think that it's outside
> the scope of
> the DotGNU project to get too deeply involved in
> such license
> discussions, at least as long as there is no risk of
> the
> proposed changes to the GPL further weakening
> copyleft or having
> negative impacts on the usefulness of DotGNU.  
One of the areas that has to be looked into is the
definition of linking under dotgnu. 
What does the GPL say about linking in a DOTNET
environment? Can I invoke, Pinvoke, remotly invoke
GPLed code from non-free code? 
Can I redistribute IL of GPLed code? What are the
terms of distribution and invocation?
 
Another is the area of the usage of the compiler and
GPLed code as we will get to later in this mail.


>The
> focus of the
> DotGNU project needs to be on creating useful
> software that will
> be licensed under whatever is the current version of
> the GNU
> General Public License, as published by the FSF.

Yes, And I am sorry if I am wasting bandwith and time
on this discussion, but I think we will get some
productive outcome from it. As I said, it is my
favorite soapbox, and I do rant alot about it.

One reason that I feel so strongly about this is that
I want to complete the introspector project, and to do
so, I need to get access to a large set of ASTs.

I have put over 2 years into this project and do not
want to drop it. It might be possible if we can work
out an aggreement with the DotGNU project.

> > As soon as you create a transport, you seem to
> > magically avoid linkage.
> > This is wrong.
> 
> I think that trying to change this situation is a
> worthy cause,
> but DotGNU is ambitious enough already without
> opening another
> front here.  We need to go forward with writing
> code.  Any doubt
> about what license(s) DotGNU will use would slow our
> development
> progress.
I agree with you there fully.

> 
> > Most of the GNU programs are written in C. RMS
> holds
> > that we should not allow programs like compilers
> and
> > other gnu applications even via a Shared Lib.
> 
> This is in refence to compilers etc (especially GCC)
> that are
> not part of DotGNU.  DotGNU's C# compiler has to be
> available as
> a shared lib, and even with C# wrappers, because
> otherwise we
> could not be compatible to .NET (and yes, this goal
> has
> Richard's approval too.)

And the compiler can then be embedded into a dynamic
language link c# and linked to non-free software? 

Could I embed the C# compiler as a Perl DLL?

Also the usage of the ASP.NET
System.CodeDOM.Compiler.ICodeParser that can deliver
asts to any user without linkage?

If so, I would be interested in working on those
parts, when we get the bases covered with the current
project. 

Not because I want to go around the GPL, but I feel
that we need to be able to implement these features in
order to promote growth and expansion.

I cannot implement them for the GCC with my original
introspector project as planned without going against
the explicit wish of RMS. 

But I think that I can easily change the software to
use the pnet compiler if these interfaces are to be
supported. 

That would also allow the introspector to be
compatible with all types of Code Dom Providers!

Personally I feel that they will help the project and
be able to provide all types of add in tools,
visualization services. 

I promised the dotgnu team that I will help test and
work on the current tasks while I get up to speed with
the project and c#. I will do what I can to help and
not hinder to project. 

One of the reasons that I came to this list was the
excellent work done by Rhys on the compiler. 

He has done an impressive job at cleaning up the tree
interface. Also your encouraging words Norbert gave me
the feeling that this was the right place to try and
get my roots in the ground.

 
> > But on that note, the GPL is being infected by
> > proprietary software already. 
> 
> ???
If you look at some of the problems that we have with
the usage of the ASTs and the interfacing to the gcc.
The university of waterloo has published a tool that
is specificly intended on removing the GPL from the
asts, the SWAG kit and cppx.
http://swag.uwaterloo.ca/~swagkit/
http://swag.uwaterloo.ca/~cppx/

mike

=====
James Michael DuPont

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