Errr.. no..

[Molt]

I really think this would be a bad idea for all concerned.

Your RGPL, in my opinion, would just marginalise itself and also actually endanger the entire GPL concept.

You say it's possible now to only work with free software, I agree, but only if you're very lucky. Judging from recent CB conversations, Perlmonks meetings, and other technical discussions I've seen all too many talented programmers without any kind of paid work whatsoever. I don't think many people can afford to be that picky about what they're working on, especially if they have a family to feed.

This is all too easy to negatively spin, tell any company that if they're going to use your tools then their own products will also have to be free is a good way to guarantee most won't even look at it. They'll standardise on something else, something which gives them the ability to chose which license best suits them. When this happens the language/tool sees a notable reduction in usage, and especially in paid-for services such as support and book sales, so suddenly your tool won't have the support networks that many businesses demand so even those writing free software will seriously consider looking elsewhere.

If, as it seems, you're suggesting applying this to existing tools such as perl and make then consider the reputation hit. The GNU Foundation, EFF, and others have been working very hard for a number of years on making Open Source software more acceptable to businesses, suddenly tearing away their tools will make them somewhat upset. Headlines screaming "New RGPL License Will Cost Businesses $30 Billion a year", and spun by companies who do want to see the GPL fail, are not going to help free software's reputation.

A tool which dictates the license of it's result will anger supporters of other licenses. Watch as BSD devotees begin to walk away from your tools, closely followed the the Mozilla license fans, the Apache license supporters, and any other group. GNU has the most successful license for free software at the moment, but I think it really doesn't want to alienate the others more than needed.

The GPL plays about with copyright, it dances on the edges. As yet I think it's still untested in a heavy-duty court-case with a big company, this would do it.. and with a license which is even more likely to fail in court. If this did fail the entire GPL could collapse like a house of cards.

I can't see this more restrictive license ever happening in any appreciable quantity, and as someone who loves to work with Perl I'm very happy about this. I do want to be able to accept jobs which don't work exclusively on GPL'ed software, I do want to be able to use the same tools at home and work, but if this happened I'd reluctantly lay down my Perl programming and go and to work for someone who'd let me work in C++, Java, or even (godforbid) C#. At least these will let me chose what happens with my code.

Final point: I've compiled GPL'ed software on proprietry compilers in the past, if you're going to stop me compiling propreitry software for my employers on RGPL'ed compilers then I seriously begin to question which gives me the freedoms I need and want. Microsoft once accused the GPL of being a 'viral' license, let's not give them very good reason to repeat the accusation.

[mdupont]

Right now there is no way to access the parse tree of the gcc from anywhere.

This is for my introspector.sf.net projects GCC patch and output.

The introspector itself could even stay under the GPL, but where would it get the semantically annotated parse trees from the gcc from?

There is no program database, no full symantic parser for emacs.

This would allow emacs and vim and other tools like DIA and VCG to access this data safely. That is what is is meant to do. A meta-data exchange.

It is not a general license for end user software, it is a license for program meta data. No one has any real tools for this right now in the c/c++ world. The perl::b modules are the only thing close, but there is no repository and browser for the output.

Please dont just jump to conclusions, I am not just proposing another license to propose another license. You cannot use any of the MSDN data for generation of free software tools. You cannot use the shared source from microsoft in a GPL program.<> This license is limited to GPLed software for the first phase and there is enough out there that would benefit from this program.

If the implications of the license are understood we can always expand it.

Please understand the limited scope of my license before shooting me!

mike

[Molt]

You did say that the license was intended to apply to programs such as gcc, perl, make, yacc, and lexx, and others which'd parse program trees.

I'd say perl and make are most certainly end-user software. An end-user cannot run any Perl program without perl on their machine, and any flavour of *nix really needs 'make' to be able to build most of the applications available, and often gcc too.

To try and restrict gcc so that any program compiled on it would be GPL'ed would have the problems I went into above, and to have a program where two sets of output (The executable code, and the parse tree for the code) come under two different licenses is a quick way to overcomplicate things to an unusable degree. How do I tell which parts are which when looking at the source?

I know I can't use MSDN code for free software, or the source of any of the MS products. I can, however, use their compiler and the profiling etc. utilities which come bundled with it.

I'm convinced your program is useful. I was initially hired into my current job as a C++ programmer, and now am happily learning the B::* modules and Inline::CPP. I'm just less than convinced of your license's usefulness, or even practicality. If you're suggesting a license which covers only add-on components such as you're designing then feel free to try it, but don't be overly surprised they won't get used too much, and they'll never end up in the core since they're under a different (and more restrictive) license.

Another problem with this, which hadn't occured to me before, is that trying to change the license with a patch is a very good way of breaking the GPL itself. If you're able to say "If you patch GCC with my patch the whole thing comes under my license" what is to stop a company saying "We've patched GCC with our own patch, and thus the whole thing is under our license". The fact you're proposing a related license is, I believe, legally irrelevent.

If I did misunderstand the scope of your license and you're not trying to get it applied to basic tools then I apologise, but when the list of tools you give as examples shocks me so much I choke on my coffee I felt I needed to reply.

[mdupont]

It is a difficult subject.

I wont be distributing the modified versions of the GPL software, but exporting them as web services only for GPLed users. To protect them from usage by non-free software, the RGPL is applied to the XML output.

I cannot limit the output of a GPL program, or change its license, but as a webservice, the gcc under GPLv2 does not have to be redistributed in source.

I can offer the data needed to the free software development community as an incentive to write free code.

>Another problem with this, which hadn't occured to me >before, is that trying to change the license with a patch >is a very good way of breaking the GPL itself.

I intend on patching the GPLed program with a private patch, extracting XML, which has no license, and licensing the output as RGPL via a webservice. Because the GPL program would never be redistributed there is not a problem. Because there is no linkage, there is not derived work.

The authors will not WANT the XML patch distributed, because then anyone can then dump out the trees.

mike