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

[Josh Berkus]

On 10/24/2018 04:33 PM, Kyle Mitchell wrote:
> On 2018-10-24 14:10, Josh Berkus wrote:
>>>> 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.
> 
> I haven't done a specific review, but I'm not aware of any
> other proposed or approved copyleft license that affords a
> choice of terms for derivative works,
> compatibility-relicense exceptions aside. In at least that
> dimension, SSPLs run with the pack of copyleft licenses.
> Zero stood apart.

Yeah, we've had a few of these recently, and I'd like to see a
choice-of-derivative-works license pass, because that feels very useful
to me.

> This begs a few important policy questions about specific
> choices copyleft rules make, versus combinations of those
> choices, but I'd rather address those in a structured way,
> on the blog.

Please link it when you do!

>>> 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?
> 
> Have a look at the definition of "External Deployment" in
> OSL 3.0, for example.

Huh, interesting.  Was that specific provision discussed at the time?
Bruce?  Simon?

> The ability to utilize open code in closed projects is the
> purpose of permissive licenses.  Strong copyleft licenses,
> conversely, have always _prevented_ use of open code in
> closed projects, by the most popular means for doing so in
> their days.
> RMS, in _Copyleft: pragmatic idealism_:
> 
>   I make my code available for use in free software, and not
>   for use in proprietary software, in order to encourage
>   other people who write software to make it free as well.
>   I figure that since proprietary software developers use
>   copyright to stop us from sharing, we cooperators can use
>   copyright to give other cooperators an advantage of their
>   own: they can use our code.
> 
> I don't think RMS would approve of SSPL.  But I think that's
> because he sees his moral commitment to, and definition of,
> software freedom as imposing a limit on how strong a
> copyleft license he can use.
> 
> Open source has always encompassed both permissive and
> copyleft.  Asking folks who believe "free for open source"
> isn't itself open source about copyleft more generally goes
> to exactly this point.

So I think we're getting split on two different definitions of closed
projects.  There's "software I develop for myself and don't distribute
or sell" and there's "software I develop for my/my company's own
internal use".

Historically, copyleft has been compatible with the latter.  The
extension of copyleft into "mere use" makes it incompatible.  Surely
there must be some way to address SAAS-as-distribution without doing so?

> Why would open source cover licenses that effectively keep
> closed developers away if "build with" means "ship a copy to
> install and run" or "use to provide network service", but
> not other kinds of "building with", so prevalent today?
> 
> To be clear, I don't care to reopen the debate on Zero
> specifically.  I am _very_ interested to reopen more general
> policy questions that Zero posed, especially whether "open
> source" limits copyleft, and if so, what those limits are,
> and why.

Yes, and I don't think that we can address the SSPL without addressing
those questions.  Given that the same causes will keep coming up, we
will keep seeing license proposals like these.

> 
>> When it comes right down to it, you are an attorney, and not a developer.
> 
> https://www.npmjs.com/~kemitchell

Well played, sir, well played!  Indeed so.

>> 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.
> 
> Dev tool makers who want "free for free software" terms are
> not well served.  Neither are back-end system makers like
> Mongo, especially those who want terms that permit
> combination in applications internally.

Keep in mind that you're speaking to someone who spent 18 years working
on PostgreSQL.  I remain unconvinced that stronger copyleft is required
for database developers to have a business model.

> License incompatibility due to diverse copyleft licenses
> approved by OSI already prevents useful combinations.

Right, and there's a discussion on *every* license proposal of "does
this make that situation worse?"  And sometimes that's grounds for
rejecting the proposal.

> But if OSI decides that "open source" means open developers
> have to share dev tools and back-end services with
> proprietary developers, that places a serious handicap on
> open source development in competition with closed.  They
> can use our best tools, but we can't use theirs.

I understand this argument.  However, it's also true that no work of
software is original; every bit of software written today depends on a
large infrastructure of older software.  It's lovely to think of
enforcing your "copyleft-on-steriods" license when you're the author,
but far less exciting to think of the day in which you can find no
complete toolchain that works for your OSS project because everything is
under an incompatible, network-effect, license.

*That* is what I call a handicap on open source development.

-- 
Josh Berkus