Messages in this thread |  | | | Date | Mon, 13 Jul 1998 16:34:40 -0700 (PDT) | | From | "Jon M. Taylor" <> | | Subject | FreeGPL license proposal (was Re: Linus Speaks About KDE-Bashing) |
| |
On Mon, 13 Jul 1998, Kristian Koehntopp wrote:
> In netuse.lists.linux-kernel you write: > >just FYI: you're collecting more and more points why I personally > >don't like GPL anymore and probably won't use it in the future for > >some sort of projects.
I'm starting to feel the same way. The GPL now appears to have too much baggage and to be too poorly worded to continue using it. It is choking the practicality out of itself.
> The GPL was designed in the age of static linking and before > object orientation (read: linking to foreign code via names > instead of addresses) became popular. > > Dynamic linking, which is just like loading, which is allowed by > the GPL or no GPL program would ever run on propietary OSes, > does not fit well into the model of the GPL. > > Making two pieces of software work together as an integral > system via message passing does not fit into the GPL model at > all. That was why the GPL failed to infect the entire Beos. Now, > just think of a Qt server communicating with a KDE app or Kimp > by message passing or a Qt being part of the X server, an X > extension. The GPL does not handle this at all. > > Via object orientation you can build upon GPLed work without > modifying the GPL source at all. Your classes simply inherit and > overwrite the GPL base classes, but this is different source and > the GPL source is left absolutely intact and unmodified - you > only refer to it by name. The clearly is a violation of the > spirit of the GPL, but the GPL does not handle this at all. > > The GPL is about 5 to 8 years behind the current design in > operating systems and applications and does not cope well with > common situations encountered in modern environments.
It does not cope well because it is fundamentally conflicted. The GPL puts restrictions on both what you can do with the source and what you can do with the resulting binary. The source part is clean, simple, easily interpreted and pretty much technology-independent. The binary part is a chaotic mess of special cases, vague generalizations, and technology-dependent definitions.
The first part works, the second is falling down in a heap around us. The fact that the LGPL had to be written (and that it STILL hasn't solved the conflicts) indicates the fundamental unworkableness of the second part. The anti-capitalist, anti-intellectual property, and "GPL virus" parts of the GPL are beginning to impose practical, rather than moral or philosophical, restrictions on people's ability to choose the GPL for their code's license, and IMHO that means that they have to go. Concerns about money and commercial vs. noncommercial software, as well as issues of the use to which the software is put, should be completely orthogonal to the issue of maintaining a free codebase that will stay free and modifiable. If people want to impose thse sorts of restrictions, they can write up their own licenses.
I didn't get involved with the free software/open source community to play bullshit political games, to have to care about or even know who uses my software when and how, or to wage war on the concepts of intellectual property or capitalism. Most of all, I did NOT come here to have to deal with lawyers!!! I suspect *most* of us (hint, hint) didn't come here to do these things either. We came here to code up software that people could use, modify, and redistribute, right? Are we doing that now? No, we are arguing about the minutiae of the GPL, dividing ourselves, scaring people away from free software and making the whole process a PITA rather than fun.
So who's up for creating a "FreeGPL" license, extra-capitalistic rather than anti-capitalistic in spirit? A license where "share the software" really means something? A license that returns to the principle of promoting code reuse and ceasing having to reinvent the wheel? A license that accepts people into the community rather than turning them away? A license that combines the best parts of the GPL (keeps the code freely distributable and modifiable for all time) and BSD (doesn't impose restrictions on the use of the software) licenses? A license that is clear, unambigous, small, simple and easy to interpret? Maybe this would heal the current divisions in the open source world, and as a bonus would create a license that doesn't have loopholes the size of Nebraska and doesn't require an army of lawyers to interpret.
(Don't say "why don't you just use the BSD license", either. The BSD license doesn't preserve unto eternity the freeness of the source, which is vitally important and is the one really good and necessary part of the GPL.)
Here's a first stab at it, in english rather than formal legalese:
* The only language in the license will deal with allowable and non-allowable behavior. No preambles full of philosophical meanderings, no "this is what we mean by this", etc. If the license requires these sorts of things be present, it is too complex or badly worded.
* A liability or usefulness disclaimer a la GPL.
* You can make whatever use you want with the binaries and/or the source. The license will specifically not have anything to say about "dependencies", "system libraries", linking, commercial vs. non-commercial use, etc.
* You are NOT required to distribute the sources with binaries (or binaries with sources), nor are you required to provide pointers to where people can obtain the latest versions of either the source or the binaries, nor are you required to provide documentation or explanatory material beyond the text of the license.
* The original author(s) retain(s) copyright and his/her name(s) must remain attached to any binaries and displayed in the same manner as the other copyrights of the rest of the software are (if there are laws about this, they'd have to be followed too or instead of this provision)
* You cannot put any restrictions on modification or redistribution of the source or binaries (with one exception, see below).
* Source and/or binaries do not "infect" in the GPL sense, and can be freely mixed with non-FreeGPLed source and/or binaries, but the copyright, modifiability and redistributability of the source and/or binaries must remain. This would mean that you are allowed to chop up FreeGPLed sources and mix them in with nonfree sources, but if you rip out, say, five FreeGPLed source blocks and stick them in random places in your code, each block must have a copyright and license notification attached to it. The only exception to this would be that if you mix FreeGPLed and nonfree sources, you are allowed to restrict the modification and redistribution of the resulting binary due to the impossibility of separating out the different code blocks when they are compiled. This exception does not in any way detract from the freeness of the origianl source, which is all that really matters anyway.
That's it. Clear, simple, unambiguous (It's even simpler than the above, because half the above describes what WON'T be present in the text of the license!). It preserves copyright, preserves redistributability, preserves the freedom of the source, allows people to use the source and binaries however they want provided they properly credit the authors, and doesn't play any "infection" games or try to impose a certain moral viewpoint on people beyond that which is implied by the text of the license itself.
What do you all think? I think it is good engineering - it follows the KISS principle as closely as possible, which the GPL does NOT. It is a very libertarian license - have only the minimal amount of rules necessary to keep the system coherent, functional and true to its principles. If I get enough people saying they like it, the next step is to present it to the public via Slashdot.org, setup a mailing list, etc.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
|  |