OVPL and open ownership - summary of discussion

[Alex Bligh]

David,

--On 26 July 2005 17:29 -0700 David Barrett <dbarrett at quinthar.com> wrote:

>> Guys, this thread is getting stuck in a rut.  Unless you have
>> something truly new to say, perhaps you should just give it a
>> rest, or should start a new list for OVPL-specific questions.
>> I'm sure the OSI board (if *they* haven't unsubscribed ;-)
>> has formed an opinion by now and will share it presently.
>
> Sounds good to me.  Without attempting to settle any more concerns, Alex,
> care to try a closing summary of what consensus we've obtained, and what
> concerns remain?

OK, here's my summary. I'm attempting to be as neutral as possible.

1. The changes in the OVPL aside from the license-back clause (which
   help with jurisdiction neutrality etc.) have received comparatively
   little comment, but what comment there has been has been favourable,
   with the exception of (2) below.

2. There has been one comment on ensuring certain compilers (which
   may include part of the work itself in their output) might accidentally
   cause compiled output to be subject to the OVPL. However, after some
   discussion, it seemed that the carve-out here would probably be
   pretty product dependent, and the easiest way out here would be
   to generate a specific license exception on a case-by-case basis,
   much as is done currently with the GPL - it's easier to do so with
   the OVPL as the ID can do that ex-post using the sublicensing provision.
   Noone disagreed with that.

3. People generally seemed to like the drafting (much of the credit there
   should go to Sun). There was one comment that 3.3 was impenetrable.

4. The argument has been expressed that OVPL should be approved as its
   license-back is "no worse than" the (approved) QPL, and counterargument
   that (i) the QPL should either never have been approved, or should be
   unapproved, and (ii) that the OSD does not work on a precedent system.

5. There is one school of thought (Chris Zumbrunn's posts typify this)
   that the OSD either does, or should, mandate that conformant licenses
   are entirely symmetric (i.e. that the rights given under the license
   to a given person should not depend on that person's identity); those
   who support this view consequently read something rather more extensive
   into OSD#3 that the literal interpretation (that the license to
   modifications should be under the same - literal - terms). Under
   this view, licenses which are not entirely symmetric should not be
   approved. This would include the OVPL and the QPL. There has been
   argument over which other licenses are asymmetric (for instance the
   MPL) and if so, to what extent, and whether it matters.

6. There is another argument (Andrew Wilson's point of view) which I
   believe rests on the point not that the OVPL as currently written
   breaches a specific OSD term, but simply that it is unfair (or
   perhaps that the OSD should be reworded to exclude it). This is
   (I believe) a distinct point from (5) above - I think what's
   being said here is "it may technically conform to the OSD, but
   it's not open-source, and thus the OSI should not approve
   the license" - it appears to have the same root cause (the
   asymmetry of the license). It led to 7 below.

7. Ernest Prabhakar suggested that those who had a problem with (6)
   above might be placated by a change to ensure that contributions
   which the license mandates are made available to the ID for proprietary
   use should also be made available to others for proprietary use by
   using a BSD-esque license. There are two ways to do this: either
   all non-ID contributions should carry a wider license (which may
   offend those taking view 5), or that the ID's own additional grant
   should be conditional on them sublicensing the modification under
   a BSD-esque license and marking it as such (mechanistically this
   is still asymmetric, which presumably means those taking view 5
   are still not going to be happy even if in practice it is
   asymmetric). [This would still leave the manner in which access
   is granted to non-public distributions (second half of 3.3)
   asymmetric in mechanics (but not result) which would I think offend
   the view 5 people but not the view 6 people]. I think it's fair
   to say that both the OVPL proponents and the view 6 people are
   reasonably open-minded that some form of BSD-esque relicense might
   solve the problem for the view 6 people without breaking what the OVPL
   people want to do, though I don't think it's been fully bottomed
   out yet. I suspect there is a compromise to be found here which would
   make everyone other than view 5 people happy.

8. There has been some discussion over whether or not Clause 3.3 should
   be optional, or whether clause 3.3 should specify an option to
   relicense under BSD rather than OVPL. To cut a long story short,
   I think everyone's now agreed this is a dead end.

9. There has been a debate on the enforceability of the additional
   grant in 3.3. This has centered around the fact that many common law
   jurisdictions require (by statute) that an assignment be made in
   writing. The counter-argument here is simply that the additional
   license grant is not an assignment (or tantamount to an assignment)
   because, inter alia, it is non-exclusive, and indeed USC specifically
   excludes non-exclusive licenses from its provision re assignments
   being made in writing. All has been quiet on this front since I
   pointed that out.

10. There has been a further debate on the enforceability of 3.3 on the
    basis that some people believe it sets the license up as a contract
    (rather than a conditional license). The counterargument here (and
    there seemed to be quite a lot of support for this one) is that
    the enforceability of many existing OSI approved licenses depend
    on conditional licenses working, and the OVPL is actually less like
    a contract than many of them. I think this one is a dead argument.

I think that's pretty much it. My (personal take and thus possibly
biased) summary of live issues is as follows:

* The OSI folks need to decide whether View 5 is correct or not. If it
  is, they should withdraw approval from a number of licenses, including
  the MPL, and redraft the OSD as (if this is the case) it is to say
  the least unclear. If it is not, they are acknowledging that "some
  licenses are more open than others".

* The View 6 problem can probably be sorted if Ernest's idea is acceptable
  to both sides. However, technically speaking, it should not prevent
  the OVPL's approval as-is, because (unless one subscribes to view 5) it's
  not actually a breach of a term of the OSD.

* If we are going to do the BSD-esque thing, requiring the ID to
  license modifications they use in their proprietary version under
  a BSD license and point it out appears to be the most practical
  solution, not least because it ensure the code is flagged as
  obviously available under both licenses.

Alex