Mixing
SSPL and the Open Source Definition
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
MongoDB has decided to change the licensing of MongoDB Community Server, seemingly to prevent businesses from monetizing on their product without giving anything back: https://www.mongodb.com/press/mongodb-issues-new-server-side-public-license-for-mongodb-community-server
Q1) Does this new license have a chance of being OSI approved? I'm thinking about this part of the OSI Open Source Definition in particular:
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium
must be open-source software.
It seems as if this might in some cases be in conflict with this part of SSPL:
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.*
Q2) What will the consequences be if SSPL is not OSI approved?
licensing open-source-definition free-software-definition osi
asked 4 hours ago
Mans Gunnarsson
1,581214
add a comment |Â
up vote
2
down vote
favorite
MongoDB has decided to change the licensing of MongoDB Community Server, seemingly to prevent businesses from monetizing on their product without giving anything back: https://www.mongodb.com/press/mongodb-issues-new-server-side-public-license-for-mongodb-community-server
Q1) Does this new license have a chance of being OSI approved? I'm thinking about this part of the OSI Open Source Definition in particular:
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium
must be open-source software.
It seems as if this might in some cases be in conflict with this part of SSPL:
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.*
Q2) What will the consequences be if SSPL is not OSI approved?
licensing open-source-definition free-software-definition osi
asked 4 hours ago
Mans Gunnarsson
1,581214
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
MongoDB has decided to change the licensing of MongoDB Community Server, seemingly to prevent businesses from monetizing on their product without giving anything back: https://www.mongodb.com/press/mongodb-issues-new-server-side-public-license-for-mongodb-community-server
Q1) Does this new license have a chance of being OSI approved? I'm thinking about this part of the OSI Open Source Definition in particular:
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium
must be open-source software.
It seems as if this might in some cases be in conflict with this part of SSPL:
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.*
Q2) What will the consequences be if SSPL is not OSI approved?
licensing open-source-definition free-software-definition osi
asked 4 hours ago
Mans Gunnarsson
1,581214
MongoDB has decided to change the licensing of MongoDB Community Server, seemingly to prevent businesses from monetizing on their product without giving anything back: https://www.mongodb.com/press/mongodb-issues-new-server-side-public-license-for-mongodb-community-server
Q1) Does this new license have a chance of being OSI approved? I'm thinking about this part of the OSI Open Source Definition in particular:
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium
must be open-source software.
It seems as if this might in some cases be in conflict with this part of SSPL:
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.*
Q2) What will the consequences be if SSPL is not OSI approved?
licensing open-source-definition free-software-definition osi
licensing open-source-definition free-software-definition osi
asked 4 hours ago
Mans Gunnarsson
1,581214
asked 4 hours ago
Mans Gunnarsson
1,581214
asked 4 hours ago
Mans Gunnarsson
1,581214
asked 4 hours ago
Mans Gunnarsson
1,581214
asked 4 hours ago
Mans Gunnarsson
1,581214
1,581214
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
Does the SSPL have a chance of getting OSI-approved? Yes, of course there's a chance, though currently it looks like a rather slim one.
The SSPL is significantly stricter than the AGPL. The SSPL puts additional conditions on
[…] 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.
This is on the border of what a copyright-based license can accomplish because it effectively treats Services based on the Program as a derived work of the Program. This does not seem to be inherently in conflict with the OSD. As for OSI-approval, it is up to the OSI as to whether they concur with the SSPL's interpretation of Services as derived works.
If, however, the “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software†for a Service based on the Program cannot be covered by a copyright license of the Program, then this would indeed look like a violation of the OSD as it would force “unrelated†software to be open-sourced.
My personal feeling is that the SSPL is so close to the line of what is legally possible for a copyright-based license that it will keep lawyers busy for a long time, and using the SSPL would be unwise until there is more clarity. An OSI-approval would bring some clarity, but would only be the OSI's opinion, not reliable legal advice.
If there is ever clarity in this matter, this would also have effects on GPL interpretation. The GPL is often interpreted so that other software that communicates with the GPL-covered software “at arms length†would not be covered. This would e.g. allow us to wrap a GPL-covered software with a proprietary interface. But if the SSPL is an open source license, this would suggest that such proprietary wrappers would also be subject to the GPL. This hinges on what exactly a creative work of computer software is. Is it a complete software system, or is it only individual libraries or files within a software system. Current open source practice points to the latter, but a widespread acceptance of the SSPL would suggest the former.
Primarily because of this huge shift of interpretation (i.e. under common copyright law interpretation, the SSPL asserts more control than it actually has) I think that it is unlikely that this license will be OSI-approved.
If OSI does not approve the SSPL, nothing happens. OSI approval doesn't confer any special status to the license. But without OSI approval, many people will be hesitant to use SSPL-covered software.
License compatibility is already clear: as a copyleft license, the SSPL is incompatible with other copyleft licenses such as GPL or AGPL, but like the GPL or AGPL is one-way compatible with permissive licenses such as MIT, BSD, or Apache 2.0.
Summary of the OSI's license-review thread on the SSPL:
Bruce Perens notices that the SSPL might infringe the FSF's copyright on the AGPL, and raises similar concerns to the scope of derived works that I have discussed above.- This derived works issue is further elaborated by Richard Fontana.
Bradley M. Kuhn opposes the SSPL as “a campaign by a well-resourced for-profit company to reframe what copyleft is.†They also notice that drafting an OSD-compliant copyleft license is a delicate matter – but no such care seems to have been taken by MongoDB here, and suggest that MongoDB should withdraw the SSPL from the license-review process. Many posters agree with that suggestion.
VanL suggests that the SSPL may be unenforcable in the U.S. because it could be a misuse of copyright.
Heather Meeker (who drafted the SSPL) responds that copyright misuse is not an issue here, in particular that the precedent cited by VanL hinged on non-compete clauses that are irrelevant here. “Sharing of source code is just not an anticompetitive practice.†They also note that in the U.S. challenges against the GPL on the basis of anti-trust laws have failed.- I disagree here because while the GPL and SSPL go in the same direction, the SSPL goes much further. This is further elaborated by VanL in their response.
Richard Fontana points out that discussions about possible copyright misuse are orthogonal to OSD compliance.
Brendan Hickey thinks that SSPL is clearly incompatible with the OSD, and that the SSPL “appears so absurdly expansive that actually achieving compliance might be impossible in practiceâ€Â. They also list a couple of scenarios where the license is unclear, e.g. “Use Docker to deploy an image that serves MongoDB†– would Docker then fall under the SSPL?
Nigel T observes that the SSPL brings legal uncertainty to downstream users of a service because that service might be SSPL-covered.
Florian Weimer observes that the SSPL seems misaligned with MongoDB's goals, but this is immaterial to OSD compliance. (This confuses me as well. If I pay Amazon for a hosted MongoDB instance, I'm paying them for the value of the instance and not for the value of any secret MongoDB tools they would have to release under the SSPL, if such tools even exist. Therefore, the SSPL would be unsuitable to dissuade Amazon from profiting from SSPL-covered code.)
Stefano Zacchiroli notices a big difference between AGPL and SSPL: while the AGPL triggers source disclosure requirements on modification, the SSPL already triggers on mere use.
Vadim Tkachenko sees the SSPL as anti-competitive, because any MongoDB competitor who offers a MongoDB service would have to use a pure-SSPL infrastructure stack. For example, you would not be able to use SSPL-covered software together with AGPL-covered tools. This would be an OSD 6 and OSD 9 violation.
Since to date no poster who is unaffiliated with MongoDB has stated that the license is perfectly OSD-compliant, but many posters have criticized either the provisions of the license or the manner in which MongoDB presented the license, OSI-approval of SSPLv1 seems quite unlikely (but it's only been a week so far.)
answered 1 hour ago
amon
9,3761425
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
Does the SSPL have a chance of getting OSI-approved? Yes, of course there's a chance, though currently it looks like a rather slim one.
The SSPL is significantly stricter than the AGPL. The SSPL puts additional conditions on
[…] 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.
This is on the border of what a copyright-based license can accomplish because it effectively treats Services based on the Program as a derived work of the Program. This does not seem to be inherently in conflict with the OSD. As for OSI-approval, it is up to the OSI as to whether they concur with the SSPL's interpretation of Services as derived works.
If, however, the “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software†for a Service based on the Program cannot be covered by a copyright license of the Program, then this would indeed look like a violation of the OSD as it would force “unrelated†software to be open-sourced.
My personal feeling is that the SSPL is so close to the line of what is legally possible for a copyright-based license that it will keep lawyers busy for a long time, and using the SSPL would be unwise until there is more clarity. An OSI-approval would bring some clarity, but would only be the OSI's opinion, not reliable legal advice.
If there is ever clarity in this matter, this would also have effects on GPL interpretation. The GPL is often interpreted so that other software that communicates with the GPL-covered software “at arms length†would not be covered. This would e.g. allow us to wrap a GPL-covered software with a proprietary interface. But if the SSPL is an open source license, this would suggest that such proprietary wrappers would also be subject to the GPL. This hinges on what exactly a creative work of computer software is. Is it a complete software system, or is it only individual libraries or files within a software system. Current open source practice points to the latter, but a widespread acceptance of the SSPL would suggest the former.
Primarily because of this huge shift of interpretation (i.e. under common copyright law interpretation, the SSPL asserts more control than it actually has) I think that it is unlikely that this license will be OSI-approved.
If OSI does not approve the SSPL, nothing happens. OSI approval doesn't confer any special status to the license. But without OSI approval, many people will be hesitant to use SSPL-covered software.
License compatibility is already clear: as a copyleft license, the SSPL is incompatible with other copyleft licenses such as GPL or AGPL, but like the GPL or AGPL is one-way compatible with permissive licenses such as MIT, BSD, or Apache 2.0.
Summary of the OSI's license-review thread on the SSPL:
Bruce Perens notices that the SSPL might infringe the FSF's copyright on the AGPL, and raises similar concerns to the scope of derived works that I have discussed above.- This derived works issue is further elaborated by Richard Fontana.
Bradley M. Kuhn opposes the SSPL as “a campaign by a well-resourced for-profit company to reframe what copyleft is.†They also notice that drafting an OSD-compliant copyleft license is a delicate matter – but no such care seems to have been taken by MongoDB here, and suggest that MongoDB should withdraw the SSPL from the license-review process. Many posters agree with that suggestion.
VanL suggests that the SSPL may be unenforcable in the U.S. because it could be a misuse of copyright.
Heather Meeker (who drafted the SSPL) responds that copyright misuse is not an issue here, in particular that the precedent cited by VanL hinged on non-compete clauses that are irrelevant here. “Sharing of source code is just not an anticompetitive practice.†They also note that in the U.S. challenges against the GPL on the basis of anti-trust laws have failed.- I disagree here because while the GPL and SSPL go in the same direction, the SSPL goes much further. This is further elaborated by VanL in their response.
Richard Fontana points out that discussions about possible copyright misuse are orthogonal to OSD compliance.
Brendan Hickey thinks that SSPL is clearly incompatible with the OSD, and that the SSPL “appears so absurdly expansive that actually achieving compliance might be impossible in practiceâ€Â. They also list a couple of scenarios where the license is unclear, e.g. “Use Docker to deploy an image that serves MongoDB†– would Docker then fall under the SSPL?
Nigel T observes that the SSPL brings legal uncertainty to downstream users of a service because that service might be SSPL-covered.
Florian Weimer observes that the SSPL seems misaligned with MongoDB's goals, but this is immaterial to OSD compliance. (This confuses me as well. If I pay Amazon for a hosted MongoDB instance, I'm paying them for the value of the instance and not for the value of any secret MongoDB tools they would have to release under the SSPL, if such tools even exist. Therefore, the SSPL would be unsuitable to dissuade Amazon from profiting from SSPL-covered code.)
Stefano Zacchiroli notices a big difference between AGPL and SSPL: while the AGPL triggers source disclosure requirements on modification, the SSPL already triggers on mere use.
Vadim Tkachenko sees the SSPL as anti-competitive, because any MongoDB competitor who offers a MongoDB service would have to use a pure-SSPL infrastructure stack. For example, you would not be able to use SSPL-covered software together with AGPL-covered tools. This would be an OSD 6 and OSD 9 violation.
Since to date no poster who is unaffiliated with MongoDB has stated that the license is perfectly OSD-compliant, but many posters have criticized either the provisions of the license or the manner in which MongoDB presented the license, OSI-approval of SSPLv1 seems quite unlikely (but it's only been a week so far.)
answered 1 hour ago
amon
9,3761425
add a comment |Â
up vote
3
down vote
Does the SSPL have a chance of getting OSI-approved? Yes, of course there's a chance, though currently it looks like a rather slim one.
The SSPL is significantly stricter than the AGPL. The SSPL puts additional conditions on
[…] 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.
This is on the border of what a copyright-based license can accomplish because it effectively treats Services based on the Program as a derived work of the Program. This does not seem to be inherently in conflict with the OSD. As for OSI-approval, it is up to the OSI as to whether they concur with the SSPL's interpretation of Services as derived works.
If, however, the “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software†for a Service based on the Program cannot be covered by a copyright license of the Program, then this would indeed look like a violation of the OSD as it would force “unrelated†software to be open-sourced.
My personal feeling is that the SSPL is so close to the line of what is legally possible for a copyright-based license that it will keep lawyers busy for a long time, and using the SSPL would be unwise until there is more clarity. An OSI-approval would bring some clarity, but would only be the OSI's opinion, not reliable legal advice.
If there is ever clarity in this matter, this would also have effects on GPL interpretation. The GPL is often interpreted so that other software that communicates with the GPL-covered software “at arms length†would not be covered. This would e.g. allow us to wrap a GPL-covered software with a proprietary interface. But if the SSPL is an open source license, this would suggest that such proprietary wrappers would also be subject to the GPL. This hinges on what exactly a creative work of computer software is. Is it a complete software system, or is it only individual libraries or files within a software system. Current open source practice points to the latter, but a widespread acceptance of the SSPL would suggest the former.
Primarily because of this huge shift of interpretation (i.e. under common copyright law interpretation, the SSPL asserts more control than it actually has) I think that it is unlikely that this license will be OSI-approved.
If OSI does not approve the SSPL, nothing happens. OSI approval doesn't confer any special status to the license. But without OSI approval, many people will be hesitant to use SSPL-covered software.
License compatibility is already clear: as a copyleft license, the SSPL is incompatible with other copyleft licenses such as GPL or AGPL, but like the GPL or AGPL is one-way compatible with permissive licenses such as MIT, BSD, or Apache 2.0.
Summary of the OSI's license-review thread on the SSPL:
Bruce Perens notices that the SSPL might infringe the FSF's copyright on the AGPL, and raises similar concerns to the scope of derived works that I have discussed above.- This derived works issue is further elaborated by Richard Fontana.
Bradley M. Kuhn opposes the SSPL as “a campaign by a well-resourced for-profit company to reframe what copyleft is.†They also notice that drafting an OSD-compliant copyleft license is a delicate matter – but no such care seems to have been taken by MongoDB here, and suggest that MongoDB should withdraw the SSPL from the license-review process. Many posters agree with that suggestion.
VanL suggests that the SSPL may be unenforcable in the U.S. because it could be a misuse of copyright.
Heather Meeker (who drafted the SSPL) responds that copyright misuse is not an issue here, in particular that the precedent cited by VanL hinged on non-compete clauses that are irrelevant here. “Sharing of source code is just not an anticompetitive practice.†They also note that in the U.S. challenges against the GPL on the basis of anti-trust laws have failed.- I disagree here because while the GPL and SSPL go in the same direction, the SSPL goes much further. This is further elaborated by VanL in their response.
Richard Fontana points out that discussions about possible copyright misuse are orthogonal to OSD compliance.
Brendan Hickey thinks that SSPL is clearly incompatible with the OSD, and that the SSPL “appears so absurdly expansive that actually achieving compliance might be impossible in practiceâ€Â. They also list a couple of scenarios where the license is unclear, e.g. “Use Docker to deploy an image that serves MongoDB†– would Docker then fall under the SSPL?
Nigel T observes that the SSPL brings legal uncertainty to downstream users of a service because that service might be SSPL-covered.
Florian Weimer observes that the SSPL seems misaligned with MongoDB's goals, but this is immaterial to OSD compliance. (This confuses me as well. If I pay Amazon for a hosted MongoDB instance, I'm paying them for the value of the instance and not for the value of any secret MongoDB tools they would have to release under the SSPL, if such tools even exist. Therefore, the SSPL would be unsuitable to dissuade Amazon from profiting from SSPL-covered code.)
Stefano Zacchiroli notices a big difference between AGPL and SSPL: while the AGPL triggers source disclosure requirements on modification, the SSPL already triggers on mere use.
Vadim Tkachenko sees the SSPL as anti-competitive, because any MongoDB competitor who offers a MongoDB service would have to use a pure-SSPL infrastructure stack. For example, you would not be able to use SSPL-covered software together with AGPL-covered tools. This would be an OSD 6 and OSD 9 violation.
Since to date no poster who is unaffiliated with MongoDB has stated that the license is perfectly OSD-compliant, but many posters have criticized either the provisions of the license or the manner in which MongoDB presented the license, OSI-approval of SSPLv1 seems quite unlikely (but it's only been a week so far.)
answered 1 hour ago
amon
9,3761425
add a comment |Â
up vote
3
down vote
up vote
3
down vote
Does the SSPL have a chance of getting OSI-approved? Yes, of course there's a chance, though currently it looks like a rather slim one.
The SSPL is significantly stricter than the AGPL. The SSPL puts additional conditions on
[…] 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.
This is on the border of what a copyright-based license can accomplish because it effectively treats Services based on the Program as a derived work of the Program. This does not seem to be inherently in conflict with the OSD. As for OSI-approval, it is up to the OSI as to whether they concur with the SSPL's interpretation of Services as derived works.
If, however, the “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software†for a Service based on the Program cannot be covered by a copyright license of the Program, then this would indeed look like a violation of the OSD as it would force “unrelated†software to be open-sourced.
My personal feeling is that the SSPL is so close to the line of what is legally possible for a copyright-based license that it will keep lawyers busy for a long time, and using the SSPL would be unwise until there is more clarity. An OSI-approval would bring some clarity, but would only be the OSI's opinion, not reliable legal advice.
If there is ever clarity in this matter, this would also have effects on GPL interpretation. The GPL is often interpreted so that other software that communicates with the GPL-covered software “at arms length†would not be covered. This would e.g. allow us to wrap a GPL-covered software with a proprietary interface. But if the SSPL is an open source license, this would suggest that such proprietary wrappers would also be subject to the GPL. This hinges on what exactly a creative work of computer software is. Is it a complete software system, or is it only individual libraries or files within a software system. Current open source practice points to the latter, but a widespread acceptance of the SSPL would suggest the former.
Primarily because of this huge shift of interpretation (i.e. under common copyright law interpretation, the SSPL asserts more control than it actually has) I think that it is unlikely that this license will be OSI-approved.
If OSI does not approve the SSPL, nothing happens. OSI approval doesn't confer any special status to the license. But without OSI approval, many people will be hesitant to use SSPL-covered software.
License compatibility is already clear: as a copyleft license, the SSPL is incompatible with other copyleft licenses such as GPL or AGPL, but like the GPL or AGPL is one-way compatible with permissive licenses such as MIT, BSD, or Apache 2.0.
Summary of the OSI's license-review thread on the SSPL:
Bruce Perens notices that the SSPL might infringe the FSF's copyright on the AGPL, and raises similar concerns to the scope of derived works that I have discussed above.- This derived works issue is further elaborated by Richard Fontana.
Bradley M. Kuhn opposes the SSPL as “a campaign by a well-resourced for-profit company to reframe what copyleft is.†They also notice that drafting an OSD-compliant copyleft license is a delicate matter – but no such care seems to have been taken by MongoDB here, and suggest that MongoDB should withdraw the SSPL from the license-review process. Many posters agree with that suggestion.
VanL suggests that the SSPL may be unenforcable in the U.S. because it could be a misuse of copyright.
Heather Meeker (who drafted the SSPL) responds that copyright misuse is not an issue here, in particular that the precedent cited by VanL hinged on non-compete clauses that are irrelevant here. “Sharing of source code is just not an anticompetitive practice.†They also note that in the U.S. challenges against the GPL on the basis of anti-trust laws have failed.- I disagree here because while the GPL and SSPL go in the same direction, the SSPL goes much further. This is further elaborated by VanL in their response.
Richard Fontana points out that discussions about possible copyright misuse are orthogonal to OSD compliance.
Brendan Hickey thinks that SSPL is clearly incompatible with the OSD, and that the SSPL “appears so absurdly expansive that actually achieving compliance might be impossible in practiceâ€Â. They also list a couple of scenarios where the license is unclear, e.g. “Use Docker to deploy an image that serves MongoDB†– would Docker then fall under the SSPL?
Nigel T observes that the SSPL brings legal uncertainty to downstream users of a service because that service might be SSPL-covered.
Florian Weimer observes that the SSPL seems misaligned with MongoDB's goals, but this is immaterial to OSD compliance. (This confuses me as well. If I pay Amazon for a hosted MongoDB instance, I'm paying them for the value of the instance and not for the value of any secret MongoDB tools they would have to release under the SSPL, if such tools even exist. Therefore, the SSPL would be unsuitable to dissuade Amazon from profiting from SSPL-covered code.)
Stefano Zacchiroli notices a big difference between AGPL and SSPL: while the AGPL triggers source disclosure requirements on modification, the SSPL already triggers on mere use.
Vadim Tkachenko sees the SSPL as anti-competitive, because any MongoDB competitor who offers a MongoDB service would have to use a pure-SSPL infrastructure stack. For example, you would not be able to use SSPL-covered software together with AGPL-covered tools. This would be an OSD 6 and OSD 9 violation.
Since to date no poster who is unaffiliated with MongoDB has stated that the license is perfectly OSD-compliant, but many posters have criticized either the provisions of the license or the manner in which MongoDB presented the license, OSI-approval of SSPLv1 seems quite unlikely (but it's only been a week so far.)
answered 1 hour ago
amon
9,3761425
Does the SSPL have a chance of getting OSI-approved? Yes, of course there's a chance, though currently it looks like a rather slim one.
The SSPL is significantly stricter than the AGPL. The SSPL puts additional conditions on
[…] 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.
This is on the border of what a copyright-based license can accomplish because it effectively treats Services based on the Program as a derived work of the Program. This does not seem to be inherently in conflict with the OSD. As for OSI-approval, it is up to the OSI as to whether they concur with the SSPL's interpretation of Services as derived works.
If, however, the “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software†for a Service based on the Program cannot be covered by a copyright license of the Program, then this would indeed look like a violation of the OSD as it would force “unrelated†software to be open-sourced.
My personal feeling is that the SSPL is so close to the line of what is legally possible for a copyright-based license that it will keep lawyers busy for a long time, and using the SSPL would be unwise until there is more clarity. An OSI-approval would bring some clarity, but would only be the OSI's opinion, not reliable legal advice.
If there is ever clarity in this matter, this would also have effects on GPL interpretation. The GPL is often interpreted so that other software that communicates with the GPL-covered software “at arms length†would not be covered. This would e.g. allow us to wrap a GPL-covered software with a proprietary interface. But if the SSPL is an open source license, this would suggest that such proprietary wrappers would also be subject to the GPL. This hinges on what exactly a creative work of computer software is. Is it a complete software system, or is it only individual libraries or files within a software system. Current open source practice points to the latter, but a widespread acceptance of the SSPL would suggest the former.
Primarily because of this huge shift of interpretation (i.e. under common copyright law interpretation, the SSPL asserts more control than it actually has) I think that it is unlikely that this license will be OSI-approved.
If OSI does not approve the SSPL, nothing happens. OSI approval doesn't confer any special status to the license. But without OSI approval, many people will be hesitant to use SSPL-covered software.
License compatibility is already clear: as a copyleft license, the SSPL is incompatible with other copyleft licenses such as GPL or AGPL, but like the GPL or AGPL is one-way compatible with permissive licenses such as MIT, BSD, or Apache 2.0.
Summary of the OSI's license-review thread on the SSPL:
Bruce Perens notices that the SSPL might infringe the FSF's copyright on the AGPL, and raises similar concerns to the scope of derived works that I have discussed above.- This derived works issue is further elaborated by Richard Fontana.
Bradley M. Kuhn opposes the SSPL as “a campaign by a well-resourced for-profit company to reframe what copyleft is.†They also notice that drafting an OSD-compliant copyleft license is a delicate matter – but no such care seems to have been taken by MongoDB here, and suggest that MongoDB should withdraw the SSPL from the license-review process. Many posters agree with that suggestion.
VanL suggests that the SSPL may be unenforcable in the U.S. because it could be a misuse of copyright.
Heather Meeker (who drafted the SSPL) responds that copyright misuse is not an issue here, in particular that the precedent cited by VanL hinged on non-compete clauses that are irrelevant here. “Sharing of source code is just not an anticompetitive practice.†They also note that in the U.S. challenges against the GPL on the basis of anti-trust laws have failed.- I disagree here because while the GPL and SSPL go in the same direction, the SSPL goes much further. This is further elaborated by VanL in their response.
Richard Fontana points out that discussions about possible copyright misuse are orthogonal to OSD compliance.
Brendan Hickey thinks that SSPL is clearly incompatible with the OSD, and that the SSPL “appears so absurdly expansive that actually achieving compliance might be impossible in practiceâ€Â. They also list a couple of scenarios where the license is unclear, e.g. “Use Docker to deploy an image that serves MongoDB†– would Docker then fall under the SSPL?
Nigel T observes that the SSPL brings legal uncertainty to downstream users of a service because that service might be SSPL-covered.
Florian Weimer observes that the SSPL seems misaligned with MongoDB's goals, but this is immaterial to OSD compliance. (This confuses me as well. If I pay Amazon for a hosted MongoDB instance, I'm paying them for the value of the instance and not for the value of any secret MongoDB tools they would have to release under the SSPL, if such tools even exist. Therefore, the SSPL would be unsuitable to dissuade Amazon from profiting from SSPL-covered code.)
Stefano Zacchiroli notices a big difference between AGPL and SSPL: while the AGPL triggers source disclosure requirements on modification, the SSPL already triggers on mere use.
Vadim Tkachenko sees the SSPL as anti-competitive, because any MongoDB competitor who offers a MongoDB service would have to use a pure-SSPL infrastructure stack. For example, you would not be able to use SSPL-covered software together with AGPL-covered tools. This would be an OSD 6 and OSD 9 violation.
Since to date no poster who is unaffiliated with MongoDB has stated that the license is perfectly OSD-compliant, but many posters have criticized either the provisions of the license or the manner in which MongoDB presented the license, OSI-approval of SSPLv1 seems quite unlikely (but it's only been a week so far.)
answered 1 hour ago
amon
9,3761425
answered 1 hour ago
amon
9,3761425
answered 1 hour ago
amon
9,3761425
answered 1 hour ago
amon
9,3761425
9,3761425
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fopensource.stackexchange.com%2fquestions%2f7522%2fsspl-and-the-open-source-definition%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
