Change ot topic, back to OVPL

[Alex Bligh]

Russ,

>  > > I also want to see the numbering of the CDDL preserved.  This makes
>  > > for fewer changebars and easier study and analysis.  I think I'm on
>  > > pretty safe ground to insist upon this particular change.
>  >
>  > The numbering HAS been preserved in its entirety, apart from the
>  > section 1, and the addition of 3.3.
>
> In other words, it HAS NOT been preserved in its entirety.  Sheesh,
> you're like one of my students saying "Well, I got it almost perfectly
> right; can't I get a perfect 100?"

You said you wanted the numbering preserved. I said we have preserved it
as far as is sensible, and explained why we hadn't. It can't be that hard.

>  > Section 1 has the majority of renumbering, and is the definitions
>  > section. As you are probably aware, it is normal for definitions to
>  > be in alphabetical order and consecutively numbered. Not doing so
>  > would make the OVPL much harder to read. In any case, anyone
>  > reading either license references the definitions by the defined
>  > term, and not by number. I hope you are not seriously suggesting we
>  > change this.
>
> I am dead serious, and I expect that most members of license-discuss
> will back me up.

I await their confirmatory emails. As I said, we are always ready
to listen to feedback. However, my priority is to make the license easy
to read (which includes comparability with the CDDL), not merely to make
it easily comparable with the CDDL.

> Like I said earlier, I can be persuaded that I am wrong if you can
> supply a lawyer's perspective that there is a legal need to make these
> small changes.  I can also be persuaded if you CONTACT the CDDL folks,
> and they REFUSE the improvements.  You've resisted doing this so
> strongly that if you assert that you have contacted them and they have
> refused, I'll feel it necessary to get the CDDL folks' side.

I have not resisted contacting the CDDL folks. I've exchanged emails from
people at Sun re the OVPL. I am polite enough not to repeat off-list emails
on-list.

Let me remind you the four drafting issues (marked "DI" in my previous
email) are:
* Change of name (to OVPL)
* Change of license steward (to OpenVendor.org)
* Revision of limitation of liability clause
* Revision of warranty disclaimer clause

I am pretty sure that the CDDL folks will not change the first two (this
is common sense), and I would not want them to.

The latter two ARE made from a legal perspective and we have already supplied
the reasons for them to this list - they are to do with non-enforceability
or voidness in certain jurisdiction. You will note that it's not only OVPL
folks who have made this comment, the OZPBL (name from memory) license had
similar problems with Australian jurisdiction and needed to modify another
license similarly. With respect to the liability limitation clause, Laurence
Rosen has made similar modifications to the OSL 3.0. I think we have done
a pretty thorough job in supplying them.

I therefore think we have satisfied what you have requested.
Nothwithstanding, I hereby (in public) REPEAT my previous public offer to the
CDDL folks - you are quite welcome to take these improvements (the
modifications to the limitation of liability clause and warranty disclaimer
clause). Because the OSI want me to, I shall go further, and ask that you do
take them, or at least refuse to take them.

> The principle I am pursuing here is that a section of a license which
> is intended to be taken the same should be EXACTLY the same.  Word for
> word, number for number.  Whitespace I'll give you for free.

They are NOT meant to be the same. The changes are meant to make the license
operate effectively in more jurisdictions than the CDDL. Perhaps I should
have avoided calling them "drafting improvements" and called them "a
fundamental change" - notwithstanding, these clauses do what I feel the CDDL
clauses were meant to do, but do them in other jurisdictions as well (or
rather make it clearer what will happen in jurisdictions with statutory
regulation of exemption and liability limitation clauses).

>  > In any case, as above, there is no OSD requirement that the numbering
>  > of one license should match the numbering of a predecessor, so no,
>  > you are not on safe ground to insist on this particular change. The
>  > criterion for approval is whether it meets the OSD.
>
> No, we've always felt free to reject licenses which are not in the
> best interest of the open source community.

Against what criteria to you judge that?

> Unfortunately, I'm headed off to the NY state fair for five days, so I
> cannot give your email the proper respect it deserves.  I'm sending
> this off as-is to give you a chance to start revising the OVPL as I
> recommend.  If you choose not to revise it, and insist that I put it
> before the board, I will do so with a "Recommend: rejection" header.
> If the board sends it back to you for revision, and you decline to
> revise it, you can re-submit it on an as-is basis and I will submit it
> to the board again with a Recommend: approval header.  It will take
> months and months for this process and in the end, you will be hurting
> the open source community.

If you wish to recommend rejection knowing the above, or having not
read the above, that is your prerogative.

Alex