Proposal: criteria for license approval

[Ian Lance Taylor]

Alex Bligh <alex at alex.org.uk> writes:

> a) Applications for license approval should be processed by the OSI board
>    in a timely manner (with allowance for the fact it is a volunteer board),
>    against the criteria listed in the OSD and the published license approval
>    process ONLY. Evaluation should take into account community postings
>    to license-discuss, to the extent that they demonstrate conformance
>    or otherwise with these criteria. After evaluation, applications should
>    be told whether their license is approved, or whether it has been
>    rejected (and if so what criteria it breaches and why). Where rejection
>    is for a minor reason that would be remedied by an obvious drafting
>    change, the words of this drafting change should be passed on.

I believe that there is an argument for the OSI to put its seal of
approval only on licenses which are good for the open source
community.  I've raised this issue before in other contexts, and I've
generally argued that the OSI should not just blindly approve licenses
which meet the requirements of the OSD, but should consider whether
those licenses will help or hurt the community.

For example, there was a proposal a year or two ago for a license
which was like the BSD license but specifically prohibited
distributing executables which contained code both under the new
license and under the GPL.  That is, it was an anti-GPL license.  I
argued that although the license obeyed the OSD, it should not be
approved because it was divisive and harmful.  Many other people
argued as you do above, that the OSL should simply stick strictly to
the OSD (in fact I don't remember whether anybody else agreed with me
at all).  The proposed license was eventually withdrawn, though not
because of my criticisms.


I do want to distinguish my position--that the OSI should consider the
good of the community--from the license proliferation issue.  I think
that license proliferation is not a good idea, but I don't think it is
particularly harmful to the community.  People who are seriously
interested in working with the open source community will pick one of
the very few generally accepted licenses--GPL, BSD, MPL, perhaps now
CDDL, AFL, OSL.  Picking a different license--particularly an
incompatible license--will put the package into its own little world,
separate from the larger open source world.  While that is not as
helpful as possible to the larger open source community, it is also
not harmful, at least not any more than the release of a new
proprietary software package is harmful.

It is a very rare software package which is so powerful and so useful
than it can overcome the hurdle of an unusual license.  The most
obvious example of such a package is Mozilla, which was sufficiently
useful that it forced its license to be generally acceptable.  An less
extraordinary software package under an unusual license is simply
doomed to be left behind--it will perhaps included in distros, but it
will not attract wide attention or contributions, or be integrated
into other packages.

I think it is appropriate for the OSI to help explain these facts to
people who are new to the open source community.  So I think the
decision to put forth a set of recommended licenses is a good one.

It is possible in principle for a new license to be sufficiently
interesting that people will adopt it in preference to the existing
licenses because of new features that it has, even if it is not
attached to any interesting software.  The only cases so far where I
think this may actually happen are the AFL and the OSL.  Perhaps it
could happen with the OVPL, but, truthfully, I doubt it.

All that said, I do think that the OSI should routinely approve
licenses which follow the OSD and are not harmful to the community.  I
personally think the OVPL may be a rather interesting case because it
may follow the OSD and yet not be a free software license in the eyes
of the FSF, because it is right on the edge of the freedom to keep
your changes private, and to not be required to notify anyone in
particular about your changes.  But the license may not in fact
abrogate the freedom, and I don't see that freedom captured anywhere
in the OSD as it stands today.


To sum up, I don't agree with your proposal (a).  But I also think
that a license like the OVPL should be approved or rejected purely on
whether it obeys the OSD.  I do agree with your proposals (b) and
(c).

Ian