[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: James Michael DuPont
Subject: Re: My Favorite soapbox : XML linkage (was Re: [DotGNU]Jabber-thon)
Date: Sun, 9 Jun 2002 18:28:01 -0700 (PDT)


First note that this is a long mail and It contain
alot of quotes to try and summarize the situation so
that noone has to dig through the archive of the mono

I found it very funny that
has taken down the May Archives so quickly from the
main archive page. It seems that google does not index
them either. Even if they are on the web server,
taking them off does not help people using them.

I did link to all the threads in the conversation,
including most of what you summarized (or tried to).
You did not provide quotes to support your arguments,
so you will get them from me.

You write : 
>   I guess he's also tired of having to reply to
issues raised by people
>   that try to spread misinformation instead of
furthering freedom and
>   code.

Sure he cannot answer everyone questions, but he has
taken his time to answer almost every single one of my
questions and I never got the type of flack from him
that you seem to dish out.

I guess you might be talking about me? Insults and
Cheap Shots like that are what get flames burning. 

If you have any examples of misinformation coming from
me, please tell me, and you will get a public apology
if you are right. If not then just cut the crap.

I even apologies to the mono list for wasting thier
time, even thought it turned out that I was not. Fancy
that, someone trying to make a peacful environment and
futher free software.

You seem to like to thow stones, and get away with it

Tough talk might impress other people, not me.

People living in glass houses should not throw stones,
so let me rebuke some of your weaker statements.

But first, Let me tell you that I have been
researching alot into this topic. I have put at least
3 years in an effort to try and create a compiler API
interface that also has the same if not greater
licensing issues that I presented here. 

The only reason I brought up the issue at all is
because it is something that I am able to contribute a
bit to. 

I have been searching for a way to safely implement a
similar interface for the GCC,
and have been in contact with many GCC developers and
FSF members. 
There does seem to be any way to interface to the gcc
compiler safely without opening it up to more 
non-free software latching onto it. 
This applies to the pnet and msc, even if you might
not be as concerned about that, you can then have
closed-source applications using your parser and
redistributing mcs as a part of a larger commercial

If that is what you want, then who is futhering
"freedom and code"?

This entire issue is not resolved yet as far as I can

There are two issues at hand  : 
1. The issue of licensing the C# compiler under less
than GPL  
2. The support of the
System.CodeDOM.Compiler.ICodeParser interface.
Two separate but similar issues.

So for proper context, I will address your issues with
quotes and hrefs,
If I missed anything important, please tell me.

You wrote :
>       What miguel didn't say in this mail, but said in
>       other mails on the same
>       topic, is that he would change the license of MCS
>       from GPL to GPL +
>       linking exception
Where did he say that?

He mentioned the loosening of the license if need in a
previous mail. I should have quoted that as well.
>       Even if there is, you can run the compiler on its
own AppDomain, and we
>       will make sure that anything that any interfaces
required from the
>       compiler are available under license terms that
allow for people to use
>       them.
>       So that pretty much ends the debate.
>       Miguel.

So that could include the linking exception, but the
resolution is not that straight forward.

This whole issue came up with the question of the
usage of the mono
compiler under a non-gpl licence where Miguel stated
that the MCS was
under the GPL, no mention of the loosing of the
license (yet).

You write :
>         MCS is currently an executable, but it would take
>         little effort in
>         converting it to a library that could be reused
>         inside another one.
So lets go back to the beginning, you are right, but
there is the licensing issue unresolved before I got
involed. Even then it is still not resolved.

The original answer from Miguel to Garrett Serack Mail
was this
--------------- SNIP  ---------------------------

                >       What's the feasability at this point in time of
making an In-memory
                >       compiler out of Mono's C# compiler.  I'm just
kinda puttering around
                >       with the .NET scripting stuff for MS's .NET, but
the only language that
                >       is supported with just the .NET runtime is
JScript. (Not that I mind
                >       terribly.) In order to even support C# compiling,
the user must have the
                >       Full Framework.

                It is trivial.  Just change a flag when you create
the AssemblyBuilder,
                instead of `Save', use the `Run' flag (or

                > So, I started thinking that Mono has a c#
compiler, and I wonder if you
                > think it would take me much work to adapt that for
use in a scripting
                > solution.

                It is an interesting project, but not a straight
forward one.

                > This would go nicely with an open-source(BSD
License) VSA replacement
                > I'm currently working on, and I'd like to support
more languages,
                > without the need for the end application to rely
on the full Framework.

                The Mono C# compiler is under the terms of the GNU
GPL, just be aware of

--------------- END SNIP ------------------------
Note that there was no mention yet of the relicensing

Then I came with my question of the CodeDom interface,
and raised the issues of linking the GPLed code to
non-gpled code. Many mails persued.

The original thread author, Garrett then stated after
some mails that he would put his
code under GPL, but that might affect the users,
so the linking issues was not resolved.
----------------SNIP -----------------------------
                Wow. I certainly touched off a discussion here :)

                Brad Wilson wrote:

                >Daniel Carrera wrote:
                >>Yes, but the GPL is not any more "viral" than a
