OT: Permissive license proliferation

[Donovan Hawkins]

On Sat, 8 Sep 2007, Chuck Swiger wrote:

> However, all of these variants are simple, permissive licenses which are 
> compatible with each other and all (or pretty much all) of the OSI-approved 
> licenses, so this type of license proliferation doesn't seem to be doing any 
> real harm in the way that having less permissive licenses interact might.

Except it requires a legal opinion to decide whether each of these custom 
licenses is compatible, to say nothing of the implicit patent grants that 
are used by most of the permissive licenses. You have to read every 
license to see what word they changed, make sure it causes no problems, 
and add up all the little unique requirements that each one added slightly 
differently:

"Hmm, so my change list has to be prominent, reasonable, standard, 
complete, in each changed file, and in its own file. I have to put a 
complete copy of the license in each file, with my license, it its own 
file, and I have to offer a copy to anyone who asks me because apparently 
they can't use one of the 137 copies I gave them."

Obviously most open source projects don't do this, and they rely on the 
fact that no one will come after them as long as they follow the spirit of 
the licenses. Most businesses will be wary of being so loose with the 
interpretations, and since they are one of the intended users of 
permissive licenses I think we could do something to make things easier 
for them to be compliant. Even some open-source developers (myself 
included) would be more inclined to make use of other projects if the 
license issue were straightened out explictly.

To be honest, I think the problem with the BSDL is that it is TOO simple. 
People can understand it so readily that they don't even hesitate to start 
tinkering with it and making a new license. A certain minimum of 
complexity is probably better if you want a license to retain its 
integrity without repeated alterations. Provide a simple English 
explaination (similar to what Creative Commons does) and let the license 
itself be explicit and in the legal language that it requires.

Ideally we would have a single license with modular terms that can be 
recommended as the preferred permissive license and grow to be the defacto 
standard (much as GPL has done in the copyleft arena); that would also 
help protect the license from needless alterations.


I mentioned this "modular license" idea in an earlier thread, and since 
then I've been trying to put one together myself. I was planning to wait 
until I had a first draft to say anything, but this seems like a good 
time. I don't think for a second that I'm the best choice to do it, but I 
haven't seen anyone else willing to try. The worst that will happen is 
that everyone will say it isn't good enough and I'll toss it in the trash, 
but I think it's worth a shot. I realize that OSI tried to help with their 
AFL and that didn't work, but I think the problem is that people have a 
lot of different ideas about what a permissive license should permit. A 
modular license which gives "constrained options" could satisfy far more 
people and have a shot at gaining critical mass.

I changed the topic to a different thread so people can offer their 
suggestions for what the license would need to do to have a chance of 
success. I realize this is a bit OT but there has been a lot of discussion 
about license proliferation and this seems like something that could 
actually be done about it. Here are some of the design goals/features I've 
been including:


Priorities (topmost is highest):

   Protect the author from liability.

   Grant unrestricted use and personal modification.

   Protect author attribution.

   Grant distribution (especially under other open-source licenses).

   Avoid artificial restrictions that affect developers (ie, keep coding 
seperate from licensing).

   Protect other author requirements.

Obviously several of these are absolute so it may seem odd to prioritize, 
but it gives a sense of what I'm aiming for and how strict or loose 
various clauses may be. I think the priorities are appropriate for a 
permissive license which is not trying to control reuse like a copyleft 
license would.


Grants of rights should be terse and general to be interpretted broadly.
Restrictions of rights should be verbose and specific to be interpretted 
narrowly. I'm still debating whether to include the usual litany of "use, 
modify, deal in, copy, possess, install, run, fold, spindle, mutilate" 
under an "includes but is not limited to" or whether to leave it simple.

Treat restrictions as limitations of license scope. This is the FSF's "a 
license is not a contract" interpretation used by the GPL. At worst it 
will be ignored by courts, but I don't see any downsides for trying.

Use a disclaimer which is as complete a combination of existing 
disclaimers as possible. There's no harm in being redundant here, and it 
might discourage some people from "rolling their own" just because they 
believe certain magic words MUST be present. Perception is important here.

Be explicit in rights grants, not implicit. Again, perception is important 
and there is no harm in comforting those who do not trust the untested 
legal opinions floating about the Net.

Include a specific clause indicating the intention to be compatible with 
downstream licensing under other open-source licenses such as GPL.

No mention of venue or reliance on a specific country's legal system.

Accept that no license can be "all things to all people" and try to focus 
on the majority of users. Do not attempt to be a simple English license 
and do not attempt to drown the reader in legalese and definitions. A 
middle road which appeals to most people is appropriate.


Rights currently granted in the "default" license:

   Use with or without modification.

   Distribute with or without modification (except as noted).

   Use name/trademarks soley to identify the item to which they normally 
refer (ie not the derived works).

   License for all patents used in the program.

   Fair use and moral rights not affected.


Always required to maintain legal notices, disclaimer, and a web link to 
the license.

Optional restrictions (each uses a unique designator and licensing a new 
project under this license is as simple as adding the restriction lists 
from all programs you used):

   Maintain an additional disclaimer.

   Include a change list.

   Add a change notice to each file changed.

   Maintain a full copy of the license.

   Maintain a warning of any third-party patents that may apply (useful for 
projects like libdvdcss and LAME).

   Require legal notices when the program is executed.

   Program name must be changed for modified versions.

   Names/trademarks may not be used in advertising.

   Maintain "exhibit A" (license notice in each file).


Additional permissions are implemented as extra clauses not part of the 
license itself, but I was planning to include standard text for some 
common ones:

   Ability to distribute without restrictions as long as no mention of the 
original authors is made whatsoever (if done in binary form only this 
would be equivalent to a term in the Boost License).

   Linkage exceptions.

   Explicitly allow use of names/trademarks in advertising (since omitting 
the explicit restriction doesn't necessarily grant you this right).


Additional items I'm still mulling over:

   Requirement to distribute only in patch form (seems a bit too 
restrictive and of limited use...I think only used by few projects who are 
really gung-ho about protecting their project integrity).

   CodeSynthesis XSD has a very interesting scheme which allows limited 
licensing under ANY free software license (they chose FSF over OSI but it 
could be made more general). This could be available as an additional 
permission, though I suspect few would be so brave as to use it.


This list may seem huge but it's actually not that large: the terms and 
conditions (does not include the additional permissions) takes about 3 
screens on my PC (approximately 80 columns wide and 70 lines high). For 
comparision, GPL v3 terms and conditions takes 8 screens in the same 
format.

Suggestions are welcome. I'm sorry if this is too OT for license-discuss, 
but I really would like to hear your opinions on this.


Almost forgot, the name of the license is going to be CMPLT (Cephira 
Modular Public License Template). It can be read as "complete", although I 
can't help but read it as the "compare less-than" assembly op-code. The 
license is completely name-neutral, but I do want to keep a unique word in 
the name to help protect it from possible confusing name-alikes.

---------------------------------------------------------------------------
Donovan Hawkins, PhD                 "The study of physics will always be
Software Engineer                     safer than biology, for while the
hawkins at cephira.com                   hazards of physics drop off as 1/r^2,
http://www.cephira.com                biological ones grow exponentially."
---------------------------------------------------------------------------