Subject: Re: Two new licenses - OVPL & OVLPL
From: Alex Bligh <alex@alex.org.uk>
Date: Sun, 10 Apr 2005 18:54:14 +0100

Bruce,

--On 10 April 2005 10:10 -0700 Bruce Perens <bruce@perens.com> wrote:

> I haven't looked at this for OSD compliance, but am making a comment on
> the covenant between you and the outside developers. Is your intention to
> vend an _enhanced_ version of the software that is not Open Source while
> you work on a "community" version as well, or do you only wish to
> continue to fulfill the needs of proprietary licensees for the exact same
> program? IMO the asymetrical relationship that occurrs when the initial
> developer vends a proprietary "super" version which also mixes in outside
> contributions doesn't attract developers very well. They have no desire
> to be second-class citizens.

In the general case, either. However, note that any *outside* contributions
by definition must be in the open source version. That's the "catch" for
the ID as per 4.1: they get the additional license "provided such versions
remain available under the terms of this License or a future version of
this License released under Section 4.1".

If you mean what are the differences likely to be for the enhanced
version, in the context of clients I'm dealing with at the moment,
they fall into two categories:
* Enhanced features developed solely by the Initial Developer which
  they intend to open source at a later date (and make some money from
  in the mean time) - rather like the Ghostscipt model.
* Features linked to closed source libraries the ID is paying for either
  by the copy or in some other manner, whose license effectively
  prohibits incoporation into open source software. In respect of some
  of these, there are no viable open source alternatives (and may
  well never be, due to patents and/or industry adoption of a single
  vendor as a closed standard).

It's actually the second which is the hardest to get wrong.

> If that is not your intent, I would suggest that you balance the
> relationship while retaining the ability to service your proprietary
> customers. In the initial developer grant, include a promise that as long
> as you are using the subsequent contributions in a proprietary version,
> that you will also release the same program under an OSI-certified Open
> Source license.

That's already there isn't it - the bit of 4.1 I mentioned? In respect of
each contribution, if the ID makes use of the additional developer grant
for proprietary product, they must in return make the contribution
available under this license (which hopefully will be OSI certified).
Perhaps I'm missing what you are saying.

Alex