[License-review] Support for SSPL v2

Wed Dec 19 22:03:36 UTC 2018

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20181219/9522a2a4/attachment.html>