[License-review] Approval: Server Side Public License, Version 1 (SSPL v1)
Kyle Mitchell
kyle at kemitchell.com
Tue Nov 6 03:02:19 UTC 2018
As promised, my stab at a systematic review of OSD criteria
for rules regulating the design of copyleft terms:
https://writing.kemitchell.com/2018/11/05/OSD-Copyleft-Regulation.html
I believe SSPLv1 conforms. It does nothing the Definition
prohibits. But on the points that make SSPL interesting,
that may say more about the Definition than the license.
I limited my review to the text of OSD, comparisons to DFSG,
historical context, and license approvals. Criteria 3, 8,
and 10 express clear limits on copyleft design. Criteria 1,
5, 6, and 9 set limits if we start with limits to set,
assume invariantly that they _have_ to go somewhere in OSD,
and resolve to do what's necessary to available text to get
them there.
A fair reading of the Definition doesn't set any closed
boundary for copyleft within open source. For example, it
doesn't clearly address when copyleft can trigger, or what
code it can reach. Given its age, its context, and its
purpose in its time, expecting clear answers to questions
that hadn't really been asked yet is unfair to those who
wrote, reviewed, and approved the Definition. Given the
novelty of the issues, twenty years of developments, and the
talent now assembled, it's also unfair to pretend OSD
authoritatively means more than it transparently says,
precluding present-tense debate.
I'd venture to say most everyone agrees there _should_ be
effective limits on open source copyleft. Discussion of
where they should lie will remain needlessly difficult, to
read and to write, so long as every point has to be
force-fit between OSD's lines. For the sake of debate, I'd
rather acknowledge, collectively, that OSD criteria describe
very strong, even uncomfortably strong copyleft licenses,
that we've very good reasons to keep debating beyond
established conformance, but that we're invoking undefined
behavior by doing so. Let's address transparently what
additional criteria or process OSI will apply, and think on
how to message them.
Beyond a few drafting points, I hold one substantial
reservation about SSPLv1, in the "offering ... primary
purpose" item of the disjunction at the end of the first
paragraph of section 13. I have my reasons. But I can only
read them _into_ OSD with purpose. I can't read them _out_
of OSD with objectivity. I'd rather just write what I think,
as best I can write it. But that's a contribution to chaos,
unless that kind of input leads somewhere.
As a final SSPL-specific note, I agree that SSPL meets
criteria 5, 6, and 9, but not for the reason given in the
SSPL FAQ. As I describe more fully in the section of my
post linked below, I find it hard to read either a
licensing-jargon or a legal distinction between
"restriction" and "condition" into OSD. I think it's
perfectly possible, and natural, to read those criteria to
miss copyleft entirely, rather than to regulate copyleft,
but only when its rules are structured or styled as
"restrictions".
https://writing.kemitchell.com/2018/11/05/OSD-Copyleft-Regulation.html#restriction-versus-condition
--
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933
More information about the License-review
mailing list