[License-review] For Approval: License Zero Reciprocal Public License

Bruce Perens bruce at perens.com
Tue Oct 24 23:23:43 UTC 2017


On Tue, Oct 24, 2017 at 12:42 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:
>
> As I understood it, the SPICE limitation didn't say anything
> about licensing or source availability.  I imagine it had
> more to do with human rights, or perhaps Apartheid specifically.
>

The license included a bald statement restricting use by the police of
South Africa, without any accompanying rationale or mention of human rights
or Apartheid. The project might have issued this elsewhere.


> Just to check my understanding:  By "passive users", do you
> mean users of the software as distributed, without
> modification?
>

Yes.


>
> You may have disposed
> of the GPL argument with condition 6 as you expanded on it.
> But proprietary software either is a "field of endeavor", or
> it isn't.  If it is, then you have to read "not restrict
> anyone from making use" oddly, narrowly, and very
> specifically to avoid current copyleft implementations.
>

Can you look back in the list archive? I'm really sure this has been
discussed repeatedly.

But if OSD 6
> needs other words, after so many years, to say what it
> means, then OSI should add and explain those words.  They
> should be as public and accessible as the rest of OSD is
> today.
>

Well, you can write a FAQ. But given that the entire goal of the OSD is to
facilitate the production of Open Source Software, if anyone concerned had
become convinced at any time that it banned the GPL, action would have
already been taken.


>
> I must be missing something.  This seems to elevate form over substance in
> a pretty dramatic way.
>

You told me you could not write the language you desired using only
modification, Mr. Lawyer, and you had to have use. I took that as a
challenge. My language is simple, easy for the layman to understand, and it
works. I submit that coupling use in the odd way you did is more form over
substance than my proposal.

In the case of the OSD, I took the easy path and said "no restrictions",
rather than enumerate a long list of permissible restrictions and study all
of their possible consequences, not that we wouldn't have been surprised
later by ones we didn't think of. The simpler language won.

Isn't the legal effect the same?


Well, if I made the OSD fit the problem, rather than the license fit the
OSD, I might have a page of material in OSD #6 alone, and the OSD would be
more difficult for everybody. IMO its simplicity is one of the reasons that
it won. So, I have proposed three simple and readable sentences in the
license, and the license would not end up shorter or easier to understand
if the OSD were written the way you propose.


> Don't most approved
> licenses pare permissions back with restrictive conditions
> on a broad grant, rather than long enumerations of
> affirmatively stated permissions?
>

So? At the risk of sounding like Larry Wall, there's more than one way to
do it. And you are actually proposing that I add affirmative permissions to
the OSD.


>
> I note that the language you propose _does_ differ from
> going L0-R condition 3, in that it permits indefinite
> private use of private modifications.  Is that relevant in
> making it OSD-conformant, in your view?  It comes up fairly
> often in FSF's comments on licenses.


Yes, I just showed you the logical way to do what you want. And I used
"publish" in one place and "distribute" in another, which isn't what would
be done in finished language. You're the lawyer and can make the language
fit your purpose exactly.

    Thanks

    Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20171024/4e958776/attachment.html>


More information about the License-review mailing list