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

[Richard Fontana]

I'll comment here on what I think may be the easiest of the four
difficult policy questions, though it is not easy.

> 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?)

I'll grant you that nothing in the OSD clearly states this is not
okay. I think one could make an OSD 5 or, better perhaps, OSD 6
argument, but I won't do that (though I'm interested in hearing other
attempts). I would argue clause 5 violates the 'spirit', though
admittedly not the letter, of OSD 9: "The license must not place
restrictions on other software that is distributed along with the
licensed software. For example, the license must not insist that all
other programs distributed on the same medium must be open-source
software."

To approve LO-R, we'd basically be saying that OSD 9 means "An open
source license can't place restrictions on other software that is
distributed along with the licensed software, but as long as the other
software is *not* distributed, it *can* place restrictions on it."

This feels to me like you're exploiting a drafting mistake in OSD 9 --
a failure, in importing the DFSG to the OSD, to think beyond
distribution criteria, which I think is true of other parts of the
OSD. Debian was naturally focused on issues like 'can a free license
force all packages in a distro to be free'. I think the reason DFSG 9
does not address the scenario of a license restricting other software
having a different tangential relationship to the licensed software
than distribution is probably that no such license had ever been
encountered. If Bruce is still following this discussion maybe he can
comment.

Leaving the literal OSD aside, I don't think open source software
should force a particular kind of licensing policy on *other*
software, entirely unrelated other than the fact that it was in some
way the functional target of running the purportedly open source
software. Here, I think strong copyleft as traditionally understood
(in the GPL/AGPL sense) is as far as an open source license should
go. My intuition is that an open source text editor, for example,
ought to be usable to modify source files that the user chooses not to
publish, or chooses to distribute only in binary form, or chooses to
publish only under a proprietary license. I believe there has been
that sort of basic assumption about open source and free software from
the get-go. Maybe others disagree with me there and I hope to hear
such other views.

I think the proper way to proceed as to this point is to consider
amending the OSD first, to clarify that an open source license can
restrict other software so long as the relationship between the open
source software and the other software is not a mere distribution
relationship, or is a kind of execution/target of execution
relationship, or something like that. Right now I'm not in favor of
such an amendment, but it might be worthwhile for the OSI board to
consider the issue. Although it can be argued that clause 5 is
consistent with the OSD, I think it is likely that a large number of
open source software users today assume that an open source license
cannot have a feature like clause 5.

Richard