For Approval: Open Vendor Public License (OVPL) and Open Vendor Lesser Public License (OVLPL)

[Alex Bligh]

Andrew,

> Well, you asked for it: I'm going to vote -1 for the following reason. I
> think the originators of OVPL and OVLPL have done an admirably
> conscientious job of drafting these licenses; I just don't accept the
> basic premise that new licenses are needed to accomplish the stated goal,
> viz., to provide a way to release code into open source while maintaining
> a parallel, commercial version.
>
> The BKM for doing this is to release the code under an OSI-approved
> license and have a contributor's agreement granting the Initial Developer
> the needed rights to relicense Modifications under a commercial license.
> Think Sun, Open Office, and Star Office.

Believe me, we thought of that. It would have been far easier in
many ways, but we came to the view it wouldn't work. Here's our rationale.

You are quite correct that IF every contributor signed a contribution
agreement, then the effect would not doubt be the same (for the initial
developer) as the OVPL/OVLPL at least in terms of the license-back.

However, there are the following problems with this:

1. Not every contributor will in practice sign a contribution agreement.
   By "sign" I mean provide a paper copy. They may or may not give
   electronic consent, which may or may not be effective, and as this
   is a separate action, notwithstanding terms of the license-back itself,
   its jurisdiction may end up differing from the license itself.
   Inevitably, people who spend their time coding sometimes do not
   pay sufficient attention to the legal details at the time (for
   instance specifying a licensor that is actually a legal body).
   The ID then has to keep track of all these issues. Assuming the
   ID is acting as maintainer, and wishes to keep the open and
   proprietary builds in sync (with respect to
   contributed features), this will add a huge amount of friction in
   ensuring contributions reach both builds in a timely manner, which
   hurts the community as well as the ID. With an OVPL-style license-back,
   the ID can rely on the fact that a license to use the code is given
   automatically by the contributor's modification of code. This makes
   the situation easier for EVERYONE to understand, and minimizes the
   amount of hassle everyone spends with legal compliance.

2. In a classic license-back situation, the license-back is a separate
   document. It may not even be available at the time the original license
   is approved. It's terms are not reviewed by OSD, and may have terms
   which are far more inimical to open source values than the OVPL
   explicit license-back. For instance, in the OVPL license-back, the
   contributor knows that if the ID is going to use his patch in the
   proprietary version, the ID must also actively make it available in
   at least one open version (as opposed to it withering somewhere).
   The license-back is conditional upon the ID's continued compliance with
   the agreement. Without reference to any specific projects, there is
   an opportunity here for the ID to develop their own license-back which
   does not accord with open-source principles. Surely it's better to have
   this in the open, and OSI approved too, so people know what they are
   signing? The OSI does not approve license-back licenses (by which
   I mean the license-back or assignment contracts themselves) for the
   simple reason they would (outside the terms of a normal license) not
   conform with the OSD.

3. One nasty scenario goes something like the following. Contributor
   A develops a patch. It gets reviewed. Contributors B through Z review
   it, and suggest alterations. Contributor A incorporates some.
   Rinse and repeat. Eventually contributor A submits the patch, and
   it is accepted. Contributor A signs a license assignment. He specifies
   that Contributors A warrants in this that he has the right to enter
   into the agreement (i.e. can so license or assign the work). If he
   is really diligent, perhaps he remembers contributors B through X
   and puts in a carve-out. But he forgets contributors Y and Z. Y has
   also signed an assignment anyway, so no problem there if the
   assignment is in general terms. Z has not. Perhaps Z turns nasty
   or gets bought by the nasty-crowd. Several years later, Z sues because
   the ID has used his IPR in the ID's proprietary software. The ID
   now has an action against A (for breach of warranty), but this helps
   noone (well, noone apart from Z). With an automatic license-back,
   everyone knows where they stand.

4. Note that the OVPL does some other stuff which other licenses
   do not do. For instance, the OVLPL relaxes "linking" provisions
   only for open-source software. We've done some work on jurisdiction
   neutrality. And we've taken a lot of the good work in the MPL and
   CDDL. Whilst none of this is mind-blowing stuff, and these bits
   (unlike the license-back) aren't individually unique, even if you
   chopped the license-back clause out, there is no license that does
   what the (neutered) OVPL does. CDDL is clearly the closest, but I
   would suggest it has serious problems for projects mainly based
   in jurisdictions based on English common law (that's UK and the
   commonwealth), and in many european jurisdictions too.

Finally, (to repeat what we've said elsewhere) we do not claim the OVPL
is suitable for all projects. We've already said "do not use this
if you plan to start an open source project from scratch". Perhaps
we should also have added "if you know you are only likely to take
patches from a small number of contributors, who you can be reasonably
certain know all the origins of their IPR, consider another OSI approved
license such as GPL, plus a separate assignment or license-back agreement".
But putting the license-back IN the agreement is (QPL aside due to
its deprecation) unique in OSI terms, and thus I don't believe proliferation
is a valid complaint. Indeed *NOT* having a (non-deprecated) license
with a license-back in is only going to cause proliferation of license-back
agreements.

It seems to me the criteria for approval should be
* Does the license mean the OSD? (and this includes)
* Does the license avoid essentially duplicating an existing license?
and I believe the answer to both those questions is "yes". The question
is not (I think) "do not approve if this be done differently, with a
different commercial effect, using an existing license" - because that
would in essence prohibit approval of any license.

I therefore urge you to reverse (or at least retract) your opinion.

And thanks for your comments on our conscientiousness.

Alex