[License-review] Approval: Server Side Public License, Version 1 (SSPL v1)

Fri Oct 19 00:25:55 UTC 2018

A quick note, especially to Florian, since a friend pointed out that my note could be interpreted in a way I didn't expect…

I replied to his message because it was the top one in my stack and for some reason the very first message in this thread (which I'd rather have used) somehow never arrived for me.

My replying to his message was in _no_ way intended as criticism against him or his contributions.

Florian, apologies if I accidentally implied that your comments aren't welcome. Quite the opposite, in fact.

My email was intended to keep folks on the topic of SSPL, not to quell other discussions. Please everyone DO discuss these things. Just, you know, on license-discuss. It's evident there's a lot of things we need to work through, so for the sake of efficiency we should try to keep separate discussions, well, separate and then cross-reference as needed.

Anything having to do with SSPL (including questions, comments, or recommendations for withdrawal) are very welcome on this thread. I apologise for implying otherwise.

Having consumed my deserved crow, I remain your faithful

--V

> On 18 Oct 2018, at 13:43, VM Brasseur (OSI) <vmbrasseur at opensource.org> wrote:
> 
> Hello, everyone.
> 
> While we at OSI appreciate the passion and interest everyone has in the license review process and licenses in general, we need you please to keep your comments to the topic at hand: whether the SSPL as it currently stands adheres to the OSD, any questions related directly to that matter, and any suggestions or recommendations you wish to provide to MongoDB about it.
> 
> Please move all procedural, policy, and philosophical questions over to the license-discuss list: http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
> 
> Thanks,
> 
> --V
> 
>> On 17 Oct 2018, at 23:58, Florian Weimer <fw at deneb.enyo.de> wrote:
>> 
>> * Eliot Horowitz:
>> 
>>> First, I want to thank everyone for their responses, even those who
>>> strongly disagree with our point of view. I have tried to answer most
>>> of the questions in this one response, if I have overlooked something
>>> or am doing something against etiquette, please let me know.
>> 
>> I should start by saying that I work as a toolchain engineer at Red
>> Hat, and while I'm not involved in packaging or running the software,
>> the company is likely impacted in some way by the relicensing.
>> 
>> The opinions and recollections written down here are my own, though.
>> 
>> (I'm also active sometimes in Debian.)
>> 
>>> Our intention is absolutely to have a conversation with this community
>>> and we will carefully consider changes to the license that may be
>>> suggested in these discussions. Our hope is that by building on an
>>> existing license that was the subject of extensive work and
>>> discussion, less review will be needed. We understand your concern
>>> with applying the license to the code before having gone through this
>>> process. Unfortunately it was necessary for us as a public company to
>>> do so.
>>> 
>>> We think it is time for an extension of copyleft.
>> 
>> I don't necessarily disagree.  I think the GPLv3 weakened copyleft
>> significantly because of the cloud computing exception.
>> 
>>> I think we can all agree that the GPL is not intended to be used by
>>> proprietary libraries. When you link to a GPL'd library, copyleft
>>> applies to your entire program. This is how many people today
>>> understand the applicability of the GPL. This made a lot of sense 30
>>> years ago, when GPL was first written, and has been beneficial to the
>>> community. In the modern era, however, very few programs are actually
>>> linked, in the sense of a programmatic link at build or compile time.
>>> Most modern applications are constructed by combining components as
>>> services which talk over the network via structured APIs. So we
>>> believe that the nature of the copyleft must evolve for the modern
>>> world. In the SSPL, we believe the concept of copyleft ought to apply
>>> to the pieces that make the original program run, but not everything
>>> else that touches it.
>> 
>> This is not a new problem at all.  There once was considerable debate
>> whether you could have software running on Emacs which was not
>> licensed under the GPL.
>> 
>>> An example might be useful. libmysqlclient is a GPL’d library file,
>>> and therefore copyleft provisions of the GPL apply to any program that
>>> links to libmysqlclient. The mysql command line interpreter is one
>>> such program, and it, too, is a GPL’d program. If someone wrapped the
>>> mysql command line in a network service (say, a trivial bidirectional
>>> proxy that “shelled out” to mysql), nothing in the GPL causes copyleft
>>> provisions to apply in a way that provides benefit to the community.
>> 
>> You can also connect directly to the database with a custom client.
>> Such clients exist:
>> 
>> <https://github.com/mysqljs/mysql>
>> 
>> (Note sure if that's the way people actually use MySQL from Nodejs,
>> but you get the idea.)  SQL databases are also often advertised as
>> implementing standardized interfaces, making the exchangeable to some
>> degree.
>> 
>>> This is the sort of loophole we have understood that the AGPL was
>>> intended to address, namely, to ensure that some copyleft provisions
>>> applicable to software will be meaningful in the case of software
>>> provided as a service. Unfortunately, we believe there’s ambiguity in
>>> the AGPL sufficient to easily sidestep its copyleft provisions via
>>> architectural considerations.
>> 
>> There are several things that were odd about your use of the AGPL:
>> 
>> * Your software does not contain a mechanism to download its own
>> sources once you have a (possibly authenticated) network connection
>> to it.  I think the AGPL was originally intended for situations
>> where you could change index.php in a URL to index.phps and view the
>> relevant source code, which used to be very easy to achieve with PHP
>> web servers (not so anymore because PHP itself has evolved).
>> Without such a built-in compliance mechanism, I don't think it's
>> reasonable to apply the AGPL to a piece of software.
>> 
>> * Most of the client libraries seem to be licensed on the Apache
>> License, version 2.0.
>> 
>> * My recollection is that you told your community that the AGPL didn't
>> apply to them if they used your software in the back end.  Users of
>> your software did not have to add source code distribution
>> mechanisms for your software to their web applications.
>> 
>>> For example, if I have an AGPL key value store library and I combine
>>> it with a network library and a management UI, then the copyleft
>> 
>> Again, the main problem here is that the original AGPL software has no
>> built-in compliance mechanism, and it does not directly interact with
>> the network.
>> 
>>> provisions of the AGPL apply to this use of the network library and
>>> the management UI, because of linkage. However, if someone splits out
>>> the management UI to a separate component that only interacts with the
>>> combined key-value store and network library over a socket or other
>>> IPC mechanism, it is unclear whether existing licenses’ copyleft
>>> provisions apply to that split-out management UI. For a program that
>>> is used only as a network service, we want to be sure that all
>>> components that make up the service, e.g. management and backup, are
>>> included in the scope copyleft provision of the SSPL.
>> 
>> I think this is very hard to do, with any license.  It's very
>> difficult to prevent others from enhancing an existing program with a
>> separate program.  People have tried, but successfully?  I don't know.
>> 
>> Is your management and backup solution currently available under the
>> AGPL?  I find it difficult to believe that someone would see a
>> business opportunity, ripping out an existing component of an AGPL
>> system and replace it with something proprietary.
>> 
>>> In short, we believe that in today’s world, linking has been
>>> superseded by the provision of programs as services and the connection
>>> of programs over networks as the main form of program combination. It
>>> is unclear whether existing copyleft licenses clearly apply to this
>>> form of program combination, and we intend the SSPL to be an option
>>> for developers to address this uncertainty.
>> 
>> True.  The AGPL does not extend to the entire system.  But (if my
>> recollection is correct) this is not what you intended in the first
>> place.  And your comment below suggsts that even today, you do not
>> want your users to turn their programs into free software and ship
>> sources.
>> 
>> The latter part is the main reason why I think you are not totally
>> upfront regarding your intentions.  This does not seem to be about
>> making more free software available.
>> 
>> You seem to have some rules about who is a good user and who is a bad
>> user.  But as far as I can see, these rules are *not* primarily about
>> how these users license the software they write.  It's something else.
>> 
>>> We are not intending to drive all users to a commercial license. In
>>> fact, by limiting the applicability of section 13 to offering the
>>> functionality of the licensed software as a third party service, we
>>> are hoping the SSPL will be less scary than the AGPL for those who use
>>> SSPL software for other types of SaaS applications. For our software
>>> in particular, this is consistent with our prior guidance that
>>> applications interfacing through our Apache 2 licensed drivers are not
>>> subject to the copyleft provisions of our license. If there is
>>> ambiguity on this in the license, we would consider suggestions on
>>> ways to clarify.
>> 
>> I still don't know if you want distributions to stop packaging your
>> software.  The packages are offered to end users (third parties), and
>> compiling the software is a service related to the software.
>> GNU/Linux distributions use the GNU toolchain and therefore cannot
>> make available under the SSPL the tools used to build the software.
>> The System Library exception does not apply to (say) GCC when
>> considering GCC itself.
>> 
>> All distributions use proprietary software (non-free TCP stacks) to
>> distribute pre-compiled packages.  This is actually something I
>> dislike very much, but is it really your battle to fight?
>> 
>> _______________________________________________
>> License-review mailing list
>> License-review at lists.opensource.org
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
> 