[License-review] Support for SSPL v2

Thu Dec 20 00:53:17 UTC 2018

Hi Lawrence,

On Thu, 20 Dec 2018 at 00:05, Lawrence Rosen <lrosen at rosenlaw.com> wrote:

> Martijn Verburg wrote:
> > I'm also the CEO of jClarity, which is actually a proprietary software
> license company, a choice we partly made because we were concerned about
> cloud providers service wrapping our software, I feel the commercial pain
> here.
>
>
>
> I'm sympathetic to your oft-stated problem and to your commercial pain,
> Martijn, but confused by your loose choice of words. What do you mean
> technically by "wrapping our software"? All software is necessarily wrapped.
>

Apologies! That was ill thought out wording on my part. What I meant is
what some folks are calling "Service Wrappers" in the blogsphere (again not
well defined when it boils down to it). Let's say (in the hypothetical
case) our APM Diagnostic Engine was under a OSI approved OSS License and it
was then "service wrapped" by a cloud vednor who made it available as a
SaaS (without contributing back and/or making their SaaS enabling source
code avaialble to the public).

As you know, ordinary copyleft conditions in the AGPL, OSL and similar
> licenses will require that "your software" and its modifications be forever
> published as open source software. But what's a wrap? Why are you concerned
> with the mere wrapping by third-party software around your unique,
> valuable, copyrighted and copylefted, open source jClarity software?
>
>
>
> By the way, I am not convinced that SSPL's far-reaching but
> non-discriminatory copyleft *condition* makes that an improper open
> source license, and not merely one that will be avoided like the plague by
> users. (That discussion continues.) But I am convinced that your own desire
> for a wrap-avoiding license doesn't work for open source. Or if you are
> still concerned with limiting "wrapping," you are not open source software.
> That is okay commercially, but not on this list. See OSD #6, "No
> Discrimination Against Fields of Endeavor".
>

At this stage of my thinking I agree, I don't think it works for Open
Source either.  This one of the reasons we went for a proprietary license
at the time, we knew the potential commercial gains of open sourcing our
software under an OSI license (e.g. more contributors etc) but also the
potential dangers to our business model (e.g. Various competitors could
take our core code and out spend us or "Service Wrap" us). I agree OSS is
not a business model!

