Apollon Oikonomopoulos
2018-12-04 14:48:22 UTC
Package: ftp.debian.org
Severity: normal
[ Continuing the thread in debian-legal[0] and Cc'ing debian-legal as
well ]
Dear FTP masters,
I would like your opinion on whether MongoDB's new SSPL license is
suitable for inclusion in the main archive. To give a bit of background,
MongoDB was previously distributed under a mixed AGPL-3.0/Apache-2.0
license. On 2018-10-15, upstream did a commit replacing AGPL-3.0 with
the new Server Side Public License Version 1[1] — of which MongoDB is
the steward. The same change was backported to two stable branches, with
the 3.6.9 and 4.0.4 stable revisions carrying the new license.
MongoDB has submitted the license to OSI for review[2]; the discussion
there is still ongoing, but the initial response seems to be negative.
In essence, the license (at least v1 which is currently in use) is
almost identical to AGPL-3.0, with the exception of Section 13, which
*all software* interfacing with MongoDB to form a "service" to be
licensed under the SSPL too. This is a much broader restriction than
linking, but still does not seem to violate DFSG #9. It is also not a
universal restriction, but one that is based on use/field of endeavor:
+ The same ancillary software, when made part of a "MongoDB
service", must be licensed under the SSPL, while when used for
other purposes may carry any license.
+ Conversely, when building a service around MongoDB, you are only
allowed to use SSPL-licensed software to build that service,
something that may turn out to be impractical or even impossible.
Note that this does not violate DFSG #6, as it does not prohibit *using*
MongoDB itself for specific purposes, but it places heavy restrictions
on *other* software you are able to use alongside MongoDB to build a
service (for instance you can use bacula to backup your personal MongoDB
instance, but you can't use bacula to backup your MongoDB-as-a-service
unless bacula switches to SSPL). This has been somewhat rectified
in v2, which was submitted to OSI for review[3], but the spirit remains.
Also note that judging whether something is a "MongoDB service" depends
on how much of its value it derives from MongoDB, or whether its primary
purpose is "MongoDB", criteria that are both rather vague in themselves.
Finally, I worry that "enabling third parties to interact with the
functionality of the Program […] remotely through a computer network"
could be interpreted to also include Debian packages, in which case the
above restrictions would apply to the Debian infrastructure as well.
Given the above and the fact that I'm not aware of any similar precedent
in the archive, I would like your opinion on the license's DFSG
compatibility. My personal view is that while the license does not
violate the DFSG directly, it also does not agree with the DFSG's spirit
(esp. DFSG #6).
If we deem the license to be DFSG-incompatible, then MongoDB will most
likely have to be removed from the archive eventually; keeping the last
AGPL-licensed version around without the ability to cherry-pick commits
from upstream is not viable (definitely so for inclusion in stable),
given the size and the complexity of the codebase.
Regards,
Apollon
[0] https://lists.debian.org/debian-legal/2018/10/msg00001.html
[1] https://www.mongodb.com/licensing/server-side-public-license
[2] http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003603.html
[3] http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-November/003836.html
Severity: normal
[ Continuing the thread in debian-legal[0] and Cc'ing debian-legal as
well ]
Dear FTP masters,
I would like your opinion on whether MongoDB's new SSPL license is
suitable for inclusion in the main archive. To give a bit of background,
MongoDB was previously distributed under a mixed AGPL-3.0/Apache-2.0
license. On 2018-10-15, upstream did a commit replacing AGPL-3.0 with
the new Server Side Public License Version 1[1] — of which MongoDB is
the steward. The same change was backported to two stable branches, with
the 3.6.9 and 4.0.4 stable revisions carrying the new license.
MongoDB has submitted the license to OSI for review[2]; the discussion
there is still ongoing, but the initial response seems to be negative.
In essence, the license (at least v1 which is currently in use) is
almost identical to AGPL-3.0, with the exception of Section 13, which
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.
What this section says (at least to my eyes), is that the SSPL requiresIf 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.
*all software* interfacing with MongoDB to form a "service" to be
licensed under the SSPL too. This is a much broader restriction than
linking, but still does not seem to violate DFSG #9. It is also not a
universal restriction, but one that is based on use/field of endeavor:
+ The same ancillary software, when made part of a "MongoDB
service", must be licensed under the SSPL, while when used for
other purposes may carry any license.
+ Conversely, when building a service around MongoDB, you are only
allowed to use SSPL-licensed software to build that service,
something that may turn out to be impractical or even impossible.
Note that this does not violate DFSG #6, as it does not prohibit *using*
MongoDB itself for specific purposes, but it places heavy restrictions
on *other* software you are able to use alongside MongoDB to build a
service (for instance you can use bacula to backup your personal MongoDB
instance, but you can't use bacula to backup your MongoDB-as-a-service
unless bacula switches to SSPL). This has been somewhat rectified
in v2, which was submitted to OSI for review[3], but the spirit remains.
Also note that judging whether something is a "MongoDB service" depends
on how much of its value it derives from MongoDB, or whether its primary
purpose is "MongoDB", criteria that are both rather vague in themselves.
Finally, I worry that "enabling third parties to interact with the
functionality of the Program […] remotely through a computer network"
could be interpreted to also include Debian packages, in which case the
above restrictions would apply to the Debian infrastructure as well.
Given the above and the fact that I'm not aware of any similar precedent
in the archive, I would like your opinion on the license's DFSG
compatibility. My personal view is that while the license does not
violate the DFSG directly, it also does not agree with the DFSG's spirit
(esp. DFSG #6).
If we deem the license to be DFSG-incompatible, then MongoDB will most
likely have to be removed from the archive eventually; keeping the last
AGPL-licensed version around without the ability to cherry-pick commits
from upstream is not viable (definitely so for inclusion in stable),
given the size and the complexity of the codebase.
Regards,
Apollon
[0] https://lists.debian.org/debian-legal/2018/10/msg00001.html
[1] https://www.mongodb.com/licensing/server-side-public-license
[2] http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003603.html
[3] http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-November/003836.html