[License-discuss] Proposed license decision process

Thu Dec 13 17:16:38 UTC 2018

On Sun, Dec 09, 2018 at 03:42:08PM -0800, Luis Villa wrote:
> (1) what is the proposed test for "guarantees software freedom"?
> (2) if the answer to #1 is something like "the same tests as the FSF would
> apply" (either explicitly or implicitly), does the board plan to talk with
> FSF about merging license lists and review processes? If not, why not?

(Just speaking for myself here)

I see the OSD as one attempt to define (or create a test for the
existence of) software freedom. The FSF's Free Software Definition is
another, different attempt.

As a definition, or test, the OSD, like any such attempt including the
FSD, is imperfect. The idea of revising or updating the OSD
occasionally comes up, as you know; for various reasons that I think
mainly come down to a certain sort of combination of conservatism and
pragmatism and inertia this is not likely to happen in the shorter
term.

However, the limits of the OSD as a self-sufficient test are becoming
more evident. I am concerned about efforts to "game" the OSD, or
reduce it to a narrowly-interpreted checklist. I can easily come up
with hypothetical licenses that would seem not to fail a highly
literalist reading of the OSD, but which historically would never have
been *treated* as conforming to the OSD, because of an obvious failure
of the license to provide software freedom as traditionally understood
in the community. When we see more real-world counterparts to
hypothetical licenses like that, what I find often happens is that
people use OSD 5/6 as a way of reintroducing consideration of the
values and norms that were historically brought to OSI license
review. I am sure I am viewing the past in a rosier manner than is
actually justified.

Anyway, I see explicit consideration of a provides-software-freedom
expectation as a way of correcting against this tendency to read the
OSD increasingly narrowly and literally. 

So, there's been no discussion of a test as such. The assumption, I
think, is that it will involve case-specific analysis. 

As to the FSF, I myself would like to see greater harmonization
between FSF and OSI with respect to treatment of purportedly-FOSS
licenses. I don't think merging review processes would make sense
because of the very different procedural approaches of the two
organizations. But for example the reason I asked Eliot Horowitz
whether he'd planned to get FSF review of SSPL(v1) is that it would be
non-ideal for FSF and OSI to reach different conclusions about what is
clearly one of the most controversial license submissions in recent
memory (not that I think that is necessarily likely ... anyway it
doesn't sound like MongoDB has concrete plans to approach FSF). I also
happen to like the public commentary of the FSF on its interpretation
of the Free Software Definition and I think it could be a useful
resource for other organizations, including OSI, to consult when
undertaking their own software-freedom-oriented review of licenses.

Richard

> 
> 
> On Thu, Dec 6, 2018 at 10:38 PM Richard Fontana <
> richard.fontana at opensource.org> wrote:
> 
> > At a recent meeting, the OSI Board discussed requests to clarify the
> > license approval process (documented at
> > https://opensource.org/approval). We've drafted the guidelines below,
> > which we aim to follow when reviewing licenses, to ensure that a
> > license will be approved only if it conforms to the Open Source
> > Definition and provides software freedom.
> >
> > "Decision Date" for a license normally means (a) 60 days after a
> > license is initially submitted for review, and (b) 30 days after
> > submission of a revised version of a license that was previously
> > submitted for review. A license is considered to be submitted for
> > review if it follows the process set forth at
> > https://opensource.org/approval. While we will try our best to adhere
> > strictly to this 60/30 day Decision Date definition, circumstances may
> > require us to extend the Decision Date further.
> >
> > On the Decision Date, the OSI will announce one of four possible decisions:
> >
> > 1. Defer for another 30-day discussion cycle, if community discussion
> > of conformance of the license to the OSD remains active
> >
> > 2. Approve, if (a) there is sufficient consensus emerging from
> > community discussion that approval is justified, and (b) the OSI
> > determines that the license conforms to the Open Source Definition and
> > guarantees software freedom
> >
> > 3. Reject if (a) the OSI determines that the license cannot
> > practically be remedied to adequately guarantee software freedom, or
> > (b) there is sufficient consensus emerging from community discussion
> > that the license should be rejected for substantive reasons, or (c)
> > the license is problematic for nonsubstantive reasons (for example, it
> > is poorly drafted or significantly duplicative of one or more existing
> > OSI-approved licenses)
> >
> > 4. Withhold approval, if (a) the OSI determines that approval would
> > require reworking the license and (b) the license submitter appears
> > willing and able to revise the license constructively
> >
> > We would appreciate your comments.
> >
> > - Richard
> >
> > _______________________________________________
> > License-discuss mailing list
> > License-discuss at lists.opensource.org
> >
> > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
> >

> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org