[License-review] Support for SSPL v2

Thu Dec 20 00:04:17 UTC 2018

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.

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".

/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 <mailto:bruce at perens.com> > wrote:

On Tue, Dec 18, 2018 at 5:58 PM Greg Luck <greg at hazelcast.com <mailto: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 <mailto: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/20181219/c5a8e83d/attachment-0001.html>