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

[Kyle Mitchell]

Richard,

Thanks also for this message.  Again, great thought and
effort in evidence.  Noted.  Much obliged!

On 2017-10-30 14:10, Richard Fontana wrote:
>
> 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."

That seems unnecessary overkill.  Reading OSD 9 to mean "as
long as the other software is _not_ distributed, it _can_
place restrictions on it" goes well beyond what's needed to
approve L0-R.  It would also miss the case where L0-R
software is used to generate subject code, and one or both
do get distributed.

As an alternative, OSI could read OSD 9:

  The license must not place restrictions on other software
  that is distributed along with the licensed software[ as a
  consequence of being distributed along with the licensed
  software --- KEM].

This sits quite well with the example:

  For example, the license must not insist that all other
  programs distributed on the same medium must be
  open-source software.

Other criteria may still constrain licensing.  OSD 3, for
example:

  The license must allow modifications and derived works,
  and must allow them to be distributed under the same terms
  as the license of the original software.

L0-R meets OSD 3.  All code required to be "released" can be
released under L0-R.

> 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.

No exploitation intended!

I read OSD 9 as a basic protection for the "common carriers"
of the software world: the loaded-media vendors, mirror
hosts, and kindred bit merchants, whose business is to
distribute qua distribute, without manual modification.

Given the volume of software packages these folks handle, to
make widespread use of systems like Debian possible, our
lack of interest in seeing terms of service from each, and
the fact they often provide service out of the goodness of
their pocketbooks, we don't want to impose per-package
analysis of license obligations springing out of their kind
of distribution, besides.  We can impose such worries on
folks who work with what they carry, but not on those who
merely transport from maintainer to working destination.

If I recall correctly, the heading for OSD 9's predecessor
in DFSG uses "contamination".  That makes a very nice
analogy to crates of goods loaded into a container for
shipping.  Each individual crate may be full of noxious
awful.  But as customers shipping the awful, you and I
needn't concern ourselves with whether your industrial
solvent was stacked atop my radioactive isotopes in the
truck, so long as yours doesn't leak onto mine, and mine
doesn't irradiate yours.  Neither does the shipping company
have to care.  So too as a Debian APT FTP host, one needn't
worry whether package X and package Y create license woes
amongst themselves by simple virtue of passing through the
same server, appearing on the same USB stick, or flying away
in response to a single HTTP request.

Professional Aside:  By "common carrier" I am hereby
revenged upon Richard for wanton use of "contacts".  That
induced a case of the lawyer-willies on my end, utterly
foreseeable on his!

> 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.

The text editor example is one that's come to my mind, too.
I asked myself a few times whether L0-R should reach through
that kind of program.  It's a new thought in my world,
though of course proprietary text editors certainly aren't.

Then I turned the question around:  Should L0-R deny text
editor authors, as a class of developer, the ability to
press the same kind of copyleft bargain that we offer to
others?  At a more general level, are we willing to deny
developer toolmakers meaningful copyleft bargains to offer,
of this kind?

We can all smudge the library-developer tool line without
much trouble.  Any library can be packaged as a tool that
patches the same into other code, or spits it out to STDOUT,
perhaps applying simple transformations, based on input.
Code is data, and data is code.  One gets run, the other
gets derived from or incorporated.  But that's mostly us
lawyers pleasing themselves with lawyerly distinctions.
Copyright catches all of the above.

Smudging the line doesn't mean there ought not to be one.
Taking off somewhat from Bruce, within my understanding,
Open Source ought to keep in mind that share-alike
requirements should fall on developer-kind, rather than
user-kind, or perhaps bit-merchant-distributor kind.  L0-R
does not extend to _all_ output or input of L0-R programs.
Only to grammatical objects in sentences with verbs that
strongly imply developer subjects.  Situations where OSI has
expected competence to contend with present-day, GPL-style,
distribution-based copyleft, as well.

That makes developer tools exactly the class of programs
where software copyleft ought to be able to go, without
collateral damage among Bruce's "simple users".  Moreover,
it's the only place share-alike _can_ go, insofar as sharing
like means sharing code, rather than other products of
running software, even products subject to copyright.  L0-R
does _not_ require that, say, graphic art or prose be made
available under Creative Commons terms, or made available in
any way.

If copyleft can't reach developer tools, Open Source
developer tools will always be as much benefit to
proprietary shops as to Open Source ones; proprietary
toolmakers will not reciprocate without extrinsic
motivation.  Linters, prettifiers, optimizers, transpilers,
bundlers, compilers, and the like will become a one-way
valve between those competing communities.  Those are
_precisely_ the tools where open development occurs most
naturally, where itches are most likely to be felt and
scratched, where developers know best what to do, since
development is what they do.  Like libraries, tools are
directed very specifically at developer-kind.

On a personal note, many of the independent developers
inspiring this work made meaningful and important leaps
precisely in developer tooling and broad-purpose utility
libraries, this turn of the great programming-platform
cycle.  The tools afford value in being applied to code,
much less so than being extended or directly modified, than
other products of programming effort.  I'd be greatly
disappointed to deny the next generation of toolmakers
strong reciprocity, and the business model that can proceed
nicely with it.  Existing strong-copyleft licenses, like
AGPL, do little or nothing for them now---almost all use is
unmodified, though the users are plenty capable of
modifying, and on local machines, without network
interaction.  The same licenses serve nice code library
authors better.

> ... 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.

I have to admit, the phrase "basic assumption about open
source and free software from the get-go" kind of takes the
wind out of me.  On the one hand, I don't have anything to
take away from it, factually.  I wasn't around; for all I
know, you're dead right.  But I'm troubled that, frankly,
there's nothing I feel I can say about it, at all.  Though
it apparently matters to this and other outcomes.

In other contexts, that's par for the course.  In Open
Source, _about_ Open Source, it's tingling the kind of
frustrated feeling we've hit before, in meta-discussion
about transparency.  A disempowered feeling.

If had-to-be-there is what it comes down to, I could not be
more in favor of an OSD revision.  And a revision that goes
beyond the terse style of the current text, to give a better
chance of preserving the why, the rationale, behind whatever
harder-line rule or clarifications currently exists in
unreduced wisdom.  "Spell out all of your unspoken
assumptions" is too tall an order for anyone, at any time, I
know.  But as close as we can come, that's what we leave
behind.  With a little luck, I'll contribute to enough of
note to find myself facing that problem someday, too.

> ... 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.

I don't mean to play the same old saw too often, but this
strikes me as an off-ramp to still another strange loop in
the license-review process.

In the same way that polling constituents' preferences will
turn up only more encouragement toward cultivate permissive
licenses, and spurn copyleft, asking users what they're
already familiar with will reinforce the need for more of
what OSI has already approved.  That sets a collision course
with license antiproliferation, broadly defined.  In tandem,
they'd add up to a prescription to shut OSI's doors, carve
the current license list into stone, and declare eternal
victory.

I understand that position has some support.  Trouble is,
the thought process might have held just as strongly before
OSL, before AGPL, or before any of the recent permissive
inductees, for that matter.  And it's fundamentally
inconsistent with the idea that Open Source can or should be
defined in principle, rather than by a purely empirical,
social, or political process.  In that alternate Open Source
universe, OSI would need a new polling process or voting
apparatus, not a refined Definition.

Thanks again,

K

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