That said, I see *some* parallels to this and the linking use case (AGPL in
particular) and so I'd also personally like to think more deeply on this
and have more folks from a broader spectrum weigh in.  But I do think that
should be done at a later date on license-discuss once the SSPLv2 has been
used in the wild for a bit and has adoption by more vendors than just
MongoDB (which again I'm happy to help with).

Cheers,
Martijn

>
>
> /Larry
>
>
>
>
>
> *From:* License-review <license-review-bounces at lists.opensource.org> *On
> Behalf Of *Martijn Verburg
> *Sent:* Wednesday, December 19, 2018 2:04 PM
> *To:* License submissions for OSI review <
> license-review at lists.opensource.org>
> *Subject:* Re: [License-review] Support for SSPL v2
>
>
>
> Hi all,
>
>
>
> TLDR
>
> --------
>
>
>
> After some long thought and many, many discussions with various folks
> across the spectrum, at this stage, I'm with Bruce on this one and am happy
> to help infrastructure projects/providers come up with a common license,
> but I think getting one that would be OSI approved in a short timeframe
> isn't going to be feasible.
>
>
>
> Thre Longer version
>
> ---------------------------
>
>
>
> I'm the CEO of jClarity, which is actually a proprietary software license
> company, a choice we partly made because we were concerned about cloud
> providers service wrapping our software!  So I do strongly sympathize with
> the commercial pressures that infrastructure projects/providers are
> operating under. It certainly isn't always easy to see others profiting off
> your hard work without contributing back in a meaningful manner, regardless
> of license choice. Yes, there is a potential risk that large, complex
> infrastructure projects won't be built under any sort of shared source or
> OSS auspices if investors all shy away from investing in them because they
> think service wrappers will kill their investment due to no license
> protection.
>
>
>
> I'll repeat an often cited statement which I've repeated verbatim to
> several investors and founders in the last few days:*  "OSS is not a
> business model"*
>
>
>
> Making changes to the OSD in order to incorporate what is effectively an
> FOU restricted OSS License should be approached cautiously and over a much
> longer time period than what we're all seem to be working under right now
> (appreciate the commercial pressures here, see below). Maybe something like
> the SSPLv2 could become an OSI approved license but for now we shouldn't
> rush this through, the consequences are incredibly long-lasting and
> far-reaching and I don't think we've collectively had enough time to think
> all of this through yet.
>
>
>
> With all of that in mind, I'd also like to offer my help alongside Bruce's
> to get the various infrastructure providers together to work on a common
> license that they're happy with. We could call the group the
> "Infrastructure License Consortium" or something else appropriate. I think
> this would address Greg's concern of proliferation, if all of the various
> players work together then they could all use the same Commons Clause, or
> SSPLv2, or YYY license and that could become a de-facto license for this
> particular service wrapper use case in the industry for whoever *wants to*
> use it.
>
>
>
> Starting in parallel the broader ecosystem could discuss how that license
> could or could not be an OSI approved Open Source License. I'm sure that
> will be a long and involved discussion, as it should be!  Perhaps at that
> point, it would be appropriate as an OSI experimental license, but let's
> cross that bridge when we come to it.
>
>
>
> Disclaimer / Background
>
> --------------------------------
>
>
>
> I'm a first-time poster, to help folks understand some of my biases etc
> here's a self-important listing of roles etc, apologies in advance:
>
>
>
> I act as a representative (when they want me to!) for Java User Groups
> worldwide and spend time pulling together vendors who are normally
> adversarial to work in communities for the common good (e.g. AdoptOpenjDK).
> This topic is of great interest to parts of that community as several
> infrastructure projects are written in Java and these projects by their
> nature attempt to fulfill an important piece of the Java (and dare I say it
> software) ecosystem for a good length of time!  Licensing *really* matters
> (preaching to the converted on this obviously).
>
>
>
> For my sins, I sit on the Java Community Process Executive Committee (an
> enterprisey mouthful I know!), the Eclipse Jakarta EE steering committee
> and help run the advocacy group at OpenJDK. I Am Not A Lawyer, my
> background is that of a non-legal 'expert' in GPLv2+CE, AGPL, EPL and
> Apache v2.0 as it applies to the Java ecosystem in particular.
>
>
>
> Repeated from above:  I'm also the CEO of jClarity, which is actually a
> proprietary software license company, a choice we partly made because we
> were concerned about cloud providers service wrapping our software, I feel
> the commercial pain here.
>
>
>
> =====
>
>
>
> Cheers,
> Martijn
>
>
>
>
>
> On Wed, 19 Dec 2018 at 02:31, Bruce Perens <bruce at perens.com> wrote:
>
> On Tue, Dec 18, 2018 at 5:58 PM Greg Luck <greg at hazelcast.com> wrote:
>
> If OSI or another standards body fails to solve this problem with a
> general, community accepted license, which keeps open source as we know it
> but restricts service wrapping, then there will be plethora of new custom
> licenses where each open source software vendor solves the problem for
> themselves.
>
>
>
> OSI can not "solve" this problem without changing the definition of Open
> Source or stepping outside of the territory of Open Source to create a new
> commercial licensing paradigm. They can't do that. I *can* do that, and
> will help gratis - as I have already helped other attorneys - as long as
> you promise to avoid conflict with Open Source. That means you call it
> something else, and that you acknowledge the difference between your
> licensing and Open Source. Have your attorney write to me.
>
>
>
> We must remain cognizant that "Open Source companies" remain in the
> minority of Open Source developers. Most Open Source developers do not wish
> to make any revenue from their software, but use it to enable another
> business or non-profit activity. Those folks might welcome having their
> software adopted by a service provider.
>
>
>
> I predict the majority of popular open source infrastructure software will
> have defensive measures in place in the next year, all with custom licenses.
>
>
>
> Actually, it would not be the majority of Open Source infrastructure
> software. It would be the minority produced by companies which wish to
> directly gain revenue from that software. This is not the paradigm behind
> the production of most Open Source.
>
>
>
> Which will require the use of a lawyer to use that software, create
> commercial uncertainty and be a major friction in the use of what has been
> open source software.
>
>
>
> Which will not be OSI or Open Source's problem. You create this problem by
> leaving the tent.
>
>
>
>     Thanks
>
>
>
>     Bruce
>
>
>
>
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20181220/82664082/attachment-0001.html>