Pre-existing purpose and value vs Adminstrative rules

[Forrest J. Cavalier III]

(BTW, the 3 criteria are no longer at the opensource.org where they used
to be, I had to dig them out of Russ's email from 3/2/2005....)  Steve M,
can you fix this?

"ESR" referred to them "new criteria" and recently as not part
of the OSD because they are "adminstrative, not philosophical."

But in my new understanding of what the OSI board did, I think they are
not new, and they should be expressed philosophically.

These can be written as formalized expressions of principles of purpose
and value that pre-existed 3/2/2005, indeed pre-existed before there
was an OSI.  The first person who was NOT from MIT or Berkeley which
used the MIT or BSD license understood these principles.

With effort, I can understand how this thing blew up.  Everyone on the
OSI board is busy.  Busy people like to adopt adminstrative rules instead
of explaining it all to the troops.  Understandable, but that is a big no-no of
good modern management, and nearly a cardinal sin in volunteer organizations...
unless there is a crisis.  (And this proliferation is hardly a crisis.)

So, backing up for a fresh start, I think the 3 criteria might belong in the OSD
after all, provided that the philosophy behind them was explained (so that people
can see they are not "new", and the unnecessary and redundant "OSI has the power
to declare compliance" sentences are removed or made non-normative notes.  That
will give a clarity to the criteria which make them much easier to apply.

I won't say I am very good at this, but I'll take a quick stab to show you what I mean.
(I'm sure it will get rewritten, butchered, etc.)

 > 11. *The license must not be duplicative.*  That is, it is up to the
 >     submitter to demonstrate that the license solves a problem not
 >    sufficiently addressed by an existing certified license.  Certification
 >    may be denied to any submitted license, even a technically OSD-
 >    conformant license, if OSI deems it duplicative.

My suggestion, subsume 13 into 11, and rewrite it to be philosophical,
not adminstrative like this:

11. *Licenses submitted for approval must not be duplicative and must be reusable.*

     A new license requires the effort of review for OSI certification, but then also effort for
     review by every potential user and contributor.  This will slow the benefits
     of quick adoption and wide usage of software under any new and different license.

     Therefore, submittors must demonstrate that their license solves a problem
     not sufficiently addressed by an existing certified license when used in
     the environment of liability, copyright, trademark, and patent law.

     Also, if the license contains proper names of individuals, associations, or
     projects, these must be incorporated by reference from an attachment that
     declares the names of the issuer and any other cited parties, and which can be
     modified without changing the terms of the license.  The license should name
     its owner and steward.

     Non-normative note:
     It is possible that an author wants to use a license that is otherwise
     compliant with the OSD except for this criterion, and just wants to be
     different.  That's fine for them, but the OSI certified mark means that
     OSI agrees that the license provides benefits to a community, not just a few
     individuals.

     They are welcome to proceed to use their license, but must not indicate
     it is OSI certified, or complies with the OSD.

 > 12. *The license must be clearly written, simple, and understandable.*
 >     Open-source licenses are written to serve people who are not
 >     attorneys, and they need to be comprehensible by people who are
 >     not attorneys.  OSI may deny certification to licenses which,
 >     though technically correct and OSD-compliant, are so obscure
 >     and complicated that an intelligent layperson cannot be assured
 >     of knowing his or her rights and liabilities after reading it.
 >     The burden of engineering this clarity falls on the submitter.


   12. *Licenses submitted for approval must be clearly written, simple, and understandable.*
       Open-source licenses must be written to be read by people who are and
       who are not attorneys.

       The OSI will not certify newly submitted licenses which are obscure and complicated.
       Using software under license is ubiquitous now, and an intelligent layperson must
       have reasonable certainty of knowing the rights and liabilities conveyed by using
       software under license.  That cannot easily happen with obscure and complicated licenses.

       Non-normative notes:

       The burden of engineering this clarity falls on the submitter, who
       is expected to have used the advice of competant counsel to draft the
       license.  It is too easy to make a simple wording mistake with unintended
       consequences.

       It is possible that an author wants to use a license that is otherwise
       compliant with the OSD except for this criteria, and that due to
       real complications in certain jurisdictions there is no way to make the
       language less complicated or shorten the license. That's unfortunate, but the OSI
       certified mark means that OSI agrees the license will not surprise an
       intelligent layman with unintended obligations, or liabilities due to
       ambiguous language that can lead to litigation.

       They are welcome to proceed to use their license, but must not indicate
       it is OSI certified, or complies with the OSD.

       Non-normative note:
       Bruce Perens 4/25/2005 in "Build Bright Lines" to license-discuss

       Not all licenses certified here are stellar examples of clarity, but in
       general we should strive for licenses that establish really bright lines
       rather than fuzzy ones that people argue about. Our clientele doesn't
       have the best access to counsel, and thus it is our obligation to make
       things unambiguous for them.

 > 13. *The license must be reusable*.  If the license contains proper
 >     names of individuals, associations, or projects, these must be
 >     incorporated by reference from an attachment that declares the
 >     names of the issuer and any other cited parties, and which can be
 >     modified without changing the terms of the license.  As the sole
 >     exception, the license may name its owner and steward.

I have subsumed this 13 into 11 above.