[License-review] For Approval: License Zero Reciprocal Public License
mccoy.smith at intel.com
Fri Oct 20 20:38:35 UTC 2017
I had similar drafting concerns as did Richard, as well as others. The goal with this license is still a bit murky to me (the way I read it and understand the mailing list discussion, the goal here is to create a permissive license that may be relicensed under any copyleft license that meets the OSD, but for a short grace period where it might be relicensed under any other license model), and I think there are probably better ways to achieve this goal with greater clarity (and to avoid questions of OSD compliance that others have raised).
1. I agree with Richard that the grace period concept, as currently formulated, is arguably non-conformant with OSD 6. I also think that the way Richard has reformulated it solves that potential problem. It also is more consistent with how other, more recent, OSD approved licenses do things; see, for example, the grace/cure periods in Sec 8 of GPLv3. So, rather than saying "you may only do X for the following number of days," saying "you must do Y within the following number of days" gets away from questions about whether you are excluding a specific field of endeavor, which is prohibited by OSD 6. Another tack, which I think is more consistent with your goals here, is to say "you must relicense under a license that obligates, as a condition of exercise of rights, that source code be disclosed" (or something along those lines) to eliminate the concern you seem to have about permissive licensing allowing for the option of non-open source (aka commercial) forking. The grace period to me seems like a fairly unimportant part of the goal of your license, unless you are trying -- like the authors of GPLv3 -- to make clear that users have a certain period, greater than instantaneous, to conform without being in a state of breach or infringement.
2. The use of "Open Source" in quote marks is potentially confusing given that's not a defined term by the OSI. The OSI promulgates the Open Source Definition (OSD for short) so I think you should be using that terminology. Also, it is not "software" that meets that definition, it is the license associated with it. Better terminology would be something along the lines of "software licensed under a license that meets the Open Source Definition from the Open Source Initiative." Note, however, I think it is smarter to instead say "software that is licensed under a license certified as meeting the Open Source Definition by the Open Source Initiative" since tying your license terms to the definition means that there are any number of licenses that have never gone through the review process (and which may in fact be non-OSD compliant) that may be swept up into the options of your license. By way of example, the Clear BSD License: It is on the FSF's list of "free software" licenses, but not on the OSI list. There are good reasons for that (as described in the warnings on the FSF page). Can LZPL code be relicensed Clear BSD? Is that a result you want, given the concerns some have with that license?
3. As Richard has noted "uses with modifications" is quite confusing. I think you are referring to conditions imposed upon modifications of code licensed under LZPL; if so, you should say that. If not, it sounds to me like you are trying to impose restrictions upon other software (that software that is used with modifications of LZPL software), which would be a violation of OSD 9.
4. "Uses as part of, or in development of, other software" seems to be a clear limitation on other software, and a violation of OSD 9. I'm not sure what you're getting at here that is different than in the prior paragraph. "Part of" seems to be getting at the same concept as "modifications" in the prior paragraph. "In development of" seems to be targeted at the same thing, or else is an effort to impose conditions on software in no way derived from LZPL licensed software, which would fail OSD 9 (and is probably copyright misuse as well).
It might help if you were to more clearly articulate (on the board, or to yourself) what it is you want people to do, and not do, with LZPL licensed code, articulate those in a draft of the license (using language more consistent with the rights granted in BSD), and then compare those against, in particular, OSD 6 and OSD 9 to ensure that neither the goals, nor the explicit language, of your provisions are inconsistent with those parts of the definitions.
I also find the argument that you're trying to do something that AGPL, or LGPL, or some other OSI approved license is trying to do, but in a different way, to be muddling the discussion. In general, the discussion (per the submission guidelines) should focus on conformance with OSD, the rationale for your license ("Compare to and contrast with the most similar OSI-approved license(s)": i.e., what additional features beyond 2-clause BSD this license provides), and perhaps why particular language you chose is being used.
As an aside, a permissive license that allows for copyleft forks but not permissive or proprietary forks might be an interesting option, if that's what you're trying to get at. I don't think that there is anything right now on the OSI list that does that. But right now it's not clear to me that's what you're getting at.
From: License-review [mailto:license-review-bounces at opensource.org] On Behalf Of Richard Fontana
Sent: Friday, October 20, 2017 11:16 AM
To: license-review at opensource.org
Subject: Re: [License-review] For Approval: License Zero Reciprocal Public License
The BSD license (family) seem to make a distinction between "redistribution" and "use", as did some other permissive licenses originating at roughly the same time. Others, none ever submitted for OSI approval AFAIK, merely spoke of permitting "use". I'm not sure if that was true of any proto-versions of the BSD license, but I am pretty sure that the earliest versions did not have "with or without modification" spelled out.
One could get into whether that's a good way of drafting a copyright license, but I don't think it's necessary to get into that. We certainly all accept that the 3-clause and 2-clause BSD licenses are OSD-conformant. So too derivatives like the recently-approved BSD+Patent (not to be confused with the late Facebook React license).
Your license keeps the distinction between "redistribution" and "use". But partly as a consequence of that, I find the language of the added clauses confusing. They refer to "uses" where the original BSD language had (and still has, in your license) "use". Is "uses" the same as "use", or does it just mean "particular forms of the thing that was previously referred to in the singular as "use""? Or no?
If "uses" is essentially the same as, or just a pluralization of, "use" as used in the initial grant language, doesn't that suggest that clauses 3 and 4 somehow don't cover the redistribution case? Maybe that doesn't matter, but I'm finding it at least distracting. :)
Or why "uses" instead of "use", when everyone is expecting the license to refer to "use" because that's what its BSD ancestors did?
Leaving that issue aside, I also find it distracting where the license says "uses with modification". I find it at least somewhat confusing phrasing.
Don't you mean something like this: If you've exercised the right to modify which I've semi-implicitly granted you with my BSD-derived grant language, then in proceeding to "use" that modified version -- which I will assume for the moment is really "distribution and use", or "use including distribution" -- at all points in time in which the "use" is taking place, the code has to be "Open Source" in the OSD sense (including the fact that I must publish source code if otherwise there'd be no licensing act and source code wouldn't be available to anyone but me)?
Would it be equivalent to say something like: If you modify this code, you must publish the modifications under an OSI-approved license within <Grace Period> days? Not suggesting that's better wording but I'm trying to rephrase what I think the intended meaning is. My rephrasing there also may make clearer what some may see as an open source conformance issue.
I may have a comment on clause 4, but I will leave it there for the moment.
On Thu, Oct 19, 2017, at 08:27 PM, Kyle Mitchell wrote:
> Revising the text of the proposed license, per feedback here on
> license-review and elsewhere.
> Also replying to the original message this time. If I revise again,
> I'll do the same, so it's easier to find.
> First the new text, then a few notes.
> License Zero Reciprocal Public License <Version>
> Copyright <Year> <Copyright Holder>
> Redistribution and use in source and binary forms, with
> or without modification, are permitted provided that the
> following conditions are met:
> 1. Redistributions of source code must retain the above
> copyright notice, this list of conditions and the
> following disclaimer.
> 2. Redistributions in binary form must reproduce the
> above copyright notice, this list of conditions and
> the following disclaimer in the documentation and/or
> other materials provided with the distribution.
> 3. Uses with any modification that is not "Open Source"
> as defined by the Open Source Initiative must be
> limited to <Grace Period> calendar days.
> 4. Uses as part of, or in development of, other
> software that is not "Open Source" as defined by the
> Open Source Initiative must be limited to <Grace
> Period> calendar days.
> THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
> WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
> WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY
> DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
> CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
> NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
> OF SUCH DAMAGE.
> - I've removed all mention of agent for sale of alternative
> licenses, as well as the automatic waiver of the copyleft
> conditions. My motivation was twofold. For one, those
> features produced considerable comment, concern, and
> confusion, aside from the main issue of use conditions
> triggering copyleft. For two, the aim of each can be
> achieved otherwise, outside the license text. As a result,
> the proposal is now _exactly_ BSD-2-Clause, plus new
> conditions 3 and 4.
> - The copyleft triggers now speak directly in terms of OSD
> conformance, to catch both source availability and license
> terms requirements. (The assumption is that L0-R, in some
> form, will eventually be recognized itself, so L0-R code
> can clearly incorporate L0-R code.) But that aside, I
> think the new language goes more directly to intent, and
> reads more clearly.
> - I've split the new conditions across two numbered items.
> This should help clarify that unmodified use alone does
> not trigger share-alike.
> - I was tempted to define terms for repeated words and
> phrases, but held the urge back. BSD-2-Clause doesn't do
> so, and for this kind of license, stylistically, I think
> that's probably best.
> Kyle Mitchell, attorney // Oakland // (510) 712 - 0933
> License-review mailing list
> License-review at opensource.org
License-review mailing list
License-review at opensource.org
More information about the License-review