On Wed, Oct 17, 2018 at 09:01:57PM -0400, Josh Boyer wrote:
> | or the modified version, and the Corresponding Source for all
programs
> | that you use to make the Program or modified version available as a
> | service, including, without limitation, management software, user
> | interfaces, application program interfaces, automation software,
> | monitoring software, backup software, storage software and hosting
> | software, all such that a user could run an instance of the service
> | using the Service Source Code you make available.”
This section, right? This could be interpreted as "you have to give
us the source code for the compiler you used to build the software,
under the SPPL license". Is that an example of your concern?
Not to mention the corresponding source code to the local operating
system including the kernel and all device drivers; every executable,
library, and runtime runtime directly or indirectly executed; the
virtualization hypervisor and/or host operating system; system
BIOS/UEFI/device firmware; and arguably your entire SAN/network/backup
infrastructure and everything you use to manage/monitor *that* too.
Because all of that ("without limitation") is used "to make the program
available as a service."
It's one heck of a poison pill that makes the SSPL-licensed software
effectively impossible to utilize in order to provide a public-facing
service. (At least without obtaining a commercial license..)
There is a lot of good discussion here. Here's Florian's take:
http://lists.opensource.org/pipermail/license-review_lists.opensource.org...
TL;DR: The [[un]intended] consequences are significant, and because the
goals behind the license aren't entirely clear, we don't know if those
consequences are bugs or a features.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Coconut Creek, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.