OVPL and the OSI Board on Thursday

[David Ryan]

Russ,

I'd just like to echo Alex's words.  We have worked very hard to create 
a license
which meets a need, and does so in a way that is templated and useful 
for others.
Alex and I both live in different countries and our discussion started
after finding other licenses didn't meet our needs.  People like David 
Barrat
prove that we are not the only ones.

I also request that the license is not withdrawn at this time from 
gaining OSI
approval.  I don't think I need to expand on what Alex has alread said 
on this issue.

Alex mentioned that the license diff disapeared off the openvendor.org 
web site.
This has now been fixed.  It is at 
http://openvendor.org/License_Description_and_Rationale

Regards,
David.

Alex Bligh wrote:

> 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
>
>
>