License situation: Kopano Core MAPI and the AGPL3
-
Kopano Core is licensed under the AGPL3 (AGPL version 3.0) and hence any modification of it requires making the source code of it available with a prominent download link:
13. Remote Network Interaction; Use with the GNU General Public License. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
That’s not possible for Kopano Core though because it has no user interface that would enable such a thing.
I am working on a port of Kopano to Alpine Linux and in the course of it have to replace the usage of the AGPL’d bsddb (Berkeley DB) lib in it with a different database. I chose libmdbx for it and implemented the changes. However, because Kopano Core is under the APGL3 and with the modifications, it can’t conform to it, the Alpine Linux devs refuse to merge it.
Quote of Ariadne Conill:kopano-core is itself listed as AGPL, but the AGPL requires that a prominent notice be displayed to the user about source availability. Given that kopano-core is supposed to be the backend service, how do they comply with this requirement? For example, if a user connects with her Outlook client or similar, how is this notice displayed? I have my doubts that we can ship this in a way that does not create a compliance trap for end-users, and that doesn't make me feel happy about shipping this. It seems that corporate world has figured out they can abuse the AGPL as a weapon for extracting commercial license fees from users who walked into the trap not knowing all of the gotchas of the AGPL. I think we should reject such scenarios in Alpine. It is not nice to expose users (and possibly ourselves) to legal risk caused by malicious use of the AGPL.
Does Kopano offer a solution to the problem? An alternative would be to implement the possibility of choosing whether to use bsddb or libmdbx and have that be part of Kopano core upstream. Is that something that you would support?
-
Hi @thermi,
my interpretation of the apgl would be slightly different. Especially since the users installing such a version would not be modifying the source themselves. I have started a discussion internally to get you a final statement.
What are the general upsides you see in replacing bsddb? And why did you choose for libmdbx with its “OpenLDAP Public License”?
Looking at the pr in the Arch Linux bugtracker how did you select the version of Kopano to be included in Arch? In general I would recommend to track versions that we also distribute to our customers and have changelogs available for at https://documentation.kopano.io/kopano_changelog/. Overall I would recommend to track versions delivered as part of Kopano One, e.g. https://stash.kopano.io/projects/KC/repos/kopanocore/commits?until=kopanocore-9.1.0 for “core”.
The Z-push version in the pr is with 2.5.2 outdated as well, see https://z-push.org/z-push-2-6-2-final-released/. WebApp is outdated as well.
-
Hi @thermi,
as said this morning we had a short discussion about this internally. The question is an interesting one, that even at the time of inclusion in other distributions, such as Debian, did not yet come up.
As stated before we think section 13 does not really apply here, since its not the administrator that is modifying the source code, but it is the package maintainers. And for the modification by the package maintainers there is usually an overview of patches being part of said package. As can be seen at https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/main/bacula for the Alpine bacula package (which is also AGPL).
Do you have an example of an agpl licensed package that lists all packaging patches within the software itself?
Interesting reading in this regard: https://opensource.com/article/17/1/providing-corresponding-source-agplv3-license
Obligatory: I am not a lawyer
-
I talked with Ariadne and the issue she sees is that at the very least the patch applied to the source so libmdbx is used does not make kopano-core a copyright message stating the modified source and where to get it via MAPI. Is there a way to send such a message, for example as part of the server version or something else?
It is required to be compliant.Regarding picking the software version:
I picked 9.x previously but we required lots of patches by Jan Engelhardt to get kopano-core to run on Alpine at all. In 10.x, the patches are already part of the release, so I switched the version to that. The versions of the other parts of Kopano were picked because they were the latest stable, not beta or alpha, versions of those parts.
I will upgrade the package version accordingly. -
@thermi said in License situation: Kopano Core MAPI and the AGPL3:
It is required to be compliant.
Like I said we do not share this opinion.
Another example from the Alpine package repository:
- Nextcloud is agpl as well
- the packaging information at https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/nextcloud show that several Alpine specific patches are used while creating the package
- how do Nextcloud users get informed about these Alpine specific patches?
@thermi said in License situation: Kopano Core MAPI and the AGPL3:
libmdbx
You still did not say why you want to use this over bsddb.
-
@fbartels
Ariadne has only recently joined the Alpine Linux team and is assigned the project to make Alpine Linux fully AGPL compliant.
netxcloud was added before she joined the team and as such her input was not part of the decision of merging nextcloud into aports.
The current AGPL’d software in aports needs to be investigated for license compliance.
As far as I can tell, the users of nextcloud on Alpine do not net informed about the patches.@fbartels said in License situation: Kopano Core MAPI and the AGPL3:
@thermi said in License situation: Kopano Core MAPI and the AGPL3:
libmdbx
You still did not say why you want to use this over bsddb.
Alpine Linux is removing bsddb and is hence refusing to merge any package depending on it.
-
@thermi said in License situation: Kopano Core MAPI and the AGPL3:
to make Alpine Linux fully AGPL compliant.
Like I said before, we do not share the opinion that the proposed measures need to be taken to be compliant.
-
Perhaps Thermi you would like to submit your patch for using libdbm3 for review as a build option to the Kopano team for potential inclusion for those users who would like to still utilize Kopano Core services under a musl based system (specifically Alpine) by compiling it on their own?
Licensing conversations like this IMO are very divided, whether it be out of passion or principal, Ariadne who represented Alpine did make a statement that accused Kopano of manipulating the AGPL for nefarious purposes, which even as an outsider rubbed me the wrong way.
I’m just a lowly user who likes the simplicity of Alpine, and the elegance of Kopano,
-
@tiredofit said in License situation: Kopano Core MAPI and the AGPL3:
Perhaps Thermi you would like to submit your patch for using libdbm3 for review as a build option to the Kopano team for potential inclusion for those users who would like to still utilize Kopano Core services under a musl based system (specifically Alpine) by compiling it on their own?
What libdbm3? Kopano core uses bddb3 (https://pypi.org/project/bsddb3/) in various sub projects for persistent storage. This cannot be changed to another databse without loosing backwards compatibility. So i doubt that a patches for this at this moment would be accepted.
The bsddb3 Python module is using a BSD license (https://hg.jcea.es/pybsddb/file/tip/docs/license.rst) and it can be linked to libdb 5.3 just fine which uses the Oracle Berkeley DB license as where version 6 uses the AGPL license.
For the license discussion i recommend to read the sections 9, 10 and 13 of the AGPL license (https://www.gnu.org/licenses/agpl-3.0.en.html) and then decide who is modifying the code and who is actually a user who does not modify code.
@Thermi generally we cannot give legal adivise, but the whole idea to abolish AGPL software from a linux distribution because one can use a network client to interact with after installing it (no modifcation done by the one installing and operating it) sounds flawed to me.
-
@fbartels I have reached out to the FSF for clarification.
@tiredofit I will continue working on a patch set to send the required download URL and so on via MAPI to clients. It is part of my work.
@longsleep The FSF will advise. It is not my idea to abolish anything. I am just tasked with getting kopano running on Alpine and, if possible, bringing it into Aports. If you want to have the discussion about abolishing AGPL software, talk to Ariadne of the Alpine Linux team.
Kind regards
Thermi