FreeGPL license proposal (was Re: Linus Speaks About KDE-Bashing)

Jon M. Taylor (taylorj@ecs.csus.edu)
Mon, 13 Jul 1998 16:34:40 -0700 (PDT)


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