OT: A Modest Proposal for a GNU infrastructure license RGPL

[mdupont]

This is a bit off topic for perl, but since I have written the software in perl that I want to license under this.

This does affect perl and relates to the B::* modules

Also the perl core is GPled and is a target for this module.

You might find it an interesting proposal. I have a modest proposition :

To create a license for software that only takes GPLed sourcecode as input and produces GPLed code as output.

Basically, it is to create a licensed persistent memory model where all data and functions in whatever form are treated as if they are in the main memory of a statically linked executable, even if all types of neat tricks are used.

More to the point, that the inputs and outputs must be already be source code (in what ever form) and that must already be under the GPL (in whatever form). If documentation is produced, then it would be under the GPL documentation license.

It is a bit like a recusive function f(n>1) that does not solve the base case, and leave the n=1 and n=0 to a specific other function.

The GPL is used by many projects to maintain thier freedom.

The LGPL is a license that allows for the production of non-free software. This could be seen as a right-wing GPL, a RGPL that is a restrictive GPL. One that only allows for the production of more free software.

Because the GPL is so sucessful, there are many applications that use it. It is now possible to work only with free software.

I would like to give those who use free software an advantage over those who don't.

By making services and software that are only legally usable by those using free software.

This special type of license will only applies to software that works on other software, thus meta-software.

The inputs and outputs of this meta software of any form would be limited to free software only.

This of course does not affect the input and output of the free software once it is compiled, so the used software is not changed. Only the usage of the GNU Infrastructure License would be affected.

The GPL is carefully designed to allow users to do anything with the input and output of the files not to affected by the license.

Some authors decide to publish a version under GPL for non-profit usage. I want to go a step further.

My question is if I can publish a software that is for GNU usage only? That is only licensed for usage in conjunction with free software, down to the user.

This would then be usable to create an entire range of services for promoting the usage of the GPL and giving them and advantage and a incentive over non-free software.

This would overcome the issues non-free software using XML, File Systems, XML-RPC, SOAP, Dynamic Linking, and Web Services for interfacing with GNU software and going around the GPL.

This would give an explicit license to a limited set of powerful interfaces that are for use for only free software. This would give people who want to experiment with interfacing to the GCC via dynamic linkage a legal basic protection.

Now the protection of the data files are very tricky, because the data file are sourcecode.

The best would be to treat all data files as if they are persistent inside the memory of the GPLed program and that any usage of them is a derived work.

If a data file is produced derived from source code, this data file would also be under a special form of the GPL that prevents it from being used by any non GNU infrastructure licensed tool.

Of course you wont have the freedom to take away this protection offered.

This would allow the safe storage of internal data structures without their usage in non-free software.

No non-gpled program would not be allowed to use any of the internal data structures of this program. Not to read or write them or process them electronically. If it is offered as a web service, only users from free software projects would be allowed to use the software in conjunction with free software.

I have put together a summary of the licensing points for your review.

This license will help create a massive online database of program meta data and hope to protect it in any way at all.

Remember this only applies to a very small set of tools that process programming languages and covers the in-memory representations of the programming languages in a form that is very close to being executable, but still readable and editable. An enriched source code. All this does is try an protect the services rendered by the various compiler and interpreters so that they may be "PATCHED" to dump thier data into this meta-data repository without fear.

This will apply to programs like GCC,PERL, BASH, MAKE, YACC, LEX and any program that can parse language trees.

An entire new generation of visualization and editing tools can be created on this foundation.

The RGPL idea has crystallized into a very restrictive and recursive idea indeed.

It might have to be renamed into RPL (Restrictive/Recursive/Right-Wing Public License) if the GNU group rejects it, but for now, I will use the RGPL, because it is the opposite of the LGPL.

Get it Left-Wing, Liberal, Lesser / Right-Wing, Restrictive, Recursive ?

Also the adding of a level notation is needed RGPL(N) for specifying the recursion factor.

I think the issue is now of a special end user license that is completely outside of the GPL.

The restrictions imposed are simple : 1. You do not have the right to remove the restrictions.

2. You do not have the right to use the software in a way that is not explicitly given.

3. All output of the program is at a one higher level of the recursion, all input at the same or one level below.

4. You cannot use input from any other source but from what is specified.

