[License-review] OSD #9 would not make SSPL OSD-incompliant

[Josh Berkus]

Kyle,

>> This question is particularly important because there are a number of
>> non-OSS licenses in the Javascript community that also make this claim
>> (you test your code using my code, it's under my license). This is the
>> reason why the FSF has been careful to define GPL licenses as not
>> applying on mere use, since that's a minefield and will definitely lead
>> to license ragnarok.
> 
> I wrote at least one of the licenses I think you're alluding
> to, and proposed an old version of it to OSI for review.  I
> would be interested to learn of the others.

Yes, and I critiqued that license for the same reasons.  However, ZRPL
at least only requires the release of source code (under any terms),
rather than licensing it under its own license, the way the SSPL does.

> Conditions on preparation of derivative works and
> distribution to the public---freedom 1 and freedom 3,
> loosely---already lay a "minefield", but have not led to
> license Ragnarok.  I concede that stronger copyleft
> conditions on reproduction in copies incidental to
> execution---freedom 0---and preparation of derivative works
> without distribution---freedom 1 alone---will lay more
> mines, as any stronger copyleft license does, to fill holes
> in the intended defensive perimeter.  That makes copyleft
> strategically effective for more kinds of software.  That's
> true of network copyleft, which triggers on use, whether the
> terms say "use" or not.

I don't know of any approved "network" license which doesn't require
modification of the original work as well in order to trigger.
Certainly the AGPL requires it.  Which license are you thinking of?

> Ask developers whether "free for open source" means free for
> use on closed projects.  Ask them whether "free for open
> source" itself counts as open source.  If they say "no",
> tell them what copyleft is, and ask whether it can ever
> count as open source.

Speaking as someone who was a software developer for 20 years, you are
quite mistaken.  The ability to utilize OSS tools in a non-modifying way
on closed-source internal projects drives the entire economy of
independent contract developers.  In fact, it was my original reason for
getting involved in OSS in the first place; the nickle-and-dime
marketplace of pay-$50-for-each-library-you-use sucked and prevented
rapid development of solutions by small teams.  This is why I opposed
your LicenseZero, because I believe it to be the death of sharing code
for Javascript.  I know more JS developers who feel the same than agree
with you.

When it comes right down to it, you are an attorney, and not a developer.

With the SSPL, I'm honestly less concerned about its effect on
closed-source development (because MongoDB is already AGPL) and more
concerned about its effect on other software licenses.  The SSPL as I
read it is intended to be uber-viral, where anything that touches the
SSPL code becomes itself SSPL-licensed, even if it was under a different
OSS license.

We are well-served by the current diversity of licenses in the
ecosystem.  Attempts to create "one license to rule them all" are not
something that the OSI should be endorsing.  Nor is certifying licenses
designed out of the gate to create incompatibilities.

Where ragnarok kicks in is, imagine that there are several such
extreme-copyleft licenses.  The SSPL, the ZZZPL, The PLPLPL.  So I want
to analyze my GPLv3 code with an SSPL program, and then compile it using
a PLPLPL program.  But I can't, not without creating a situation where
the software can't be legally distributed at all.

The winner, in such a situation, is proprietary software.  And that's
directly against the mission of the OSI.

-- 
Josh Berkus