3 ms·

Interestingly, there is some nuance. One of the two licenses seems to be copyleft, but it's just not currently approved. EDIT: Ironically, the SSPL seems to be

Interestingly, there is some nuance. One of the two licenses seems to be copyleft, but it's just not currently approved. EDIT: Ironically, the SSPL seems to be more open than the copyleft counterpart (AGPL) - the difference is that it enforces releasing the whole service source. Any discussion assuming that the new dual licensing model is hurting the users' freed is actually unfounded. --- About SSPL (https://redis.com/legal/licenses https://redis.com/legal/licenses): SSPL is a source-available license created by MongoDB, who set out to craft a license that embodied the ideals of open source, allowing free and unrestricted use, modification, and redistribution, with the simple requirement that if you provide the product as a service to others, you must also publicly release any modifications as well as the source code of your management layers under SSPL. SSPL is based on GPLv3, and is considered a copyleft license. This means that if you use the source code and create derivative works, those derivative works must also be licensed under SSPL and released publicly. For more information, MongoDB has a good FAQ. Note that SSPL has not been approved by the OSI, and we do not refer to it as an Open Source license.

Macha 3y ago
> but it's just not currently approved: This makes it sound like it's just a matter of resources or time to just get it approved, which is misleading. Field of use restrictions go against most definitions of open source or free software, and it was on track to be rejected by OSI until they withdrew from the process. https://opensource.org/blog/the-sspl-is-not-an-open-source-license https://opensource.org/blog/the-sspl-is-not-an-open-source-l... Similarly, Debian also rejected classifying it as open.
- pizza234 3y ago
  Right, thanks for the correction. For reference, the v2 withdrawal thread is here: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003989.html http://lists.opensource.org/pipermail/license-review_lists.o.... With the current expectations, no license will solve the problem of making software open and prevent companies from "stealing" it. The "stealing" point is not necessarily my opinion; just pointing that there's always noise about it.
aragilar 3y ago
Both were noped by lawyers pretty quickly (who actually know their stuff and how licences work, rather than random engineers), so I'm not sure what you are trying to suggest...
- pizza234 3y ago
  > (who actually know their stuff and how licences work, rather than random engineers) The whole licensing diatribe is more ideological than concrete, so it's actually about "random" engineers more than lawyers. > so I'm not sure what you are trying to suggest... First, that most, if not all, of the criticism of dual licensing, in particular WRT the Redis case, is unfounded/uninformed. The SSPL is liberal when it comes to "engineering" freedoms (fork/distribute); the restriction is a business one (SSPL is very close to AGPL). Second, most importantly, with the advent of cloud engineering, as of now, there's no licensing that makes everybody happy. And this implies that there will be plenty of complaints no matter what (just look at the dual licensing threads): - if a company adopts standard FOSS licenses, there will be complaints about cloud companies leeching off open source projects - if a company adopts non-standard but still liberal licenses (e.g. SSPL), there will be complaints about companies betraying the FOSS principles

Macha 3y ago

> but it's just not currently approved: This makes it sound like it's just a matter of resources or time to just get it approved, which is misleading. Field of use restrictions go against most definitions of open source or free software, and it was on track to be rejected by OSI until they withdrew from the process. https://opensource.org/blog/the-sspl-is-not-an-open-source-license https://opensource.org/blog/the-sspl-is-not-an-open-source-l... Similarly, Debian also rejected classifying it as open.

pizza234 3y ago
Right, thanks for the correction. For reference, the v2 withdrawal thread is here: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003989.html http://lists.opensource.org/pipermail/license-review_lists.o.... With the current expectations, no license will solve the problem of making software open and prevent companies from "stealing" it. The "stealing" point is not necessarily my opinion; just pointing that there's always noise about it.

aragilar 3y ago

Both were noped by lawyers pretty quickly (who actually know their stuff and how licences work, rather than random engineers), so I'm not sure what you are trying to suggest...

pizza234 3y ago
> (who actually know their stuff and how licences work, rather than random engineers) The whole licensing diatribe is more ideological than concrete, so it's actually about "random" engineers more than lawyers. > so I'm not sure what you are trying to suggest... First, that most, if not all, of the criticism of dual licensing, in particular WRT the Redis case, is unfounded/uninformed. The SSPL is liberal when it comes to "engineering" freedoms (fork/distribute); the restriction is a business one (SSPL is very close to AGPL). Second, most importantly, with the advent of cloud engineering, as of now, there's no licensing that makes everybody happy. And this implies that there will be plenty of complaints no matter what (just look at the dual licensing threads): - if a company adopts standard FOSS licenses, there will be complaints about cloud companies leeching off open source projects - if a company adopts non-standard but still liberal licenses (e.g. SSPL), there will be complaints about companies betraying the FOSS principles