Change ot topic, back to OVPL

[Alex Bligh]

--On 30 August 2005 15:45 -0400 Russell Nelson <nelson at crynwr.com> wrote:

> I've spoken to some people from large enterprises.  They're getting
> tired of all these licenses, and at some point they're going to put
> their foot down and say "Okay, that's it!  If you want us to use your
> software, you'd better use a license we've already approved, because
> frankly, your software isn't worth its license."

<OVPL hat off, asbestos suit on>

This (it seems to me) is the least important reason to prevent license
proliferation. People from "large enterprises" have the resources to
evaluate licenses, and bargain for changes. The same problem exists
for large enterprises with shrink-wrapped licenses. Open-source is
already ahead. What you are saying here is (effectively) some licenses
are better than others. Well, if so, let them fight it out. Let's see
which one wins. Same principle as open-source software itself. We don't
need an OSI-type body to give imprimatur to one license over another.

A much better reason to avoid license proliferation is license
incompatibility. By that I mean two differently drafted licenses, A and
B, which functionally do almost the same thing. But if code A1 is licensed
under A, and code B1 is licensed under B, the terms of A and B prevent the
use of the code together. *THIS* is what why need some coordination from
OSI etc - so we maximise code reuse.

Equally, we need to have commonality of license terms. When the word
"distribution" is used (or any other terms) it should ideally mean the
same in each approved license, and moreover we should avoid replicating
faults in license-framing between different licensing. Just as we learn
from coding design mistakes (strcpy), we should do the same at a license
level.

The above is precisely why the OSI needs to be far more intelligent than it
has thus far seems to have been on the issue of proliferation. We should
be looking at promoting qualitative improvements in licenses, and maximising
sharing of license knowledge, not preventing license innovation. If you
substitute "text of license" with "text of program" and apply open source
principles, the mistake becomes self-evident.

Alex