license from Microsoft
                >>which limits your ability to use their code (e.g.
their shared source
                >I disagree. The Microsoft license says you can't
use their stuff for
                >commercial use, but it makes no additional
requirements of any code that
                >links to them. The GPL says that by merely linking,
you now must make your
                >own code GPL. That is specifically the problem in
discussion here.
                Um, *Personally* when I write code I intend to
open-source there are a
                couple of different questions I have before choosing
a license.  If I
                want the code to be used, as much as possible, and
I'm not concerned
                with the with what people intend to make of it, I
tend to fall to the
                BSD (and like ) licenses.  My Embeddable Scripting
for Applications
                (ESA) project is done with that in mind.
Essentially, I'm getting tired
                of answering questions about the scripting
technology in MS's poorly
                documented VSA technology, that I'm opening up that
code that I'm
                writing for others to use. That, and I'm less than
thrilled with Summit
                Software's rather heavy handed requirements for even
evaluating the VSIP
                Scripting Engine, and I wanted to provide that for

                On the other hand, technology that I think is neat,
but more of a
                complete product, I'd release as GPL, so that others
don't just take and
                run. :p

                >>This is why the GPL is almost never used for
libraries.  Under Linux,
                >>libraries are usually LGPL or X11.  That way
linking is allowed.
                >Right. And the problem is that the line beteween
executable (C# compiler)
                >and library (System.CodeDOM) is blurred now. The
compiler is GPL, not LGPL.
                >>I can't think of a single library that has this
GPL problem you describe.
                >Until now, potentially...
                Um Yeah!

                I really was hoping the compiler was at least LGPL
rather GPL.  I'm
                building something I expect people to include in
their own projects,
                regardless whether it's a Opensource project or not.
(as my primary goal
                is to get folks to use the ESA project for their own
needs), and to have
                it eventually run on .NET, mono and whatever else it

                At most I'm looking for a bit of recognition.

                So, I guess I do have a problem. I'd like to add a
C# compiler to the
                scripting engine, that could be embedded into an
application. *Without*
                making (a) my own library GPL and (b) the target
application GPL.  I
                think that this sort of thing would be a nice
complement to the mono
                project as a whole.

                Is there going to be a way I can resolve this?
Special License? Get the
                mono C# compiler license changed?

                I'm a bit confusled as to why the Compiler itself
needs to be GPL'd
                anyway... I mean is there a *fear* that someone may
take it, extend it
                and make it commercial without releasing the code to
it? Really? I can't
                see how someone would. Seems a little unlikely.

--------------- END SNIP ------------------------
No futher addressing of the issue yet.

You Write :
                > (if it's
                > actually needed: it
                > appears, though, that the interface doesn't
                > the use of the
                > compiler in the library).

So again, more tough talk.
Carl witty writes in response to Miguel 

-------------- SNIP ----------------------------------
               Miguel de Icaza <address@hidden> writes:

               > The System.CodeDOM API is a mechanism to
"build" source code through an
               > API.  It is just an abstraction so that
ASP.NET can "create" pages built
               > on a number of languages.

               Well, there's also
System.CodeDOM.Compiler.ICodeParser, which takes
               source code and parses it into a CodeDOM tree.
 (I think Visual Studio
               .NET uses this to handle its
               The C# parser in mcs might be a good place to
start to provide this

               Carl Witty

--------------- END SNIP ------------------------

This interface does require the embedding of the
You can argue like Miguel did that it does not
absolutly *need* to implement it, 
the same view that the DotGNU team seems to share.
--------------- SNIP ------------------------
                I noticed that .NET does not ship with any
implementations of
                ICodeParser, and the only class that implements the
                (CodeParser) is an abstract class with "helper"
methods, but no
                implementation at all.

                So people can not depend on this existing, because
even in .NET they
                wont be able to get anything to work with it. 

                MCS might be used though to implement this beast if
we choose to, and in
                that case, we will probably package the compiler as
a component that can
                run on its own AppDomain, allowing for the GPL code
to be running side
                by side with proprietary code.

--------------- END SNIP ------------------------

Best Regards,

James Michael DuPont

Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]