All RGPL(N) input and output is source code mixed with mark-up in a declarative language.

Here is an overview of the license and linkage : 1. LGPL software can be linked to by other programs GPL and non GPL programs.

2. GPL software can only be used by users and linked to by other GPL programs, it can link to LGPL programs, but cannot link to RGPL programs, otherwise the RGPL program might be considered a derived work and fall under the GPL.

3. The GPL program can only use the output of the RGPL, the RGPL can only use the output of the PATCH to the GPL program.

4. This GPL PATCH is will be a intellectual property of a holding company and will not be distributed outside of it. Only the usage of it via a registered user via a web service with a restrictive EULA and Terms of Usage will give access to the ability to invoke the PATCH.

Under the GPL v2 there is no need to distribute the source code of this patch, and that will prevent third parties from abusing the PATCHED program, because non-one will ever get the source code. Anyone who does will have to either sign a NDA with the company or join the holding company.

Here are three examples : A. GPL software + PATCH = RGPL(1) output The RGPL(1) output can only be used by RGPL(1) and GPL programs.

B. RPL(1) + PATCH = RGPL(2) output The RGPL(2) output can only be used by RGPL(1) and RGPL(2) programs.

C. RPL(n) + PATCH = RGPL(n+1) output The RGPL(n+1) output can only be used by RGPL(n) and RGPL(n+1) programs.

The point is that the license gets recursively more and more restrictive.

Creating layers and layers of programs and licensing. All data and output is licensed only for usage by the programs at the same layer or higher.

There is no linking between the programs, only an File and network connection that have no copyright. The data will be only accessible via a site the imposes restrictions on copying, linking, quoting and usage of the copyrighted materials.

All of this to protect the GPLed programs from having such "patches" widely available and the programs that use them under the GPL.

If you look at putting the RGPL under the GPL, you will see that a profilation of such patches would just cause licensing chaos and just invite abuse by non-free software vendors.

This license being restrictive, does not mean it is not free. It gives you less freedom, but opens up a area of freedom that is not covered by the GPL, the freedom to exchange data safely between GPLed programs.

A function call might go between GPL --> RGPL (1) ->RGPL (2) ->RGPL (3) RET -> RGPL (2) RET -> RGPL (1) RET->GPL.

