OVPL and the OSI Board on Thursday

[Alex Bligh]

Russ,

--On 19 August 2005 13:47 -0400 Russell Nelson <nelson at crynwr.com> wrote:

> It's approvable as far as I can see.

I'm glad about that.

> However we also have license
> proliferation issues to worry about.  The OVPL is derived from the
> CDDL.  As a derivative work, it makes two types of changes:
> improvements to the CDDL, and semantic changes necessary to achieve
> the desired ends.

I agree.

> I think that mixing those two changes is a bad idea.
>
> In the software realm, patches that fix too much code are difficult to
> understand and manager of the software is reluctant to apply them.
> The people who wrote the CDDL are neither stranger nor strangers.  I
> think that the changes from the CDDL to the OVPL are genuinely
> improvements to the CDDL.  They should not go into the OVPL, but
> instead into the CDDL.
>
> The semantic changes (which I agree are necessary to achieve the
> stated ends) should also slot cleanly into the CDDL.  No renumbering
> terms with identical text.
>
> This is just my opinion, and I can be talked out of it.  One way to do
> that is to tell me that I don't understand the law, and there are
> legal reasons why my suggestions cannot be adopted.  Another way would
> be to show that you've tried to work with the CDDL folks and they've
> been uncooperative.

Well, first thing, the email to which you replied was from David Barrett,
and though David B seems a keen user, it's not him who is asking for
approval specifically, it's me and David Ryan. So if he hasn't talked to
the CDDL folks, that's not his problem!

On the main point, I have talked to the CDDL folks, firstly out of courtesy
as we were using their license. They have been far from uncooperative.
However, they are trying to do something fundamentally different.

We've made it quite clear we would be more than happy for them to retrofit
any changes we made into the CDDL (or indeed anyone else to take anything
from our license and use it anywhere else, just so long as they don't call
it OVPL etc.). However, in practical terms, what they want the CDDL to do
is different from what we want the OVPL - they are licenses with different
objectives. So whilst I can see them taking (for instance) some of the
changes to the liability limitation and warranty clauses, it's most
unlikely they would want to take the additional ID license-back clauses,
because that's not what they want in the CDDL.

For the record, I will state that in the unlikely event that the
CDDL folks want to incorporate similar license-back provisions into the
CDDL, I will withdraw the OVPL from the approval process, because
I'm sure we could reach agreement on getting all the other stuff in
in a satisfactory form. But NOTHING I've heard from the CDDL folks
indicates that they are interested in doing that.

So there's a need for an additional license ANYWAY. Nothing does what the
OVPL does (like it or loathe it) in terms of the ID license-back, apart
from the QPL (which is deprecated and clearly unsuitable for a number of
reasons). So (assuming the OVPL meets the OSD as I think it does) it
fulfils a unique need and thus is not duplicative.

I would certainly like to see it closer to the CDDL (i.e. have the CDDL
folks incorporate some changes - we don't really want to back changes out
as we feel they are necessary but perhaps the CDDL folks disagree) - not
least as it would be easier to explain a smaller set of differences.
However, if this doesn't happen, I don't see it's a reason not to approve
the OVPL (for reasons of preventing license proliferation). Because even if
all the "drafting" changes were incorporated into the CDDL, there would
STILL need to be two licenses.

Moreover, if they are reasonably happy with the CDDL, I would entirely
sympathize with them not wanting to have a CDDL 1.0 and a CDDL 1.1
hanging around which are in essence different only to the degree of
drafting changes. If anything, *that's* unnecessary proliferation.

I will also undertake that if the CDDL folks do perform a retrofit of any
"drafting" changes, I will keep the diff up to date (i.e. make it shrink).
However, if you look through, I think you will find that this element of
the changes is actually the smaller, because we have been very reluctant to
make changes for the sake of it (and consequently rejected a number of
proposed drafting 'improvements' that were not 100% necessary).

Alex