[License-review] on OSI review/rejection [was Re: NOSA 2.0 - 'Up or Down' vote]]

[Luis Villa]

On Thu, Jan 5, 2017 at 12:57 PM Richard Fontana <fontana at opensource.org>
wrote:

> As some know, NOSA 2.0 [1] has been languishing in a limbo review
> state for an extremely long time.
>
> In my opinion, NOSA 2.0 is, in its current form, an overly complex and
> badly drafted license. I cannot gain enough confidence that it meets
> the letter and spirit of the Open Source Definition, without
> substantial revision, which the license steward seems disinclined to
> undertake. This is just my view and does not reflect any sort of
> consensus view, although I am not sure one could really demonstrate a
> consensus view on the other side. (It should be noted that Luis Villa,
> a former OSI board member and one of my personal heroes,


Hah! ;)


> actually did recommend early on that the OSI approve NOSA 2.0, but this
> never went to a vote. [2])
>

I have not looked at NOSA in some time so I can't speak to how I'd think
about that specific license today.

However, as some context to my previous push for approval: my sense was
that, except in egregious cases, being poorly written and/or duplicative
was sufficient to delay and push for improvements, but not (ultimately) to
block adoption. In particular, since there was no political will to
deprecate old licenses which did not meet "new" standards, I thought that
the best route was to ultimately approve licenses that were professionally
drafted, presented to OSI in good faith, and appeared to be in compliance
with the OSD.

I later discovered that outright license rejection, though it seems to have
> been uncommon if it occurred at all in the past several years, was
> sometimes done earlier in the OSI's history.
>

I think rejection is perfectly appropriate for licenses that obviously
violate the OSD or other *clear, written, (ideally) objective* OSI
policies. However, the OSD is frequently ambiguous or vague (e.g., patent
grant?), other rules are completely unwritten (e.g., quality standards),
and others were never actually adopted as rules (e.g., non-proliferation
report). Rejecting on any of those grounds is problematic.

Each of these have at least some fixes available (e.g., could address
drafting by requiring professional legal involvement and/or a public
drafting process). But ultimately any fixes must involve OSI saying "some
OSD-compliant licenses are better than others", so unless the org indicates
there is some stomach for that, I won't waste much time discussing the
other fixes.

Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20170109/f41a1a35/attachment.html>