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

[Kyle Mitchell]

Richard,

Thank you very much for this message.  I'd like to offer my
thoughts on the questions posed, as succinctly as I can.

First, one embarrassing, general admission from me.  Larry
Rosen was kind enough to point out today that OSL-3.0
section 5 actually goes further than AGPL-3.0 section 13 in
its trigger.  OSL's "External Deployment" reaches also "use,
distribution, or communication of the of the Original Work",
without modification.  In a few dimensions, that makes
OSL-3.0, not AGPL-3.0, the high water mark.

On 2017-10-30 13:10, Richard Fontana wrote:
> Policy question 1 (raised by clause 3: "If you modify or extend this
> software, you must release source code for your modification or
> extension."):
>
>   Can an open source license (or, for those who prefer, 'Should the
>   OSI approve a license that') require(s) source code distribution
>   upon private/internal modification or extension, even in
>   circumstances that go beyond the network services provision scenario
>   contemplated in AGPLv3 section 13 paragraph 1?

Posing this question in terms of specific prior licenses
feels very appropriate.  I've done much the same, a few
times, on the thread.  But stating it so concretely, and
narrowly, shouldn't obscure the broader implications.

If currently approved licenses are as strong as
modification-based copyleft triggers can be within Open
Source, then Open Source hobbles copyleft as a strategy.
Defining Open Source that way would say, in effect, that
copyleft has to limit itself to only a small part of the
power of copyright, or else part ways with Open Source.
That Open Source copyleft licenses have to play with a
handicap against proprietary licenses, which aren't so
limited.

The absolutism of permissive licenses is apparently not so
constrained.  We've seen at least one license, FSL/0BSD, go
right to the edge of permissivity, by stripping a dated form
down to its unclear permission grant, dropping the basic
mechanism of attribution for the sake of licensee
convenience, at non-negligible risk to licensors, and
receive approval.

A few notes on private changes, FSF, and free software below
are also relevant here.

> Policy question 2 (raised by clause 4: "If you include this software
> in a larger piece of software, you must release any source code for
> that larger piece of software that has not yet been released."):
>
>   Can an open source license (or 'Should the OSI approve a license
>   that') require(s) source code distribution merely because the user
>   has, without necessarily engaging in distribution or AGPLv3-style
>   network services provision, incorporated the licensed software into
>   other software? (Maybe we ought to assume that if this were a
>   distribution-triggerd clause it would be Open Source, though that
>   may not be clear.)

OSI-approved copyleft licenses already reach code that
incorporates, without directly modifying.  Hence all the
familiar fret about static versus dynamic linking, loading
in dynamic languages, and so on.  L0-R could alleviate those
headaches, and succinctly.

As for extent, AGPL and OSL already go beyond triggering
copyleft based on distribution.  Both trigger on execution
of the software, run in a certain way.  That kind of
execution "distributes" the usefulness of the software over
the network in only a very loose sense.  Source provisions
requirements trigger nonetheless, without actual
distribution of any copy.

Finally, I hope you'll forgive a semantic nit: I don't
believe you mean to connect this policy question to OSD 9
through "other software".  Rather, you raise OSD 9 for
question 3 / clause 5.

> Policy question 3 (raised by clause 5: "If you run this software to
> analyze, modify, or generate software, you must release source code
> for that software."):
>
>   Can an open source license (or 'Should the OSI approve a license
>   that') require(s) source code distribution of software other than
>   the licensed software, or software that incorporates or is a
>   modification or extension of the licensed software? (Perhaps one can
>   put the question this way: At what point are the 'contacts' between
>   the licensed software and the other software too remote for a source
>   distribution requirement, particularly one that is triggered merely
>   by running the licensed software, to be a legitimate feature of an
>   Open Source license?)

You've responded to this question separately.

I'll reply to that message.

> Policy question 4 (raised by your candid admission of how you yourself
> intend to use this license):
>
>   Should the OSI approve a license if the license submitter's primary
>   contemplated use is as a means of facilitating a dual-license or
>   'proprietary relicensing' business strategy?

I've tried to be as transparent as possible about the
inspiration for this license.  But my views on its purpose
or meaning won't bind others who choose to use it.  Some of
those may do so without any interest in "selling exceptions"
at all.  Nothing about the license, as written, requires
that approach.

At least one other license, Artistic-2.0, mentions reaching
out to licensors for alternative terms, right in its text.
L0-R no longer does so.  Other licenses, like Apache-2.0,
expressly address offering additional terms not found in the
public license.  GPL-3.0 consciously addresses itself to
sideline patent licenses.  As it turns out, all approved
licenses I'm aware of abide separate, parallel terms.  A
remarkable number do so expressly.

Moreover, common use for dual-licensing evidently does _not_
disqualify a license.  In my experience, AGPL-3.0 is the
most common pick of this kind, exemplified most recently by
MongoDB.  That doesn't make AGPL any less an Open Source
license.  Nor does offering software under a vague
permissive license, like MIT, with an eye to selling
functionality, title, or noninfringement warranties on the
side, cast doubt on that classic.

I am not sure what's meant by "proprietary relicensing".  It
was _not_ a drafting goal to make it possible or convenient
for L0-R licensors to retract their public license and move
the same work onto proprietary terms.  The License Zero
service happens to allow developers to set a price at which
they'll relicense from copyleft to permissive public terms,
essentially selling an exception to everyone at once.  But
the end result is software under permissive Open Source
terms, not proprietary ones.  Again, it will be perfectly
possible to use L0-R without using licensezero.com or
anything like it.

> > It's a goal of the project to conform to
> > the Open Source Definition.
>
> Apologies if you've previously commented on this, but I'm interested
> in knowing whether you also plan to seek recognition by the FSF of
> this license as conformant to the Free Software Definition. I believe
> the present-day OSI board might be reluctant to approve LO-R if it
> were very likely or certain that the FSF would designate LO-R as
> 'non-free'.

I haven't gone back and forth with FSF staff, as I have with
those on this list, about L0-R.  And I understand there's no
standard, public process for doing so.  I'd thought
originally of running both conversations in parallel, but
found license-review needed and deserved all the attention I
could muster.

Left to speculate, I'm of two minds on L0-R and FSF.

On the one hand, "What is free software?" lays out all the
components of a strong case for net-freedom-enhancing
conditions on the four freedoms generally.  It specializes
to distribution-freedom conditions to cover GPL-style
copyleft.  But that begs extension to the other freedoms.
It isn't clear from "What is free software?" why "Copyleft"
should be a subsection of "The freedom to redistribute if
you wish..." in particular, and appear there only.

On the other hand, FSF's comments on specific licenses,
which I must admit I find a bit cryptic, come down hard on
requirements to give notice of private changes.  It's hard
to tell whether that reflects an absolutist position on
freedom 1 that does not apply to freedom 3, or the fact
that, to date, triggers of the kind haven't been employed to
advance copyleft aims.

On one hand, FSF is the institutional home and intellectual
birthplace of software copyleft as practiced to date.  That
bodes well for L0-R.  On the other had, I wonder whether FSF
might be more opinionated in matters of implementation.
They are clearly invested---understandably so---in the
specific compromises written out in the licenses they tend.

> > I would also be interested in the correct process for, and
> > results of, reviewing L0-R assuming waiver of its copyleft
> > conditions---from number 3 to the end.  I suspect the
> > remainder would be classed "Redundant", especially of
> > BSD+Patent.
>
> If I understand you correctly, I'd suggest submitting that as a
> separate license (if you want to pursue that).

I might very well do so, after word on L0-R, since if at all
possible, I'd like L0-P(ermissive) and L0-R to differ only
by the addition of conditions 3-5.  I'd like to make it an
easy, abbreviated process, following on from L0-R, rather
than a separate or parallel burden.  Especially since
L0-Permissive would very likely be classed redundant of
BSD+Patents, and L0-R has been burden enough.

In other words, it can wait!

-- 
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933