http://www.perlmonks.org?node_id=176041


in reply to Errr.. no..
in thread OT: A Modest Proposal for a GNU infrastructure license RGPL

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

Replies are listed 'Best First'.
Re: Re: Errr.. no..
by Molt (Chaplain) on Jun 20, 2002 at 15:42 UTC

    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.

      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