Subject: Thoughts on approval process and license proliferation
From: "Chris Travers" <chris.travers@gmail.com>
Date: Fri, 7 Sep 2007 10:53:04 -0700
Fri, 7 Sep 2007 10:53:04 -0700
Hi all;

FIrst since I am still somewhat new here, I don't know if this is something
better to discuss on the license-proliferation list, but since it is closely
related to the approval process, I figured I would submit here.

I think that the approval process may need some restructuring to deal with
license proliferation issues.  Obviously the 2005 guidelines are not being
used in the approval process itself, so we may want to look at other ways of
structuring the approval process and license list so that  we have a) fewer
entries and b) the entries we do have are more useful.

My suggestion is that we change things in the following way:
1)  Differentiate between "new licenses" we are approving, "new versions of
licenses which cause older versions to be deprecated (as in the MPL 1.1, but
not the GPL3)," and "variations on approved licenses."  For example, the
X.org license might be approved as a variation on the MIT license rather
than a license itself.

2)  Consolidate existing list entries in the following way:
Approved License

Approved Variations

Older deprecated versions


My suggested guidelines for each category are:
1)  New licenses must be legally different from other licenses and not
merely variations on others.  It is fair to ask the submitting body how the
license is different from those already approved.
2)  Variations must be different in some ways, at least in the opinion of
the legal counsel for the submitter.  We should be willing to ask what
differences these have.  (In this case, MS-PL and MS-CL might have been
submitted as a new license plus a variant on that license).
3)  New versions must be structurally similar to the older license, and
represent incrimental changes.  Large and incompatible changes, such as
between the GPL2 and GPL3, should mean submission in the new license
category.

Note that this is likely to add a requirement of having the sponsoring
organization actually have legal counsel available to answer questions on
the list if the answers to the question of categorization and
differentiation are not obvious.  Thus for Microsoft or the FSF to have
their licenses approved their lawyers would need to be available to answer
questions.  THis would raise the bar for creation of licenses and help slow
down license proliferation, and it would also help clarify licenses as they
are being approved.  Seems like a win for everyone.

Best Wishes,
Chris Travers


Hi all;

FIrst since I am still somewhat new here, I don't know if this is something better to discuss on the license-proliferation list, but since it is closely related to the approval process, I figured I would submit here.

I think that the approval process may need some restructuring to deal with license proliferation issues.  Obviously the 2005 guidelines are not being used in the approval process itself, so we may want to look at other ways of structuring the approval process and license list so that  we have a) fewer entries and b) the entries we do have are more useful.

My suggestion is that we change things in the following way:
1)  Differentiate between "new licenses" we are approving, "new versions of licenses which cause older versions to be deprecated (as in the MPL 1.1, but not the GPL3)," and "variations on approved licenses."  For example, the X.org license might be approved as a variation on the MIT license rather than a license itself.

2)  Consolidate existing list entries in the following way:
Approved License

Approved Variations

Older deprecated versions


My suggested guidelines for each category are:
1)  New licenses must be legally different from other licenses and not merely variations on others.  It is fair to ask the submitting body how the license is different from those already approved.
2)  Variations must be different in some ways, at least in the opinion of the legal counsel for the submitter.  We should be willing to ask what differences these have.  (In this case, MS-PL and MS-CL might have been submitted as a new license plus a variant on that license).
3)  New versions must be structurally similar to the older license, and represent incrimental changes.  Large and incompatible changes, such as between the GPL2 and GPL3, should mean submission in the new license category.

Note that this is likely to add a requirement of having the sponsoring organization actually have legal counsel available to answer questions on the list if the answers to the question of categorization and differentiation are not obvious.  Thus for Microsoft or the FSF to have their licenses approved their lawyers would need to be available to answer questions.  THis would raise the bar for creation of licenses and help slow down license proliferation, and it would also help clarify licenses as they are being approved.  Seems like a win for everyone.

Best Wishes,
Chris Travers