<div dir="ltr">> They can use our best tools, but we can't use theirs.<div><br></div><div>It's fundamental to Open Source that everyone can run the program for any purpose. And as we have discussed in the past, they shouldn't even have to read the license to do that. So, it has been obvious from the start that proprietary software folks could leverage their business in various ways using Open Source without giving back in any way.</div><div><br></div><div>Anyone can create their own license and call it "Business Source", and give it rules that prevent some forms of use. But I don't think it's at all attractive to throw out the ability for anyone to run the software for any purpose, in the name of making someone's business method work. So, to the extent that it's necessary to make crystal clear what was always intended, I am recommending a change in the definition.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 24, 2018 at 4:32 PM Kyle Mitchell <<a href="mailto:kyle@kemitchell.com">kyle@kemitchell.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-10-24 14:10, Josh Berkus wrote:<br>
> >> This question is particularly important because there are a number of<br>
> >> non-OSS licenses in the Javascript community that also make this claim<br>
> >> (you test your code using my code, it's under my license). This is the<br>
> >> reason why the FSF has been careful to define GPL licenses as not<br>
> >> applying on mere use, since that's a minefield and will definitely lead<br>
> >> to license ragnarok.<br>
> ><br>
> > I wrote at least one of the licenses I think you're alluding<br>
> > to, and proposed an old version of it to OSI for review.  I<br>
> > would be interested to learn of the others.<br>
><br>
> Yes, and I critiqued that license for the same reasons.  However, ZRPL<br>
> at least only requires the release of source code (under any terms),<br>
> rather than licensing it under its own license, the way the SSPL does.<br>
<br>
I haven't done a specific review, but I'm not aware of any<br>
other proposed or approved copyleft license that affords a<br>
choice of terms for derivative works,<br>
compatibility-relicense exceptions aside. In at least that<br>
dimension, SSPLs run with the pack of copyleft licenses.<br>
Zero stood apart.<br>
<br>
This begs a few important policy questions about specific<br>
choices copyleft rules make, versus combinations of those<br>
choices, but I'd rather address those in a structured way,<br>
on the blog.<br>
<br>
> > Conditions on preparation of derivative works and<br>
> > distribution to the public---freedom 1 and freedom 3,<br>
> > loosely---already lay a "minefield", but have not led to<br>
> > license Ragnarok.  I concede that stronger copyleft<br>
> > conditions on reproduction in copies incidental to<br>
> > execution---freedom 0---and preparation of derivative works<br>
> > without distribution---freedom 1 alone---will lay more<br>
> > mines, as any stronger copyleft license does, to fill holes<br>
> > in the intended defensive perimeter.  That makes copyleft<br>
> > strategically effective for more kinds of software.  That's<br>
> > true of network copyleft, which triggers on use, whether the<br>
> > terms say "use" or not.<br>
><br>
> I don't know of any approved "network" license which doesn't require<br>
> modification of the original work as well in order to trigger.<br>
> Certainly the AGPL requires it.  Which license are you thinking of?<br>
<br>
Have a look at the definition of "External Deployment" in<br>
OSL 3.0, for example.<br>
<br>
> > Ask developers whether "free for open source" means free for<br>
> > use on closed projects.  Ask them whether "free for open<br>
> > source" itself counts as open source.  If they say "no",<br>
> > tell them what copyleft is, and ask whether it can ever<br>
> > count as open source.<br>
><br>
> Speaking as someone who was a software developer for 20 years, you are<br>
> quite mistaken.  The ability to utilize OSS tools in a non-modifying way<br>
> on closed-source internal projects drives the entire economy of<br>
> independent contract developers.  In fact, it was my original reason for<br>
> getting involved in OSS in the first place; the nickle-and-dime<br>
> marketplace of pay-$50-for-each-library-you-use sucked and prevented<br>
> rapid development of solutions by small teams.  This is why I opposed<br>
> your LicenseZero, because I believe it to be the death of sharing code<br>
> for Javascript.  I know more JS developers who feel the same than agree<br>
> with you.<br>
<br>
The ability to utilize open code in closed projects is the<br>
purpose of permissive licenses.  Strong copyleft licenses,<br>
conversely, have always _prevented_ use of open code in<br>
closed projects, by the most popular means for doing so in<br>
their days.<br>
<br>
RMS, in _Copyleft: pragmatic idealism_:<br>
<br>
  I make my code available for use in free software, and not<br>
  for use in proprietary software, in order to encourage<br>
  other people who write software to make it free as well.<br>
  I figure that since proprietary software developers use<br>
  copyright to stop us from sharing, we cooperators can use<br>
  copyright to give other cooperators an advantage of their<br>
  own: they can use our code.<br>
<br>
I don't think RMS would approve of SSPL.  But I think that's<br>
because he sees his moral commitment to, and definition of,<br>
software freedom as imposing a limit on how strong a<br>
copyleft license he can use.<br>
<br>
Open source has always encompassed both permissive and<br>
copyleft.  Asking folks who believe "free for open source"<br>
isn't itself open source about copyleft more generally goes<br>
to exactly this point.<br>
<br>
RMS goes on:<br>
<br>
  Not everyone who uses the GNU GPL has this goal.  Many<br>
  years ago, a friend of mine was asked to rerelease a<br>
  copylefted program under noncopyleft terms, and he<br>
  responded more or less like this:<br>
<br>
    "Sometimes I work on free software, and sometimes I work<br>
    on proprietary software---but when I work on proprietary<br>
    software, I expect to get paid."<br>
<br>
  He was willing to share his work with a community that<br>
  shares software, but saw no reason to give a handout to a<br>
  business making products that would be off-limits to our<br>
  community.  His goal was different from mine, but he<br>
  decided that the GNU GPL was useful for his goal too.<br>
<br>
Strong copyleft licenses were written to deny the use of<br>
free code to closed developers, to create a competitive<br>
advantage for open developers.  It just so happens that<br>
copyleft licenses---including Zero and now SSPL---work both<br>
for that purpose, and as the basis of dual licensing plays.<br>
Any license that excludes closed projects, for activist,<br>
strategic, or business reasons, can also work as the public<br>
license for a dual licensing play.<br>
<br>
OSI has approved licenses for specific developers who very<br>
clearly wanted to dual license.  And also for activists,<br>
like FSF, that never intended to sell exceptions.  OSI has<br>
also approved licenses that explicitly mention dual<br>
licensing, like Artistic.<br>
<br>
You don't need a license that triggers copyleft on dev-tool<br>
use to exclude closed developers from using _any_ code in<br>
closed projects.  You can already do that for some kinds of<br>
code with old, approved copyleft licenses.  In the case of<br>
front-end JavaScript in particular, even first-generation,<br>
distribution-based copyleft licenses work swell, because<br>
JavaScript gets distributed to site visitors with<br>
app-specific code.<br>
<br>
You _do_ need a stronger copyleft license to cover back-end<br>
libraries.  The answer there is OSL, maybe RPL.  You _do_<br>
need a stronger copyleft license to cover dev tools.  As far<br>
as I know, that license didn't exist until Zero.  You _do_<br>
need a stronger copyleft license to cover freestanding<br>
back-end systems.  Like SSPL, at least in general approach.<br>
<br>
Why would open source cover licenses that effectively keep<br>
closed developers away if "build with" means "ship a copy to<br>
install and run" or "use to provide network service", but<br>
not other kinds of "building with", so prevalent today?<br>
<br>
To be clear, I don't care to reopen the debate on Zero<br>
specifically.  I am _very_ interested to reopen more general<br>
policy questions that Zero posed, especially whether "open<br>
source" limits copyleft, and if so, what those limits are,<br>
and why.<br>
<br>
> When it comes right down to it, you are an attorney, and not a developer.<br>
<br>
<a href="https://www.npmjs.com/~kemitchell" rel="noreferrer" target="_blank">https://www.npmjs.com/~kemitchell</a><br>
<br>
I was a 1099 web dev before law school.  Mostly content<br>
management systems and educational multimedia.<br>
<br>
I remain active in legal automation, like <a href="http://commonform.org" rel="noreferrer" target="_blank">commonform.org</a>,<br>
<a href="http://publicdomainchronicle.org" rel="noreferrer" target="_blank">publicdomainchronicle.org</a>, and SPDX validation code and<br>
utilities for for Node/npm and a small bit for RubyGems, as<br>
well as browser-based peer-to-peer applications, like<br>
<a href="http://proseline.com" rel="noreferrer" target="_blank">proseline.com</a>.  I wrote both the server (Node.js) and CLI<br>
(Go) for License Zero.  The former is licensed on the<br>
strong-copyleft terms that I wrote, without any offer to<br>
sell exceptions.<br>
<br>
None of that matters.<br>
<br>
> With the SSPL, I'm honestly less concerned about its effect on<br>
> closed-source development (because MongoDB is already AGPL) and more<br>
> concerned about its effect on other software licenses.  The SSPL as I<br>
> read it is intended to be uber-viral, where anything that touches the<br>
> SSPL code becomes itself SSPL-licensed, even if it was under a different<br>
> OSS license.<br>
><br>
> We are well-served by the current diversity of licenses in the<br>
> ecosystem.  Attempts to create "one license to rule them all" are not<br>
> something that the OSI should be endorsing.  Nor is certifying licenses<br>
> designed out of the gate to create incompatibilities.<br>
<br>
Dev tool makers who want "free for free software" terms are<br>
not well served.  Neither are back-end system makers like<br>
Mongo, especially those who want terms that permit<br>
combination in applications internally.<br>
<br>
All copyleft licenses that require work within the reach of<br>
their copyleft rules to be licensed under the same terms<br>
compound compatibility issues.  That has been true of every<br>
new strong-copyleft license without a very generous and<br>
explicit compatibility bridge, like we see with EPL 2.0.  It<br>
was true of GPLv3, in the context of GPLv2.<br>
<br>
> Where ragnarok kicks in is, imagine that there are several such<br>
> extreme-copyleft licenses.  The SSPL, the ZZZPL, The PLPLPL.  So I want<br>
> to analyze my GPLv3 code with an SSPL program, and then compile it using<br>
> a PLPLPL program.  But I can't, not without creating a situation where<br>
> the software can't be legally distributed at all.<br>
><br>
> The winner, in such a situation, is proprietary software.  And that's<br>
> directly against the mission of the OSI.<br>
<br>
License incompatibility due to diverse copyleft licenses<br>
approved by OSI already prevents useful combinations.<br>
<br>
But if OSI decides that "open source" means open developers<br>
have to share dev tools and back-end services with<br>
proprietary developers, that places a serious handicap on<br>
open source development in competition with closed.  They<br>
can use our best tools, but we can't use theirs.<br>
<br>
Some folks don't want open to compete with closed,<br>
especially at the ready-to-use application level.  But I<br>
don't think it was OSI's consensus mission to relegate<br>
openness to components, tools, or infrastructure in the<br>
service of proprietary development, or to "deprecate"<br>
copyleft for new work, going forward.<br>
<br>
I do think it remains OSI's mission to encourage software to<br>
be open.  The question copyleft poses is the extent to which<br>
that can mean _requiring_ software to be open, through<br>
intellectual property license terms, rather than merely<br>
hoping it will be, or lobbying that it should be.<br>
<br>
-- <br>
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933<br>
<br>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>