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.font...@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@lists.opensource.org > > > > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org > > > _______________________________________________ > License-discuss mailing list > License-discuss@lists.opensource.org > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org _______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
