[License-review] Support for SSPL v2

Nigel T nigel.2048 at gmail.com
Thu Dec 13 14:06:46 UTC 2018


I agree and there are a number of scenarios where I wonder whether the terms apply or not and the end result is folks will buy a commercial license out of fear.

Frankly, this is just an end run around the fact that non-commercial licenses aren’t considered to be open source.  

I disagree that academic/NC licenses aren’t open source but that’s the way it’s been.  

Companies that invest in their codebase need revenue to sustain their business.  I get that and agree.  To let another company compete using your own investment against you is a great way to go out of business.

Still, this doesn’t seem to pass the sniff test for the OSD and anything that reaches beyond derivative works is IMHO an over-reach.  

If you don’t want folks to profit from your codebase just make it shared source and move on.  

> On Dec 13, 2018, at 2:09 AM, Carlo Piana <carlo at piana.eu> wrote:
> 
> Greg, 
> 
> While I certainly agree with most of what you say,  being an advocate of copyleft and a believer that it must adapt to a world where cloud is the naturally dominant of software, and while I agree that it's a difficult task, I don't believe *this particular license* makes the cut. 
> 
> And I can't help repeating what I've said since the beginning. As I can't work out in a reasonably large number of application scenarios what the scope of the license (larger or stricter doesn't matter) is, the copyleft here is a red herring for "get it, but if you want to use it for anything meaningful,  you must take a proprietary license". It's the dual licensing paradigm on steroids, as it counts on uncertainty. Therefore unworkable in distributed copyright projects. 
> 
> The troubling bit is 
> 
> > "the **value** of which entirely or primarily **derives** from the **value** of the Program or modified version" [emphasis added]
> 
> That's not copyright nor a legally parsable concept. The other bit
> 
> > "or offering a service that accomplishes for users the primary purpose of the Program or modified version." 
> 
> is clear and understandable: it maps distribution to network distribution. The first is a general, vague statement that can work for certain scenarios and totally fail in others. 
> 
> Therefore, unless that bit is changed, providing stricter rules for defining boundaries, I will insist on rejection, even as experimental. 
> 
> Warmest regards, 
> 
> Carlo 
> 
> 
> 
> 
> 
>> On 13 Dec 2018, Greg Luck <greg at hazelcast.com> wrote:
>> "Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
>> The copyleft concept in the GPL applies to redistribution (GPLv2) and conveyance (GPL v3).
>> 
>> In GPL v3, To “convey” a work means any kind of propagation that enables other parties to make or receive copies.
>> 
>> Cloud Providers are different. And new.  They provide the software as a service, not a copy of the software. They provide the exact software, with the same API, and generally without any modifications, as a service. I call it service wrapping. Some examples are Redis, MySQL, Kafka.  They derive all their economic value from running the software for others without giving those others “copies”. So they can do this without passing on any copyleft restrictions. The software is used, not copied and therefore not conveyed as defined. 
>> 
>> I always through the idea behind copyleft was to prevent that other party from simply selling, or modifying a selling something that was free. So it made those derivative works free too. This is the same idea, but applied to the new world of services. 
>> 
>> The other thing that is different is that there are a smaller number of people who can meaningfully service wrap than redistribute. There are natural monopolies that exist with the giant cloud providers. Cloud Providers benefit from the network effect. There is also a high barrier to entry - it takes billions of dollars of investment and many years to set one up. The network effects are number of regions and features. This leads to more customers, and those lead to more regions and features, and so on. These factors suggest we will have a single digit number of Cloud Providers into the future. 
>> 
>> Software is rapidly changing from a model where to get utility from it, it had to be redistributed or conveyed to you, to using it as a service. If copyright owners want to restrict this, one way is to pass the copyleft obligations to the software that runs the service itself. Which is what SSPL so elegantly does. GPLv3 does not deal with this nor does any other open source license deal 
>> 
>> Which is why I support SSPL.
>> 
>> In terms of Lawrence Rosen, the last sentence in his email from yesterday is  "I vote for approval as an experimental license."
>> 
>> Regards
>> 
>> Greg Luck
>> CTO
>> 350 Cambridge Ave #100, Palo Alto, CA 94306 USA 
>> 
>> 
>>> On 13 Dec 2018, at 11:44 am, Rob Landley <rob at landley.net> wrote:
>>> 
>>> 
>>> 
>>> On 12/12/18 7:23 PM, Greg Luck wrote:
>>>> Hi
>>>> 
>>>> I wanted to offer our support to SSPL v2.
>>> 
>>> I'd like to offer my support for Universal Basic Income. I consider the
>>> sentiments roughly equivalent in this context.
>>> 
>>>> In our opinion, applying a copyleft
>>>> provision to those providing the software as a service by a Cloud Provider is a
>>>> great idea, and within the spirit of the original intent of copyleft. 
>>>> 
>>>> There is a great need in the open source community for a license that places
>>>> obligations on service wrappers. Cloud Providers as we know them now did not
>>>> exist when the open source movement came into being. It is a special case.
>>> 
>>> Richard Stallman railed about the "Application Service Provider loophole" in a
>>> talk he gave at LinuxWorld Expo in 2000. It was his main gripe with GPLv2 at the
>>> time. I was there, I think it was this one?
>>> 
>>> https://zing.ncsl.nist.gov/cifter/TheCD/TMFsite_instrumented/FoolSite/FoolMain/portfolios/rulemaker/2000/rulemaker000818.htm
>>> 
>>> GPL version 3 came out 6 years later. If he and Eben Moglen working together for
>>> half a decade couldn't manage to address the issue and still call the result
>>> "Free Software", what makes you think you're going to?
>>> 
>>> It's been _18_years_ since that conference. The "great need" hasn't really
>>> intensified since. The dot-com boom was at least as gung-ho about cornering the
>>> market on every possible niche as the modern "cloud" business models.
>>> 
>>> (Cloud is the marketing term used for "the PC got kicked up into the server
>>> space like mainframes and minicomputers before it". Mainframe -> minicomputer ->
>>> microcomputer -> smartphone, I gave my own talk about _that_ 5 years ago,
>>> https://www.youtube.com/watch?v=SGmtP5Lg_t0#t=29 and blogged about it back in
>>> 2010 http://landley.net/notes-2010.html#09-10-2010 . This is not a new thing.)
>>> 
>>> If the consensus on this list so far from people like Lawrence Rosen has been
>>> "that's now how copyright law and open source work", how is "but that's now how
>>> I WANT them to work" going to help?
>>> 
>>> Rob
>> 
>> 
>> 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/20181213/0367569a/attachment-0001.html>


More information about the License-review mailing list