[License-review] resolving ambiguities in OSD [was Re: For Approval: License Zero Reciprocal Public License]

[Richard Fontana]

On Wed, Oct 25, 2017, at 11:33 PM, Luis Villa wrote:
> On Tue, Oct 24, 2017 at 6:20 PM Josh berkus
> <josh at postgresql.org> wrote:>> On 10/24/2017 06:13 PM, Bruce Perens wrote:
>> >
>> > With regard to *simple users,* those who make use of the Open
>> > Source>> > software and do not modify or redistribute it, there should be as
>> > close>> > to *no legal load* as possible. We need to be cognizant that
>> > many of>> > these users are individuals and very small businesses that can't
>> > reasonably assume any legal load at all. We can't protect them from>> > patent issues brought by others than the licensor of the
>> > software, but>> > to the extent that we can protect them, we should. In
>> > particular, *simple users should not ever have to read the
>> > license.*>> 
>> Is this an actual requirement for OSI license certification?  I ask
>> because it has specific bearing on whether or not we recommend LZRPL.>> 
>> It would also leave open the question of why the AGPL gets to
>> circumvent>> that requirement.
> 
> And GPL v2 and v3, and EUPL, and I'm sure others. (The only reason one
> can even vaguely pretend v2 meets a "should not ever have to read the
> license" criteria is because of decades of usage.)
I read Bruce as saying that, in effect, mere exercisers of FSF Freedom 0
should not have to read the license, essentially the same as saying an
Open Source license should not limit Freedom 0. But maybe I
misunderstood and Bruce was speaking much more broadly.
> Again, OSI would be well-served by actually writing down the non-OSD
> criteria, or publicly admitting that the criteria are not agreed-to
> and non-transparent. I realize this would not be easy, but the current
> situation benefits no one.
So here are some of my thoughts on this. I think the OSI (and I mean the
OSI broadly to include the license-review and license-discuss
participants) has never really limited itself to mechanical or
literalist application of the OSD, not taking context , tradition or
policy into account. I think this is  clear from review of the mailing
list archives and past OSI board minutes relating to license approvals.
I am not sure if there is some expectation out there that the OSI
*should* limit itself to literalist application of the OSD but that
seems wrong to me.
For one thing, the OSI grandparented in a bunch of licenses at the
beginning, as exemplifying what open source was supposed to mean. I
don't think the OSD can be understood properly without thinking about
that. All of those licenses did not limit Freedom 0, for example.
The first sentence at https://opensource.org/approval
says: "The goal of the OSI License Review Process is to ensure that licenses and software labeled as "open source" conforms to existing community norms and expectations."
I do think it would be good to try to write down more about those norms
and expectations that is not obvious from an out-of-context review of
the OSD. (Actually I'm all for trying to revise the OSD, but there is
probably little appetite for that. )
But I feel the accusation of nontransparency is unfair. Several years
ago I gave a talk (called "The Tragedy of the Commons Gatekeepers") in
which I criticized the license review  processes of OSI, FSF and Debian.
One thing I liked about OSI, though, was its transparency - at least in
any contentious case, when a license was rejected, it was generally
clear what the problem was, from review of mailing list archives and
board minutes. Contrast that with Debian, where the legendary ftpmasters
have arbitrary power to accept or reject licenses without rationale
(subject to the democratic processes of Debian, though), or the FSF,
where rationale for free/nonfree designations is often relatively
unclear or opaque.
 Richard


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20171026/9b1a62e6/attachment.html>