That will allow for GPLed programs to communicate over the RGPL safely without any non-free software to get between (other than the RGPL if you don't consider it free.)

Mike

[ignatz]

This seems like it will just further extend and entrench the conflict over licensing, and not just between closed source software but also between the GPL and other licenses. I don't see that as productive. Making free and open software restrictive in terms of whom/what it can communicate with goes against the grain. Open-source's strength is that it is open. Play to your strengths.

()-()
 \"/
  `                                                     

[mdupont]

Yes I agree with you, but this is prevent the use of compiler modules in creating non-free extensions.

I have gotten into too many fights on the level of people in the gcc group worrying about my project allowing access to the parse trees and people making non-free backends to the gcc.

That is why I am proposing this, to find some middle ground in the free versus non-free debate.

Mike

[FoxtrotUniform]

Yes I agree with you, but this is prevent the use of compiler modules in creating non-free extensions.

The GPL is not the only "free software" license out there. As far as I can tell, your proposed RGPL prevents code under other free licenses (the Artistic License, for example, which includes all of my code; or the BSD License, which includes my operating system's code) from being used as input to RGPLed programs -- like gcc, if you get your way. Or would you like to fork the gcc development tree? This proposal protects the interests of the GPL, not of open-source software.

Never mind that this would seriously undermine the real-world influence of any GPLed tools to which it was applied.

Please tell me that I'm horribly misunderstanding your point.

--
The hell with paco, vote for Erudil!
:wq

[mdupont]

Also Remember that the GPL does not copyright the output of the program.

This is basically a hole in the gpl

mike

[kudra]

Also the perl core is GPled and is a target for this module.

Actually, "Perl may be copied only under the terms of either the Artistic License or the GNU General Public License..." The Artistic License is not the same as GPL (and it's funny you consider GPL to be left-wing...I think it's about as restrictive as open-source licenses get). Many modules are available "under the same terms and conditions of Perl itself", which means the choice for either license exists. I, and I imagine others, prefer to use Perl under the Artistic license. Because the Artistic license is an acceptable way of using Perl, I hope a module only available under GPL would be rejected for the core.

Also, don't forget programs distributed under other free licenses (such as the BSD license) You can't make these programs GPL licensed just by using them. Would these programs have to fall in the category of 'non-free software' just because they don't use the 'right' free license? If that's the case, consider just how little freedom a hard-line GPL only stance gives you if it forces you to reject free, open-source software available under other licenses.

Signs of restrictions can already be seen in section two, which prevents one form of GPL programs from using other GPL programs. (GPL software can only be used by users and linked to by other GPL programs, it can link to LGPL programs, but cannot link to RGPL programs, otherwise the RGP L program might be considered a derived work and fall under the GPL.)

Consider the Perl motto "There's more than one way to do it." It's as applicable to free software licensing as programming.

[mdupont]

First of all, The GPL does not cover the Dumping of code as data, it cannot the restrict the usage of the GCC via an XML interface. Therefore it is not that restrictive. The RGPL is just for that purpose.

Secondly, I can use the PERL under the GPL. Even if it is licensed, under the Artistic license.

BSD is a problem right now, because you cannot link BSD to GPL, and you cannot make BSD modules attached to the GCC.

The motivation for creating this library is to create a haven for free software tools to interact with the meta data of the compilers. Unless we protect that, it will be very difficult to get support of the compiler vendors for such a patch. Believe me!

I am well aware of issues, the RGPL provides the only solution to the issue protecting the AST dumps from the compilers.

Regards,

Mike

[Abigail-II]

BSD is a problem right now, because you cannot link BSD to GPL, and you cannot make BSD modules attached to the GCC

Well, as I've understood, that's GPL's problem, not BSD's problem. The BSD license is more free (the only true free software is public domain software) than the GPL.

I never write modules and release them under the GPL. I seldomly agree with Microsoft, but I do agree with their opinion that the GPL is a viral license. I prefer the use an MIT/X style license. I release code because I want to the code to be used, not because for political statementes, or because I want to enforce my ideas on the world.

I'm only a humble coder. I've consumed more code that I've given. Who am I to put restrictions on the code I release?

Abigail

[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.

[jryan]

Personally, I find this (and the GPL in general) to fly directly in the face of how I feel about free software. If I make a piece of software that I have written free from cost and open sourced, I honestly don't care whether its used in the core of a Microsoft operating system or printed out and used as toilet paper. Why is it that so many people seem to care more about the GPL license than the software under it? I feel that the the true objective of all software to be as useful as possible; open-sourcedness tends to maximize the potential of the software because an entire community supports and develops it. I feel that a restrictive license such as the GPL neuters this potential by limiting the use of the software.

One of the most beautiful things about Perl is its Artistic licsene that is about as open as you can get. Its a license that does not limit the usefulness of the language by limiting what it can be used for. If Perl were to fall under a liscene like the one you describe, I would abandon it in disgust.

[Anonymous Monk]

Again, please read my post. Perl cannot fall under this license!

This license is to solve a specific problem.

If anyone could do anything with the gcc, we would not have so many supported gcc backends, because the big companies would refuse to release the support for one chip or the other!

reread my posts and answers and then respond!

mike (not logged in)

[Anonymous Monk]

Just write a GPLed program whose output necessarily includes text that is under your copyright. That makes the output necessarily GPLed because it includes (and derives from) a GPLed source.

It does not force the input to be GPLed, but you cannot do that within the confines of existing copyright.

Side-benefit. You do not have to introduce Yet Another License.

[mdupont]

There is nothing stopping anyone from removing that under the gpl. :(

Anyone can just take out the GPLed code. mike

[Anonymous Monk]

It depends on what the nature of your program is.

If, among other things, your programmer inserts extensive pre-processor macros, then changing that behaviour may be impossible. Also note that if person A creates a document, B modifies it, then C makes modifications that (among other things) remove everything that B did - B still has copyright on the final result! (Copyright is a funny beast.)

Also note that if you try to implement a ton of restrictions beyond the simple approach that I just described, you will run afoul of the fact that your license is not even remotely compatible with the GPL. This is a Bad Idea.

For further discussion I suggest signing up for fsl-discuss. They are much better equipped to give you feedback than random Perl hackers.