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

[Kyle Mitchell]

I received a phone call from Bruce Perens today, on L0-R and some other topics.

Bruce made very clear that he doesn't represent or speak for OSI, but provided some excellent feedback on the process and L0-R specifically.  Feedback I felt I should summarize here, so it lives with the rest of the mail archive, where others will probably look for that kind of thing.  This summary can't be all of it---I was too busy keeping up to take good dictation---but I hope Bruce will chime in if he feels I've got something wrong, or omitted something essential.  He's copied.

Bruce's most concrete point was that, yes, licenses that conform to the Open Source Definition are open source licenses, but some licenses that conform to the Open Source Definition come before OSI, and leave without OSI approval.  Poorly drafted terms conceived by amateur drafters came up a few times.  As did needless, proliferating reimplementations of existing terms.

The major point that I took on a more general level was that I should expect and respect focus on "licensee compliance load" created by L0-R, especially for "passive licensees" who don't look like developers, and tend to use FOSS because it is free.  A litmus test is whether users who don't either know or care about Open Source and its particulars stand a chance of needing a lawyer at any point.  Permission must be very clear to feel comfortable advocating use with no counsel.

Use without involving either lawyer skills or development skills is "free riding" in a very direct sense.  But creating opportunity for others to ride places they otherwise couldn't afford to go is a valuable kind of public good that OSI promotes, absent though it may be from the Definition.  A similar concern for compliance load on developers combining software under Open Source terms pervades.  All of this sounded in points already made here on the list in different terms, especially about the dichotomy, sharp or fuzzy, of "users" and "developers".

Bruce didn't see great prospects for anything triggering short of either modification or distribution, even if the triggering actions look distinctly developer-like, such as incorporation into another program or compilation of other code.  The outlook seemed to be that licenses triggering in that way could very well conform to the Definition, but would be very difficult for OSI to be seen to promote.

We discussed AGPL at some length, and in some detail.  Bruce characterized the section 13 trigger there as attempting to synthesize an analog to public performance of copyrighted software work, which doesn't exist under the law.  From that point of view, provision over a network wasn't "use", it was trying to be something entirely of its own kind.  A kludge.

We also discussed the legal boundary between creation of derivative works and reproduction in copies, to acquire a copy to execute, and also incidental to execution itself.  We agreed that many ways to incorporate or adapt software---combinations---probably should be treated as derivative, but don't involve "derivative works" as that's understood at law.  That begs another attempt at synthesis.  One not taken up to date.

My specific takeaways for L0-R were twofold:

1.  Take another stab at revising condition 3, to make it more readable, especially for not-a-lawyers.

2.  Revisit the condition also to clarify, if possible, a "safe zone" of uses for which permission is unconditional, even at the expense of added length.  L0-R might be OSD-conformant as written; I certainly see it that way.  In final form, it may or may not garner OSI approval.  But whatever the outcome, that clarity is worth chasing.

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