On Fri, May 31, 2019 at 7:47 PM Luis Villa <l...@lu.is> wrote: > > From the updated https://opensource.org/approval: > "the OSI determines that the license ... guarantees software freedom." > > I still have seen no coherent explanation of what software freedom means in > the OSI context. Richard has asserted on Twitter that it isn't necessarily > the same thing as FSF's definition, but OSI has not (as best as I can tell) > proposed an alternative either, so we're left with a limbo of having some > idea what FSF means, but knowing that OSI's definition is somehow, in unknown > directions, different.
This isn't how I see it. "Software freedom" is a recently-popularized (still not so popular) term, which has actually been in use for quite a while, to describe a set of evolving community values and traditions around the core legal and ethical underpinnings free software/open source software, reflected in a few widely-respected and influential definitional efforts -- the DFSG, the OSD, and the 4-part FSD, but additionally reflected in the actual demonstrable choices and attitudes of the main participants in free software/open source development. If the OSI board agrees at all with any of that, maybe it could add some words to that effect. > Until more specific, less vague language is used, I remain deeply concerned > that this makes the process even more deeply political by allowing the board > to veto any license on virtually any grounds it feels like, as long as it can > be vaguely tied to "freedom" for some person or company. The constraint ought to be a commitment to the tying of "software freedom" to demonstrable community values and traditions. Of course the OSI should not be using "software freedom" to justify any arbitrary decision. Also, frankly, hasn't it been the case in practice that the OSD is broad, vague and in some places oddly-worded enough that it can also be criticized as facilitating arbitrary decisionmaking? I have recently pointed out that basically any critique of a submitted license can be couched as an OSD 5/6 violation, because any conceivable problematic feature of a quasi-FLOSS license is going to be describable as a discrimination against *someone*. What has preserved the OSI's legitimacy -- despite what I believe was the mistaken approval of a few largely-obsolete licenses years ago -- is not really the constraint provided by the 10-part OSD, but rather the commitment of the OSI in practice to adhering to shared community values and expectations about what an open source license can and can't be -- which I believe is neatly expressed using the phrase "software freedom". > It also leaves it less clear than ever what useful role, if any, OSI plays > that distinguishes it from FSF. If both organizations are using essentially > identical criteria, I'd again urge the two orgs to consider merging their > license lists and review processes. This is not a bad idea (though it's currently somewhat unrealistic). But it has been a good idea for a long time, because in reality the two organizations *have* been using the same underlying criteria, for the OSI at least since the mid-2000s. Both organizations seek to recognize as respective-definition-conformant licenses that can be expected to guarantee software freedom. They just happen to use different definitions, much as Debian and the FSF use different definitions of "free software". That after all is why the two organizations have few significant disagreements about the FLOSS-legitimacy of particular licenses. If the two organizations were really aimed at markedly different value systems we'd expect to see major differences between the FSF's list of free software licenses and the OSI's list of approved licenses. Richard _______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
