Compatibility metalicense, huh?

[Henning Makholm <henning@makholm.net>]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> But I invite everyone to implement a copyright construction kit, a Gtk app,
> which lets you build your copyright by Drag'n'Drop. A small portion on
> freeness, of copyleft, a but of restricted warranty and a non-commercial
> clause :)

This was probably meant as a joke, but I think seriously that
something like that may be the best long-term response to the
license compatibility problem.

As I see it, when two licenses are incompatible, it is commonly the
fault of both: neither one allow derived works to be distributed under
anything but the exact same license statement.

So far the only real alternative to that seems to have been to make no
requirements at all about the possible conditions for distributing
derived works. That is the way public-domain, BSD et at. work. Many
people find that this provides too little protection against being
used in proprietary products. So they end up with using free licenses
that turn out to be incompatible with anything but themselves. GPL is
one example of that, but by no means the only one.

What we need is a way to write a license that expresses what the
author thinks should limit what deriviators can do, leaving it to
downstream users to 'fill in the blanks'.

If everyone used the same text snippets we could have two libraries
with quite different terms which nevertheless both allowed enough
clauses to be added that we could determine a "least strict
combination" license that one could distribute a combination under.

E.g. point 42 of a license could be one of

42A. No money must change hands when distributing the program.

42B. You can charge money for distributing the program.

42C. You can charge money for distributing the program. If you
     make a deriviative work you have the option of replace
     this clause with clause 42A or clause 42B.

and point 43 could be one of

43A. If you make modifications you have to distribute them as
     patches.

43B. Feel free to distribute modified source without further ado.

43C. Feel free to distribute modified source without further ado.
     If you make a deriviative work you have the option of replacing
     this clause with clause 43A or clause 43B.

So a library with a licence saying {...,42B,43C,...} could be combined
with source code whose license said {...,42C,43B,...} and the final
program could be distributed under terms {...,42B,43B,...}.

Note that 42A is not DFSG-free. The "license generator" should allow the
author to produce a non-free license. Some people have pure enough
ideals that they do not want to see money change hands over their
code. If I write a library and care more about easing the lives of
other programmers than pushing some RMSish agenda, I'd like to
license my library so it can be used in free software as well as
by profitophobic purists. So I can choose 42C.

Choosing terms would be a tradeoff between "protection" and "flexibility",
but it already is today.

Of course this would only *really* promote license compatibity if
everyone used the same "clause library". Therefore it is important
that the choices are varied enough that everyone *can* use the scheme
without being forced to say something they don't mean.

Ideally, there should be enough knobs to turn to make license with
the same substance as every currently used formula. E.g., one
onfiguration of the license should yield precisely the same
combination of protection and flexibility as the GPL gives. Then
we could lobby the FSF to publish that configuration as version 3
of the GPL. Instantly it would be really easy to produce libraries
that were GPL compatible without constraining all *other* users of
the library to the choices of GPL.


Am I making myself clear? Probably not...

-- 
Henning Makholm