OVPL and the OSI Board on Thursday

[Alex Bligh]

Russ,

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

> Alex Bligh writes:
>  > 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.
>
> You are writing the OVPL from your perspective: you want the best
> license for yourself.  Perfectly understandable.  We, on the other
> hand, have a responsibility to more people than just yourself.
...
> At some point, they're going to put their foot down and say "Here is
> our list of licenses.  If you want us to use your software, you will
> use one of these licenses."  If we continue to increase the number of
> approved licenses, they WILL do this.

With respect, I don't think that's actually true. It's quite true that I
started the LOOKING at the license problem with one particular client in
mind. However, it took only one post to this list to find other people who
wanted to do similar things, and that's why OVPL was started. The license
has been written as a GENERAL license for those who want ID license-back,.
That isn't just me. That's why it's templated, multi-jurisdiction, has the
OVLPL variant etc. Had I wanted to write a license "just for my client" it
would have been a lot easier, and I probably wouldn't even bother trying
for OSI approval with the views on license proliferation.

You are correct that it is written "only" with the type of ID in mind who
wants license-back. But, if they didn't want license-back, I'd tell them
"I'm not going to write a license for you, go look at the wide choice
available already". IE that's a circular argument.

>  > 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.
>
> No, not at all.  Both the OVPL and CDDL have a "successor" clause
> which allows users to relicense under a later version.  So, somebody
> concerned about the cost and difficulty of license reviewing could
> review the simpler CDDL 1.1 and OVPL 1.1 (which incorporates the CDDL
> 1.1 changes), and relicense any incoming 1.0 code under the 1.1
> versions.

Unless any ID had used the "version 1.0 only" prohibition on version
rolling that's available in both licenses, yes.

>
>  > 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).
>
> Good.  I'll suspend your approval request until we hear back from you
> on the results of this process.  Or, you can split out the CDDL
> improvements from the OVPL changes, and submit the latter.  The CDDL
> changes can be made later.

I'm not asking for the approval request to be suspended. My request
for the board to consider the license remains.

I said I'd keep the diff up to date (subsequent to approval).

Moreover, by "drafting improvements" I meant things that were necessary
(because we discarded the unnecessary ones) that were not to do with
license-back. We cannot submit the OVPL without these, because they are
necessary. An example is the change to the "no warranty" and "liability
limitation" clauses. Our view is that the existing drafting does not work
in jurisdictions that are important to us. This is nothing to do
with license-back, it is a drafting improvement. But we can hardly
submit a license without it, or wait for an indefinite period until
the CDDL folk take the change (which, given they are mostly US
based, they are unlikely to do).

I should say there is a third (broad) category of change - those
to do with what consists of a derived work and the usability
of licensed code for inclusion in larger works (the linking issue).
The CDDL being file-based did not do what we want here, and there
was no license available to modify that did. Therefore this type
of functionality change I'd categorize a separate functionality
change (IE is necessary to do what we want).

The link to the changes from the CDDL seems to have disappeared off
openvendor.org (I'll fix that), but I've put the list of changes below.
I've marked each change "[LB]" for license back-driven, "[LL]" for
OVLPL/library license/linking issues, and "[DI]" for drafting improvement.

I'm glad I did this exercise, as it shows quite how much resisted the
temptation to redraft. The ONLY "[DI]" changes left are the jurisdiction
compatibility changes to the warranty disclaimer and liability limitation
clauses, and stuff to do with the name of the license. I don't think either
of these are dropable. Which "[DI]" changes do *you* think are dropable?

Alex


Changes to the CDDL by type
===========================

Sections that have not changed (except for numbering) are not listed.

Name:	changed the name to a different name, which is equally generic. Also 
made clear that the document describes two licenses (in final form, it may 
be easier to submit two separate licenses for approval, but this way we 
make change control easier). [DI]

1.5.	Future Versions: Defined 'Future Versions' to mean future versions of 
the Original Software that are distributed by the Initial Developer under 
any license, by virtue of the additional license granted to the Initial 
Developer by Clause 3.3. [LB]

1.7.	Larger Work: Defined 'Larger Work' more narrowly, such that it only 
includes 'mere aggregation' of separate pieces of software, and (in the 
case of the OVLPL) separate pieces of Open Source software (Qualifying 
Software) linked to the Software. [LL]

1.10.	Licensed Modifications: Defined 'Licensed Modifications' to mean 
Modifications which You contribute, distribute, or otherwise make available 
(i.e. excepting Modifications which are retained privately); this is for 
the purposes of Clause 3.3, and it is these modifications which are subject 
to the additional license grant.[LB]

1.11.	Modifications: Defined 'Modifications' more broadly, to include (i) 
code (normally executable code) which required the Original Software to 
compile, and (ii) code otherwise derived from the Original Software, but 
(in the case of the OVLPL) in each case excluding separate pieces of Open 
Source software (Qualifying Software) linked to the Software. Also replaced 
'previous Modification' by 'prior Modification' for consistence with 1.2. 
[LL]

1.12.	Other Software: Defined to mean any software that is not released 
under this License. [LL]

1.13.	Qualifying Software: (OVLPL only) Defined to mean all Software issued 
under a Qualifying License, that either is not a derived work, or is only a 
derived work due its use of header files etc. during compilation. [LL]

2.1.	Initial Developer Grant: Clarified that the Initial Developer Grant is 
subject to the grantee complying not only with Clause 3.1, but all the 
mandatory clauses of Clause 3, including 3.2 and 3.3. [LB]

2.2.	Contributor Grant: Clarified that the Contributor Grant is subject to 
the grantee complying not only with Clause 3.1, but all the mandatory 
clauses of Clause 3, including 3.2 and 3.3. [LB]

3.3.	Additional License of Modifications to Initial Developer: Added a new 
Clause that gives the Initial Developer a license to any Licensed 
Modifications (i.e. Modifications which the author distributes etc.), which 
the distributor may also license under any other license, provided that the 
Initial Developer makes generally available under this license (i) any 
Licensed Modifications he uses, and (ii) a Future Version incorporating the 
same set of Licensed Modifications as any he uses. [LB]

4.1.	New Versions: Changed the license steward. We will put in the actual 
license steward after approval. [DI]

4.3.	Modified Versions: Stated that modified versions must remove 
references to the license itself, as well as the license steward; this is 
necessary as unlike the CDDL, the license now refers to itself internally. 
[DI]

5.	Disclaimer of Warranty: Only disclaimed warranty "to the fullest extent 
permitted by the laws of the applicable jurisdiction". This is to prevent 
the warranty clause being struck in its entirety in jurisdictions that 
restrict the disclaimer of warranty. Added a further limitation on warranty 
in such jurisdiction as the former limitation might, in certain 
jurisdictions, not be treated as permissible at all under certain 
circumstances (e.g. when dealing with consumers). [DI]

7.	Limitation of Liability: Only limited liability "to the fullest extent 
permitted by law". This is to prevent the liability limitation clause being 
struck in its entirety in jurisdictions that restrict such liability 
limitation. [DI]



Alex