Open Source Gig
I was prompted to write down some thoughts by the recent Elastic relicensing, and by how the reaction to it from “the community” turns individual contributors from outside the hyperscalers into gig-workers, essentially.
- A community of hyperscalers
- Commodifying their complements: not just the software, but the authors themselves.
- Individual Open Source contributors are made into gig-workers: Outside of folks employed by a member of the community, any individual contributor is made into a gig-worker.
- The Innovator’s Dilemma: hyperscalers will retreat up-market and won’t innovate outside their local maximum – the gig workers’ inventions get absorbed.
- Relicensing is an inherently acceptable action on its face
- However, how do I square that with Oracle effectively closing OpenSolaris?
Peddling Fear, Uncertainty, and Doubt
An enormous mass of electrons has been inconvenienced by folks who keep Just Asking Questions about whether the terms in section #13 apply to them: “If I build an app with a search box powered by Elastic, does section #13 apply to my app?”
Of course not.
There’s no danger of that FUD interpretation ever being plausible. The intent is clear: the hyperscalers are the targets of this section, and this is echoed both in the FAQ accompanying the license, and in multiple statements by the company’s representatives.
A mere replacement for the AGPL’s section #13
A diff between the AGPL and the SSPL shows how the latter has material changes in section #13 and nowhere else. The new section increases the scope of section #13 in the original, so that it applies not only to derivatives from AGPL-licensed works, but to components necessary to make it available as a service.
13. Offering the Program as a Service. 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.
FUD as a Service
It could be said however that section #13 is poorly drafted: it forces the redistribution of third-party components under the SSPL license, which could be incompatible with those components’ licenses.
This is entirely orthogonal to the previous discussion, with a well-known solution: you can’t distribute those components, and you can’t make use of them in your SSPL-licensed service. It annoys me greatly that this FUD is being peddled: folks who need to care about this poor wording are the folks to whom section #13 applies, the hyperscalers.
Note: the 2.0 draft of the SSPL license tried to address that poorly worded consequence.
Why only the hyperscalers?
It’s important to ask: whomst doesn’t want to publish their SaaS’ source code? Because that’s the key issue with the AGPL itself – the SSPL merely extends the breadth of components subjected to this.