![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
So the big free software news of the week is that Amazon is forking Elasticsearch after Elastic relicensed Elasticsearch under the SSPL. The internet's in a frenzy about this, as tends to happen these days whenever a large previously free software project goes proprietary. I'm disappointed that the free software world has partly lost yet another useful piece of software, and glad that the project will at least live on in some form as free software, even if not from Elastic.
But let's back up a moment. What is the SSPL, the license that Elasticsearch was just relicensed to? What does it do? Why does everyone consider it a proprietary license? Well, it's largely based on the GPL, with a few additional restrictions that kick in if you're "mak[ing] the functionality of the Program or a modified version available to third parties as a service". Let's take a look at the relevant bits of the license text for a moment:
Now, one thing in particular here jumps out at me (emphasis mine):
Keep in mind that the definition of "service source code" here means:
You might be able to see where I'm going here. To comply with this license while offering the SSPL-licensed program as a service, you must be able to relicense all the software in your stack under the SSPL. It's incredibly unlikely that you're able to do this: if you use Linux for example, it's under the GPL, and while you can do many things with this you can't relicense it under the SSPL.
I'm inclined to interpret this somewhat uncharitably and say that the license was intentionally written to make complying with this clause nearly impossible. However, let's think about a more charitable interpretation for a moment. If we assume that your goal is to ensure that users of your software are always able to make changes to the software they're actually using, distribute those changes, and so on, there are a few license tweaks you could make. Rather than requiring that the program itself and its surrounding enviroment all be distributed under the SSPL, you could be more flexible with the licenses, like so:
I'm not saying this is perfect or that we should start doing this, but it's an interesting line of thought to think about. Most hosting companies certainly wouldn't be able to comply with this, but if you were willing to commit to only using FOSS, it doesn't close the door to it immediately. (If the software were running on Guix, for example, it would likely be pretty easy for me to comply by posting the Guix manifest for my servers along with the Guix revision used.) I think a license modified in this way would be a bit more palatable to the free software community than the SSPL is today, while still preventing large companies from integrating the software into their proprietary offerings.
Even this modified license would not be Open Source. It probably wouldn't be acceptable under the DFSG. It might, however, be Free Software, and that'd be an interesting discussion to have.
But let's back up a moment. What is the SSPL, the license that Elasticsearch was just relicensed to? What does it do? Why does everyone consider it a proprietary license? Well, it's largely based on the GPL, with a few additional restrictions that kick in if you're "mak[ing] the functionality of the Program or a modified version available to third parties as a service". Let's take a look at the relevant bits of the license text for a moment:
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. 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.
“Service Source Code” means the Corresponding Source for the Program 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.
Now, one thing in particular here jumps out at me (emphasis mine):
you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License
Keep in mind that the definition of "service source code" here means:
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.
You might be able to see where I'm going here. To comply with this license while offering the SSPL-licensed program as a service, you must be able to relicense all the software in your stack under the SSPL. It's incredibly unlikely that you're able to do this: if you use Linux for example, it's under the GPL, and while you can do many things with this you can't relicense it under the SSPL.
I'm inclined to interpret this somewhat uncharitably and say that the license was intentionally written to make complying with this clause nearly impossible. However, let's think about a more charitable interpretation for a moment. If we assume that your goal is to ensure that users of your software are always able to make changes to the software they're actually using, distribute those changes, and so on, there are a few license tweaks you could make. Rather than requiring that the program itself and its surrounding enviroment all be distributed under the SSPL, you could be more flexible with the licenses, like so:
“Service Dependencies” mean 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.
...
you must make the Service Dependencies available via network download to everyone at no charge, under the terms of this License or, at your option, under any other licenses designated as Free Software by the Free Software Foundation, or as Open Source by the OSI.
I'm not saying this is perfect or that we should start doing this, but it's an interesting line of thought to think about. Most hosting companies certainly wouldn't be able to comply with this, but if you were willing to commit to only using FOSS, it doesn't close the door to it immediately. (If the software were running on Guix, for example, it would likely be pretty easy for me to comply by posting the Guix manifest for my servers along with the Guix revision used.) I think a license modified in this way would be a bit more palatable to the free software community than the SSPL is today, while still preventing large companies from integrating the software into their proprietary offerings.
Even this modified license would not be Open Source. It probably wouldn't be acceptable under the DFSG. It might, however, be Free Software, and that'd be an interesting discussion to have.
