4 ms·
The discussion needs to be split in two: the why of AGPL/SSPL, and the hate against them (and from who). Re:why - SSPL is intended to be an improvement of AGPL
by pizza234 3y ago
The discussion needs to be split in two: the why of AGPL/SSPL, and the hate against them (and from who).
Re:why - SSPL is intended to be an improvement of AGPL, because according to some, it's possible by a cloud provider to work it around.
Re:hate by big companies - Google has an explicit policy, which says:
The license places restrictions on software used over a network which are extremely difficult for Google to comply with. Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is. The risks heavily outweigh the benefits.
I think that there's no way for a license to be formally exact on preventing cloud services to appropriate a code base. AGPL was an attempt (presumably failed), and SSPL failed for the exactness reason (which is the reason why it was rejected).
- kevincox 3y agoI think there is a fundamental "proxy problem" with AGPL-like licenses. If I put a transparent proxy in front of the service and let users connect to that am I exposing it to them? Almost certainly yes. What about a proxy that provides a HTTP API for the database and then translates it to the native protocol? Probably also considered exposing. If I put stock data into the database and put up a website that displays a stock ticker am I exposing the database to them? Very likely not? But what if the user can also write stock values? What if they can sum the values of various stocks. Basically there is no clear line where you stop exposing the database to the user and you stop needing to provide the source of whatever intermediate services you are using. So lawyers will recommend erring on the side of caution and just not touching it.